The Excise Movement and Control System (EMCS) is an EU digital system for recording the movement of excise goods. In the UK the service is owned and operated by HMRC.
The UK version of EMCS hadn’t been updated since it first went live in 2012. I was contracted to provide service-side content design from within a fully-fledged design and development team. The key driver for the service update was accessibility, as the existing service wasn’t meeting legal accessibility requirements.
I spent most of the Discovery phase working with the interaction designer to audit the existing service: the design, pain points, apparent user needs and legislative framework. As we were without a user researcher for the majority of this phase, I also took the lead on writing a detailed research plan to set out the team’s strategy for engaging with end users throughout the lifecycle of the project. This brief was reviewed by the internal Research Operations (ResOps) team, and approved by the project lead and by the Head of Research.
Throughout the subsequent delivery phases, alongside my daily practice of designing, testing and iterating content, I also:
Content designers are responsible for naming services and GOV.UK services are expected to adhere to the GDS naming convention – verbs, not nouns, descriptive, and with an emphasis on user-centred language.
Naming the new EMCS service presented a challenge in that GDS expected the service to be (re)named, but users didn’t want the existing name to change. So, we needed to find a new name that fit the GOV.UK model without undermining the needs of legacy users or causing misalignment between the UK and non-UK versions of EMCS.
To dig into the problem, I ran a service name workshop with 6 other content designers over 2 sessions; the first focused on exploring naming conventions and talking through different naming processes that other designers had experienced previously, and the second focused on proposing and iterating name suggestions for EMCS. The final name met with GDS’s approval and tested well in research sessions. The session Mural was later used as a best practice example for naming 2 other services.
While I was carrying out this piece of work I had the opportunity for an interesting discussion with a user researcher from another team, about how the GDS service naming convention came about and why it’s not actually capable of serving the needs of all users. Improvements tend to be rolled out starting with the most critical services first – a move which I support – but this means that ‘global’ needs tend to represent individuals who are performing single-serve actions on an infrequent basis: “Find a thing”, “Do a thing”, “Pay your whatever”, etc. Problems therefore start to pop up when we try to apply global needs to more discrete subsections of users, such as those who are engaged with single services as part of their daily work, and who may use those services to perform a range of (sometimes complex) tasks. For them, “Do a thing” just isn’t representative. This is exactly what we found with EMCS. Happily, we were able to find a solution that fit most of the needs of all of our stakeholder groups, including GDS, but there were times when it felt as if we were cutting the pointy bits off the puzzle pieces in order to make a picture that our users just weren’t seeing.
We had a very particular challenge when working as designers on the EMCS project, in that the EMCS developers were deploying almost as fast as the design team could iterate. This created a need for design documentation that was capable of doing some extremely heavy lifting, because both teams needed single sources of truth that could be used for different purposes: designers needed a flexible version that could be iterated based on research insights and then used to hand over huge amounts of content to the developers, and developers needed as a stable version to deploy and track bug fixes back to. Both the interaction designer and I also needed to be able to use this single source to support consistent digital prototyping, especially later in delivery when the team expanded to include another interaction designer and content designer.
To solve these problems I used a type of design document called a copydeck, and significantly iterated it to meet our team’s needs.
The first iteration was very closely aligned to the example found in David Haigh’s government services design presentation. It was a single page document without much detail or specialisation, which included the URL, routing, markdown and validation, but no internal document versioning or space for demonstrating content iterations or variations.
My copydeck evolved over a series of months, as team needs continued to emerge. The final iteration was much more complex than the first. The first impactful decision was to use Google Sheets instead of Word, as this allowed me to more easily demonstrate how content had evolved over time, to clearly show variations of content dependent on logic or user decisions, and to allow the entire team to easily track how and when content changes had been made. The final version includes status tags and more precise flagging for conditional elements. Markdown and “if” statements are used to stabilise routing and support independent deployment by the development team. Sub elements allow for better representation of elements that support different types of styling.
Download my copydeck template.