Approaching interaction design in government

I've had an issue with user-centred design in government as of late. There has been a lot of attention about content design and service design, but little about my preferred specialisation of choice, interaction design (IxD). I suspect that as the main role that was common in digital before the founding of the Government Digital Service (GDS), it's somewhat taken for granted as they would have been involved in the original 10 government design principles. I loved the comment from someone (I think it was you Ed Horsford?) who said that interaction designers are the red squirrels of user-centred design.

Back in 2022 I had a go at writing some interaction design specific principles of ways of working (google document and related twitter thread), based on my experiences of good compared to not-so-good interaction design practices. Caroline Jarrett and Jo Szczepanska left some great feedback on the document.

I then let it sit (actually I got really busy and then switched jobs so half-forgot about it). However, in this week's GOV.UK Design System meetup, Katharine Beer mentioned wanting to create interaction design guidance for the Department for Education, and I remembered my earlier work!

So, after a review one year on and a bit of tweaking (thanks Joe Lanman for the title, I'm terrible at titles), here are my 10 points about approaching interaction design in government and how to 'start well'.

Interaction design in government starts with:

1. Finding out what you need to ask users

This is a government design principle to understand context. This translates in interaction design to understanding what is required. This means not just understanding user needs, but also technical constraints, and sometimes workflow processes.

2. Content

Interaction design in government is nothing without content design. Can something be explained with words first? Can we prove the need for an image?

3. Patterns

Starting from tried-and-tested patterns from the GOV.UK design system (and the guidance on when to use them) means that you can save time, and begin with components built with accessibility in mind. If the pattern doesn’t work, you can start to change it and share what you’ve done with other designers to help them.

4. Accessibility

How will someone with a screen reader use your screens? Someone with a screen magnifier? Someone with ADHD? Understanding how these people use services when you start will help you make things that work for them. Accessibility is a team sport.

5. Prototyping journeys, not screens

Thinking in screens can mean putting too much information on a page ‘just in case’. Thinking in journeys makes it easier to look for the right place to put information. A user might need guidance before they start adding details. Or a staff member may expect instructions on an intranet.

6. Prototyping one journey

Rather than trying to design all journeys at the same time, start with one. This could be a simple journey, or the most important journey. Then try doing a different journey. This may mean redesigning journeys as you go. This also gives a chance to slow down and really understand constraints and user needs rather than trying to do everything superficially.

7. Prototyping one thing per page

One thing per page usually means one question per page, but it doesn’t have to be. For example, if someone is doing data entry, the ‘thing’ might be everything on a document. Your research may prove that you can group some things together or in different ways, but starting with one thing per page prioritises people who aren’t confident with the Internet or are sensitive to dense pages.

8. Doing the hard work to make it simple

This is a government principle particularly relevant to interaction design. Whether it’s forcing users to use ‘janky journeys’ in existing systems, or hiding complicated text behind icons or accordions, it’s easy to leave things complicated. Making things simple means championing journey changes rather than just adding text, and working with technical peers to understand where data can help simplify a journey.

9. Doing the hard work to make it testable

Designs that are put in front of users should be as good as the designers think that they can be. The team should be comfortable that the work is at the right level of detail, so that if it doesn’t then the team has learnt a valuable lesson. Maybe the pattern really doesn’t work. Maybe ‘one thing per page’ needs to be split in a different way. Maybe the testing proves that a stakeholder’s idea won’t work. As long as the designs have been crafted to test a hypothesis, then it’s valuable learning.

10. Teamwork

Just as user research is a team sport, doing interaction design in government is to be part of both a service team and a community of practice. Other team members can use their expertise to help refine what you need to ask and give suggestions for improving ideas. The design community can also give feedback and share what they’ve learned.

Like all things, this is a work in progress

I've put this out as a first draft. I'm interested to hear how people might change it or repurpose it for use in their own department. For example, I'm aware that this doesn't include sustainability - as it's not included in any more general GOV.UK guidance as of yet (though I believe that the NHS and some departments such as Defra are starting to integrate this into their work).

Other references

• Service Standard and Technology Code of Practice (GOV.UK)
• Government Design Principles (GOV.UK)
• Structuring forms (GOV.UK)
• Inclusive design principles
• Form design masterclass (Adam Silver, Smashing Magazine)
• How to write good questions for forms (NHS)
• DWP accessibility principles
• Designing for accessibility posters (Home Office)
• Co-design in 2022 (Defra)