Improving team memory by using the
GOV.UK prototyping kit
It can be hard to keep track of design decisions, especially in new or growing teams. Why something has changed might not be clear to everyone and could be lost if there’s a change in team members.
If it isn’t clear what we’ve tried and what has not worked, the team could end up repeating work. How can we improve team memory so everyone understands what’s been done and the reasons behind those design decisions?
Designing and iterating
When designing a government service, we continuously research and iterate the design. Iterations are good as it means we’re learning and evolving the service based on insights from real users. But it also means the design can change a lot from one sprint to the next.
When planning our work for the next sprint, we identify parts of the service we still need to design and things we need to iterate based on the analysis from the previous sprint’s research. The combination of changes can make the prototype feel quite different from the previous version.
Documenting design in a prototype
Like many other designers in the Home Office, I design in code, with the help of the excellent GOV.UK prototyping kit. It has the design system’s patterns and components built-in, so it makes getting a realistic version of a service in front of users quicker.
Updating the prototype each sprint meant the changes were being recorded in the code and the reasons why we were changing them was being kept in a research document elsewhere. This meant we didn’t have just one place the whole team could refer to and no clear picture of seeing what had happened and why.
To address this problem, we experimented with how we use the prototype kit. Not only as a tool to conduct usability research with but also as a way to document our design changes.
Keeping a record of the design iterations helps everyone in the team understand why something was changed. We settled on a structure of:
1. The sprint goal.
2. What we changed.
3. Why we changed it.
The sprint goal is an overall objective like ‘understand the outcomes of applications’. Often, we won’t know what the ideas will be but it allows us to be clear about the overall focus.
What we’ve changed relates to the previous sprint’s research and analysis, and how the design has changed this sprint. Why we changed it: this is where we add more detail about specific changes.
We found this was about the right level of information, based on feedback from the team and stakeholders. It gives people enough context so they know what to expect in that version of the prototype.
We’ve done this as a way to support our decisions and make the work we’re doing as transparent as possible. It’s also been invaluable for discussing changes and showing our thinking, particularly at service assessments.
Let us know how you improve your team’s memory.
