Designer role standard
Working together as a team
We work in agile, multidisciplinary teams. We expect our designers to work together to advocate for user-centred design (UCD).
UCD is an approach, not a team. Designing for our users should be an approach that the whole delivery team takes.
The roles
Our specific user-centred design roles are:
interaction designers - design the detailed actions a user needs to make in order to use a service
content designers - communicate complex concepts in simple logic, with plain language that a user can understand quickly
service designers – design the end-to-end journey of a service
Other roles we work closely with
These are some of the key roles you will work with in a project delivery team.
- user researchers – understand and apply a range of user research methods to understand our users and their needs
- developers - build the thing. There are usually separate front-end and back-end developers
- product owners - work with the delivery team to make sure the service meets user needs while working with business objectives and technology. They also help to prioritise work in sprints
- business analysts (BAs) – help the team to ensure they understand the needs of the business as well as the users
- delivery managers - help the whole team to work smoothly and remove any blockers to getting work done
Find out more about the roles you should have and what each role does in a service team.
How we work together
You should work collaboratively with the people on your team, including other designers.
The group of roles is ideal for you to work smoothly to discover, design and iterate a service.
If you don’t have each of these roles in your delivery team, you can use our guidance and standards to gain a greater understanding of the expectations of each role and help you to deliver what is needed - or request more resource if needed.
Our researchers and designers work together to:
- define the problem
- learn about users
- facilitate workshops
- map user flows
- sketch and prototype
- test and iterate ideas
Involvement in research
We expect interaction, content and service designers to be involved with planning research and usability sessions, feeding into research questions. They should also observe sessions and help with research by taking detailed notes.
The wider delivery team should also attend research sessions, to help them to see how the user accesses their product. Everyone in a delivery team should aim to attend research for 2 hours every 6 weeks where possible.
Agile delivery phases - expectations
At each phase of delivery, you are expected to deliver certain outputs. These are the typical outputs of each phase.
Discovery
Before you commit to building a service, you need to understand the problem that needs to be solved.
- understand users and participate in research activities
- help the team define its focus (problem statements)
- understand policy intent
- help the team communicate and understand by visualising user journeys, processes and flows ‘as-is’ to identify problems and opportunities
- find the words people use
Alpha
Alpha is where you try out different solutions to the problems you learned about during discovery.
- work up various design approaches (sketching, wireframing) for testing using GOV.UK and Home Office design elements
- create and test multiple hypotheses with prototypes
- improve design through analysis and recommendations from testing
- write and test letters, emails and notifications
Beta
The beta phase is where you take your best idea from alpha and start building it for real.
- continue testing and iterating design and content based on feedback
- engage GOV.UK content team on start, feedback and guidance pages
- facilitate design workshops in the team and invite feedback
- addressing accessibility issues reflected in the design - completing an accessibility audit and statement for the product/service
- work with business analysts / performance analysts / product managers to establish success measures
Live
The live phase is about supporting the service in a sustainable way.
- improve content and design based on live feedback and analytics
- discover and explore new user needs
- update and maintain the accessibility statement to reflect any changes
However, there may be reasons why you do not undertake all these activities in every situation. You may join at any point in a project, and how embedded you are in a wider delivery team may vary - as well as the scope of the changes you are able to make within that team.
But wherever you are, you can add value as a designer.
Another key part of a designer’s role is to take an expert eye, question approaches and challenge assumptions.
Different levels of design involvement
We need to be pragmatic with some of the projects we are involved in, as not all will have the scope and funding to apply an ideal user-centred approach.
However, we all have a part to play in advocating for the benefits of our approach even when circumstances aren’t ideal.
Some research undertaken by our designers showed that there are generally three levels of designer involvement in typical Home Office projects. We have included a guide below to help you understand the general expectations if your project falls within one of these categories.
Not integrated
This is when there is a lack of understanding around UCD and low implementation of UCD practices. You will generally find that features are driven by requirements gathering, rather than user research. You should focus on using best practice design patterns, making your service accessible and making improvements through usability testing.
Designers are:
- focussed on creating screen designs
- given requirements to create designs that adhere to them in a format ready to be used during build
- have limited scope for iterating based on usability testing
Semi-integrated
UCD approaches are known but not always implemented in the right way. It’s likely some user research will be happening, but the team may not be used to integrating findings into development. You should try to work closely with developers to implement design recommendations, involve the team in generating ideas and prioritise the most impactful areas of the interface with cycles of iterative design.
Designers are:
- valued for their design thinking so can be involved at certain points of the delivery process but not all - it can be inconsistent and not fully collaborative with development
- given some room to make changes based on user feedback
Integrated
UCD is understood and implemented and valued for driving forward the delivery. User research and design is as valued as other disciplines. The features and ideas are driven by user needs.
Designers are:
- a valued voice in each stage of the delivery process
- able to iterate based on user research
- part of a multidisciplinary team
Designing for government
Designers work with user researchers at different delivery phases to frame a problem, identify user needs and design content that meets those needs. See more on the activities that we expect at each delivery phase.
Standards we follow
We always follow the government design principles in all of our work:
- Start with user needs
- Do less
- Design with data
- Do the hard work to make it simple
- Iterate. Then iterate again
- This is for everyone
- Understand context
- Build digital services, not websites
- Be consistent, not uniform
- Make things open: it makes things better
- Minimise environmental impact
We also follow the:
Service Manual - guidance to help teams check they're working to best practice from the start
Service Standard - best practice principles for designing and delivering great public services
When designing content and services, we use:
GOV.UK style guide - style, spelling and grammar conventions
GOV.UK content guide - guidance for publishing digital content on GOV.UK
GOV.UK Design System - common styles, patterns and components used to design government services
Home Office Design System - supplements the GOV.UK Design System
Home Office content style guide – guide covering specific Home Office to help make our language clear and consistent for all our users
Accessibility
When designing services we must ensure they are usable by all and meet accessibility requirements. This means that we must adhere to the Home Office accessibility standard.
Best practice guidance
Our UCD community hub on SharePoint has lots of information about content, service and interaction design best practice.
Reviewing content
Definition of ‘done’
Content in a service is 'done' when it has been through the following checks:
Standards
- has been checked to make sure that it meets the GDS standards
- is consistent with the tone of the rest of the service
- uses clear and familiar language
- has been checked (2i'd) by a second content designer
User testing
- is designed with user stories in mind
- has been tested with users
- is amended to reflect user feedback
Sign off
- has been agreed with the product manager
- has been agreed with subject matter experts (SMEs) - for example, policy and legal teams
- service start pages have been agreed with the GOV.UK content team before presenting to policy teams
Development
- has been added to the dev environment
Reporting
- has been logged and updated on JIRA (or other team workspace) and marked as 'DONE'
If you write content for a different area other than a service, you might have different processes. Check with your line manager if you are unsure.
Types of reviews
Your work should go various types of review as part of the design process.
2i process
A 2i (second pair of eyes) is a review of a content designer’s work by another content designer, to ensure content meets style, structure and design standards.
We have a 2i process in place, which includes mandatory 2i training and a buddy system. Read more about 2i on the UCD community hub.
Design crit
A design crit is a critique, or detailed analysis of something in order to improve designs. It is not a criticism. Crits could be done at any stage in the design process and are useful to help improve overall services.
Prototyping
It’s a designer’s job to test ideas and show their thinking through mock-ups and prototypes. This can be anything from a paper sketch to a more high-fidelity, coded prototype, depending on what it is for and what stage you are at in your project.
We use Heroku and the prototyping kits for our prototypes at the Home Office.
However, when preparing a prototype for user research, you should lean towards testing interactive prototypes to test the most realistic version of an idea.
Prototyping in code
Our designers should be able to work with prototypes in HTML. We use the GOV.UK prototype kit for public-facing services, as well as the Home Office plugin for internal services.
One of the reasons we do this is because HTML prototypes look like real GOV.UK services and can help capture real user needs.
What to use prototypes for
We use HTML prototypes to quickly validate ideas and assumptions. They are not meant to contain perfect code. Within teams, it is important to establish:
- how different designers, such as interaction, service and content designers, will collaborate on prototypes
- how iterations are documented - to help teams understand how designs have evolved based upon research
What you should not use prototypes for
Prototypes should not be made to align to production code or used as a production demo for teams. There should be a separate demo or training environment which is a direct copy of the live environment.
Another option for those wanting to view what’s being built is to give selected team members accounts to get into the live system.
Who maintains prototypes
While HTML prototypes are usually created and primarily owned by interaction designers, we expect content designers to be able to contribute and make basic updates to the code. For instance, to be able to change the wording on a page. We have a prototyping page on the UCD community hub which includes information on how to prototype and recorded training.
Documenting design decisions
We have a large community of designers coming in and out of the Home Office, and with them lives a lot of knowledge. It is vital that we document the decisions we make about our designs and why we make them, so that we don’t lose this knowledge and risk re-visiting the same problems repeatedly.
There are a couple of ways you can do this, including:
- recording iterations within your prototypes (with notes as to why changes have been made)
- on a Wiki, such as Confluence
We do not dictate how you should do this – the most important thing is that you do it. You should link to relevant research where possible.
There are several blogs you can read on documenting design decisions, in the Home Office and across government: