Skip to content

NHS App design system team ‐ DRAFT

Jump to bottom
Dave Hunter edited this page Apr 11, 2024 · 4 revisions

Who we are

  • Dan Collins - Product manager
  • Alex Drake - Delivery manager
  • Gina Britton - Scrum master
  • Simon Moore - Technical lead
  • Mike Monteith - Lead Developer
  • Dave Hunter - Lead designer
  • George Rowe - Visual designer
  • Michael Milne - User researcher
  • Graham Pembrey - Content designer
  • Lavanya Khetavath - Tester
  • Vonni Bentley - Business analyst

Our products

  • NHS App design system website
  • NHS App design system Figma Library
  • NHS App HTML prototype
  • NHS App Vue component library

Roles and responsibilities

We work in a multidisciplinary way. Many people contribute to the work happening across the stages of the workflow, but some people have a clear role and responsibility to drive things forward. We also rely on each other to provide the necessary inputs at each stage.

For example, a designer will consolidate multiple designs to define a versatile style, component or pattern. Designers need evidence as source material for that, which they may get from the user researcher.

When not playing a driving role, people play either - a supporting role, contributing to work at this stage, or - need awareness of what’s happening, so they can have input later.

Workflow stages

  1. Prioritise what to work on
- The product manager, lead developer and lead designer play a driving role. The delivery manager, content designer and user researcher play a supporting role.
The product manager requires good-enough data to make realistic calls on what’s valuable, and input from delivery, design and development to understand what’s feasible.

  2. Gather evidence and consolidate designs
- The user researcher, developer and designer play a driving role in gathering evidence. The product manager and content designer play a supporting role.
The designer and developer need examples from the community, which the user researcher helps facilitate. The designer and developer need to know the design direction or rationale for any constraints.

  3. Create a rough proposal
- The designer and developer play a driving role. The content designer and product manager play a supporting role.
The developer and designer communicate with the design and development community to let them know about the upcoming proposal.

  4. Build a working version of the thing
- The designer and developer play a driving role. The content designer plays a supporting role.
This is a highly collaborative stage of the model.

  5. Do more user research (only if needed)
- The user researcher plays a driving role. The designer, content designer and product manager play a supporting role.
The user researcher needs information from the designer and developer in order decide whether research is necessary.

  6. Build a robust version of the thing
- The content designer, delivery manager, designer, developer, content designer and user researcher play a driving role.
This is a highly collaborative stage of the model.

  7. Publish
- The content designer and developer play a driving role. The delivery manager, product manager, lead developer and lead designer play a supporting role.
The content designer needs a plan and expected audience for communicating the publication.

Core values

These values form the bedrock for how we work together. They’re designed to inspire action, help us make decisions and set boundaries.

  1. Don’t skip the basics. We build good quality, well researched stuff that works for everyone.


  2. We build in the open, so that people can see what we are doing and why we have done things.


  3. Stay curious, humble and open to new perspectives. We take on feedback and change our work or our ideas. 


  4. Be inviting. Work with and for our peers and community — it’s a two way relationship. Actively encourage members of the team, people on the NHS App, and the wider community to get involved in our work.


  5. Transfer power. Enable others to make decisions about the design system. Seek out people and ideas proactively that we can involve in activities.


  6. Educate. We’re set up to do the harder work, but we can provide people with the knowledge and skills to iterate and improve the design system sustainably.


  7. Evidence and research are golden get it when you can. But expect a bumpy road. It’s okay to make a call that turned out to be wrong. That’s how we learn and improve.


  8. Care for, support and look out for each other.
We look after the team’s health. We own our team and its ceremonies collectively. We create a safe and empathetic environment for each other.


  9. Progress, don’t perfect. Focus on validating the riskiest assumptions. Highlight where the cost of being wrong is low. Trust the community’s insights to guide us. Iterate.

Group norms

These norms are the social contract which underpins our work.

  1. Ask for help when you need it
  2. Don’t work if you’re not well
  3. Share your work
  4. Say what you’re going to do, do it, say what you did
  5. Involve others in decision making
  6. Be willing to make a call based on evidence, even if it doesn’t feel perfect
  7. Invite feedback
  8. Take the time to say thank you

Adapted from https://team-playbook.design-system.service.gov.uk/

Clone this wiki locally