Sharing designs and recording decisions
Depending on what stage your service is at, you’ll likely use different techniques and tools to share your work with the team and test it with your users.
This could be:
- sketches or wireframes – to ideate quickly or show layout of content on a page
- a user flow – to show the order of pages
- clickable prototypes – to show the content to the user
- Word documents – for example, to draft an accessibility statement
- a table on Confluence – for example, to provide bilingual error messages to developers
If you join an established team, they may have preferred tools to showcase and test the work. For example, the interaction designer might build wireframes or prototypes using Figma and create user flows on Mural.
Speak with your team, especially UCD colleagues, and decide which tools are best for you to collaborate on.
Working in the open is an important part of agile delivery. Your delivery manager should show you where to store information. For example, this could be on Sharepoint, Confluence or Mural depending on how the work is set up.
Prototyping
A prototype is a version of your work which you use to develop your service. Prototypes are often quick and easy to update, allowing you to iterate and test content and interactions.
You’ll typically be working on prototypes alongside your interaction designer. Read more about prototypes whilst working in the alpha phase.
Record your content decisions
Consider how to save previous iterations and record why you made the changes.
Design histories
A design history is like a blog. They’re short updates that describe the iterations and development of a service based on user research. See Department for Education design histories for examples.
These design histories are sometimes built into the prototype. Ask your interaction designer about how you'll record these.
Save versions of your files and prototypes
Save previous prototype iterations and documents, particularly those that have been shown to users.
Use a consistent naming convention, so you can easily recall the different versions you’ve worked on.
This will help you find previous work, if you ever need to go back to an older feature or content that worked better.
Risk register, also called a RAID log
A risk register is a document formatted in a grid that lists the risks, assumptions, actions, issues, dependencies and decisions.
Sometimes decisions might be made that might not be the best fit based on user research.
If content changes are not implemented for some reason, it’s helpful to log any associated risks and share these in a friendly and open way. This makes sure your concerns visible to the team, and you can rest easy that you’ve let people know.