Skip to main content

How to grow capability across UCD disciplines with a ‘design a service in a day’ workshop

Posted by: , Posted on: - Categories: Design, Training

4 members of the user-centred design community holding up their paper prototype sketches.

The user research and interaction design teams at HM Courts & Tribunals Service (HMCTS) spent a day together face to face, helping each other to grow their skills and tools. Interaction designers wanted to upskill in user needs and interpreting discovery research. User researchers wanted to expand capability in user journey mapping, designing questions and prototyping for testing. Both teams wanted to gain experience coaching colleagues outside their discipline. User research and interaction design are user-centred design (UCD) roles — you can find the skills required for these roles in the Government Digital and Data Profession Capability Framework.

A group of us facilitated the session, and we designed a challenge based on a fictional government initiative — to encourage pet owners to volunteer their animals to volunteer in the community. The teams used the provided discovery research, did their own desk research, and worked together to end the day with a prototype for the service.

This model can be replicated, both with these disciplines, as well as others.

The structure of the day

We split the day into sections:

  • Capturing user needs
  • Naming the service
  • Mapping the service
  • Designing the questions
  • Prototyping in Figma with an introduction to the Prototype Kit

Throughout the day, we related activities back to the Service Manual and Service Standard.

The fictional problem we gave teams

The teams were given a brief alongside discovery research about an existing initiative for the public to register their pets as volunteers. The take up was low due to pet owners and organisations not knowing about the scheme.

The department wanted the teams to design a service to allow pet owners to register their animals through a registration form, however teams needed to think about the broader picture beyond the form. For example, how would organisations access the register? How might potential volunteers find the form?

You could use this problem, or design your own brief to focus on specific skills or methods your teams want to develop.

1. Capturing user needs

We began with a refresher on user needs versus user wants, looking at the Government Design Principle ‘Start with user needs’ and thinking about needs as being problem-centred and based on evidence and relevant research, rather than assumptions.

Task 1: The teams then broke off to write user needs on post-it notes. They conducted research online during the activity and then prioritised their user needs.

2. Naming the service

In the next activity, we looked at the guidance for naming a service.

Task 2: The teams worked together to workshop ideas for naming their services, applying the key principles of the guidance. This was an opportunity for the teams to think about the purpose of the service and how users will find it.

3. Mapping the service

We then moved on to designing the registration form.

Before the teams started mapping their services, we reviewed some parts of the Service Manual. We prioritised areas which would help the teams develop a good service, including:

We looked at mapping styles, from low fidelity post-it notes describing steps in the journey, to high fidelity wireframes.

Task 3: The teams then broke down what they needed to capture from users and what the journey would be in phases, such as:

Before the service:

  • How will users find the service?
  • Do they need to check if they’re eligible?

In the service:

  • What do we need to capture from users?
  • How long is that journey
  • Will they be able to complete the form in one go?

After the service:

  • What happens next?
  • What can users expect?
  • How do we keep users informed?

Slides on a big screen, the slide explains the 'designing the questions' task.

4. Designing the questions

After creating a high-level map of the user journey, the teams began looking at questions in more detail.

At this point, we took a look at some of the Service Standard - particularly the points that would help the team design their questions: 

We also introduced the GOV.UK Design System and the ‘Do’s and Dont’s on designing for accessibility’

Task 4: Using the design system as a reference for components and patterns, the teams split up their journeys and everyone took the opportunity to create some low fidelity mockups to sketch out how to ask the questions. Then they discussed different pattern options in groups.

5. Prototyping

We then introduced different prototyping methods, including MOJ Forms, the GOV.UK Prototype Kit and using design tools like Figma, looking at the pros and cons of each method.

We worked through a step by step training exercise on how to create a screen in Figma using the design system. This involved giving a high level overview of how Figma works, how to install the GDS Transport font and how to activate the design system as an asset library.

Task 5: Once everyone had successfully created an example page, the teams split off again to continue developing their designs from sketches to screens in Figma.

The teams were also asked to think about how they might test these designs, with a focus on thinking about it from the angle of the other discipline.

For example:

  • Did the user researchers have any thoughts on key areas we needed to test for usability? 
  • Were any of the interactions they had designed potentially inaccessible and worth investigating?
  • What questions would the interaction designers ask if they were conducting a research session?
  • What testing methods might the designers use to validate the prototypes?

Reflections on the workshop

Overall, both researchers and designers found the day really valuable as a development activity. Designing a service in a day provided opportunities for both disciplines to think more generally about users and the standards we design to, as well as gaining more practical skills like using the design system and Figma. 

We hope to follow up this activity in the future — testing the forms the teams have designed and iterating based on that feedback.

We are keen to learn about how other teams use this type of session to upskill their teams, and if there are any other activities they include with other disciplines. If you would like to see the templates we used, email

Sharing and comments

Share this page