Big government design
Bobby King | Madmarch | UX Glasgow
User-Centred Design for longer-term, complex government projects
Contents
Introduction
Teamwork
Looking after a giant prototype
Sharing design decisions
Introduction
I worked on two HMRC projects between 2021 and 2024. Before that I worked for the Home Office for a year.
The challenges I faced were:
Teamwork
User-Centered Design roles
User Researcher
Collects research questions, chooses methods, analyses the results
Interaction Designer
Designs user flows and screens
Content Designer
Writes content and identify who reviews it
Service Designer
Designs the whole ‘end to end’ service
Other important roles
Business Analyst - keeps track of ‘requirements’ and hands over the design to developers to build
Policy, legal and compliance staff - define the boundaries of the project and often review the content
Give people ownership
A Business Analyst owns the requirements.
A User Researcher gets to choose the research method, carry out the research and make recommendations.
A Content Designer gets to choose the final wording.
An Interaction Designer gets to choose the design patterns.
A Service Designer gets to map out the whole service (not just the online journey)
The challenge: making design decisions
We use research to check our designs are useful, usable and accessible.
However, research can’t tell you want the design should be - that responsibility belongs to the Interaction Designer and Content Designer.
Use mapping along with prototyping
Mapping out an online journey before you create a prototype is a good way of understanding the problem.
You can also review the map with stakeholders without having to show them full screens.
Start page
How many balls can you juggle?
What is your favourite trick?
Tips for working together
I try to:
How do I tell if ideas are good or bad?
I use a combination of:
Try to balance the three parts of the project
The UCD team is only one part of a project. If any one part is neglected, the whole project will be dysfunctional. Bringing in third parties (like external developers) can add more challenges.
Policy
Design
Development
What the government want
What service users actually need
What we’ll build, and how we’ll build it
Looking after a giant prototype
Use the gov.uk prototyping kit
The gov.uk prototyping kit gives you helpful instructions for building your own prototype and hosting it on a service like Heroku or Onrender.
Most organisations support good design
HMRC and the Home Office give you instructions on how to host your prototypes on Github.
You don’t need that much technical knowledge to be a government interaction designer.
Prototypes can become huge and out of date
One project had been running for four years by the time I left. The prototype had dozens of journeys and hundreds of files.
From time to time we’d create an ‘archive’ of the prototype and start again with a new one.
Sharing the prototype between three designers
At HMRC we kept one version of the prototype on Github. We used separate branches and used Github desktop to avoid merge conflicts.
Use Heroku to host more than one prototype
We created two duplicate versions of the prototype for Heroku: a main version and one for User Research.
These were actually two versions of the same prototype. We avoided updating the second version during research sessions.
Version control - current and new versions
We kept a ‘current’ area of the prototype for our development team to use. This only contained journeys where the design and research was complete.
We also had versions where we were still running research. We updated these every two weeks.
Set variables as you go
A prototype page might show different content depending on different variables - such as whether the user is a juggler or a juggler’s manager.
You can offer a starting screen where the prototype user can set the variables. This can help with usability testing.
You can also build prototype toggle links into the footer to switch views on any page.
Discuss what to hand over to developers
Different designers have different approaches for what to hand over to developers.
I hand over a working prototype with all the screens which have to be built. I don’t build in error messages: the Content Designer creates a separate document for these.
Meet with your developers and discuss the best way to hand over designs.
Remember: interaction designers aren’t developers!
Although we write code, it’s not our job to make perfect prototypes which work like actual software.
Our job is to solve problems for users!
Group design decisions
Run regular show and tells
Schedule review meetings with your fellow designers to review each other’s ideas.
When you find a good solution, re-use it: for example, a good wording or a design pattern which solves a problem.
Try to be consistent with the patterns you use.
Make research a team sport
During one project, I helped run over 50 user research sessions by building prototype journeys.
Involve designers, developers and policy colleagues to watch research and take notes.
They’re more likely to understand what the research means if they’ve watched users try the prototype.
Make previous research easy to find
Agree on a way of storing research findings so that they are easy to find: such as on Confluence or Sharepoint.
Summarise the findings on a page called ‘Research themes’.
Use the gov.uk design system
There’s no point designing your own ‘Start’ page! Use the default version from the gov.uk design system.
Only design something new if your research tells you that you need to.
Documentation: store your design decisions
Create a Confluence or Sharepoint page with a table of ‘design decisions’ on it.
Explain why you designed the service the way you did. Also document what happened when you tested the new design with users.
You can refer to this when you go through a Service Assessment.
Be a prototype ninja - store useful code
Keep a Confluence page of useful code snippets. This can help the designers stick to the same style of code.
You can also use a section of the prototype to store templates of commonly-used pages.
Veterans versus rookies
Most of the ideas in this presentation aren’t mine.
If I work with a younger designer with drive and enthusiasm, I usually let them try out their ideas.
I learn from both experienced designers and people who are new to the UX field.
Conclusion
Design projects are non-hierarchical
Modern design teams have delivery managers, scrum masters and product owners but they don’t have leaders as such.
Everyone’s expected to collaborate, make decisions and resolve conflicts. This is what makes design challenging.
How interaction designers can support the team
Give your team what they need at the right time - whether it’s a map, a prototype, a sketch or just an encouraging word.
Strike a balance between taking responsibility for the design and allowing good ideas to come from anyone.
Bobby’s tips for playing in bands (also applies to design projects)
Ability is less important than teamwork:
Thanks for listening
Bobby King | Madmarch | UX Glasgow
Any questions?