Complex design documentation

The project

 
Redeveloping the legacy Excise Movement and Control System (EMCS) for HMRC.

The problems

 
The EMCS service involved redesigning 300+ individual pages of content within a relatively tight timeframe. By the time the project reached Alpha, the EMCS design team found that developers were deploying almost faster than the design team could iterate. This created a need for design documentation that was capable of doing some extremely heavy lifting, because both sides of the team needed single sources of truth that could be used for different purposes.
 
Designers needed a flexible version that could be used to:
 

• demonstrate research insights
• hand over huge amounts of content to the developers
• support multiple designers working in the prototype environment
• clarify complex routing and logic across a huge and complex service
• hand the service over to a permanent team to support ongoing improvements post-delivery

 
Developers needed a stable version of content that they could:
 

• deploy and track bug fixes back to
• build independently without the need for clarification of intent from the designers

The solution

 
A type of design document called a copydeck, significantly iterated it to meet our team’s diverse needs.

The process

 
The first iteration of the copydeck was based on a primary need from the design team – to be able to record the content and track changes over time so that we could demonstrate to stakeholders how we were acting upon research insights. It was a single page document that captured the on-page content, URL, routing, markdown and validation. The model for this copydeck came from David Haigh’s government services presentation.
 
I began to iterate the copydecks when the developer team started using them to support the build. 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. This allowed me to start using status tags and more precise flagging for conditional elements.
 
The final version of the copydecks included Markdown and “if” statements alongside content variations and sub elements. Doing this gave us a clear view of how routing worked across the entire service, without having to rely on the prototype environment to demonstrate conditional logic. It also meant that the developers were able to deploy independently, without having to ask for clarification on more complex points of style, logic or validation.

The outcome

 
By using my copydecks, the team found that we were able to:
 

• more easily demonstrate how content had evolved over time
• save time that would otherwise have been spent in meetings
• easily standardise language and terminology across hundreds of pages of content
• work more efficiently inside of and adjacent to the digital prototype environment
• peer review work more efficiently
• communicate work and progress when team members left or joined the project

Download my copydeck template.