DWP interaction design community
DWP wide Interaction Design monthly community meeting (Teams)
The Interaction Design monthly community meeting is a chance to share work, get feedback and learn from each other. We use this time to:
- stay up to date with activity relevant to our profession and the User Centred Design practice
- see examples of work from other parts of the department
- discuss challenges with like-minded colleagues
Interaction design community meetings
We’re a dispersed team, so we create a strong community by having regular meet-ups virtually and in person across the country.
As part of your induction you will be invited to the community meetings relevant to you.
All designers are expected to make a positive contribution to community meetings by:
- taking part
- sharing their work
- giving feedback on others’ work
There are also plenty of other events related to interaction design, organised by the government and others.
Ask other interaction designers in your regional team what’s going on.
Interaction design community days
All our interaction designers meet up together every 3 months.
Less frequently, we hold meet-ups where people with a wider affiliation to interaction design come along, too.
At the moment these events are being hosted online, but we hope to do them face to face again soon.
At both of these types of get-togethers, people:
- give presentations on work they’ve been doing
- listen to guest speakers
- try to address interaction design issues collectively
Interaction design community on Slack
Slack is used in the design community to chat, collaborate and share.
It may already be installed on your Mac or it’s available in the ‘Collaboration’ section in the Self Service application.
You may also want to download Slack to your personal mobile device (but there’s no obligation to).
Slack etiquette
Slack is not an alternative to email - not all members of staff across DWP have access to Slack. You should think about your audience when deciding which communication tool to use.
If you want to discuss or share something with the design community Slack is usually the first choice.
All digital communications that public servants use are subject to Freedom of information regulation. All messages, public, private, group and direct can be requested and released. Be mindful of what you say and share.
Workspaces
You will be invited to two workspaces in Slack:
- DWP - dwpdigital.slack
- UK government - ukgovernmentdigital.slack
Channels
Each workspace is divided into channels set up around different themes.
The main channel you will use is #interaction-design in the DWP workspace. We’ll invite you and introduce you to the community.
Use this channel to:
- ask interaction design questions
- share work for feedback
- help others with their interaction design problems
This means all interaction designers can see and take part in conversations about each others work.
The senior designer in your area will invite you to the relevant channels you need for the service you’re working on.
Expectations for Interaction Designers in DWP
Consider the bigger picture
Interaction designers are problem solvers. We think about problems first and actively encourage those around us to do the same.
Designers must:
- make design decisions based on research and data
- consider multiple solutions to a problem
- design for all users regardless of ability or technology
- remove unnecessary interactions
- design user journeys and interation flows, not just screens
- consider all channels, not just digital
- take themselves out of solutions
- be curious
- positively challenge and ask why
Collaborate, share and work in the open
We facilitate discussion and collaboration to bring understanding to teams.
We actively involve team members and stakeholders in the design process so we can get to meaningful solutions more quickly. This builds understanding and a sense of shared ownership.
Seeking feedback early and often helps identify any potential issues in a design quickly. It also helps spot opportunities for re-use.
Designers must:
- be highly collaborative, and bring others on the journey
- share work regularly
- use common tools, processes and patterns
- share successes and lessons we've learnt
Re-use components, patterns and insight
Re-use builds on expertise and insight from other teams, helping DWP Digital deliver better products and services to users with greater efficiently.
Designers must:
- re-use existing components and patterns where appropriate
- support the creation and improvement of patterns
- document design decisions referencing user research and data insights
- contribute to the DWP Design Research Library
Contribute to the community
We pride ourselves on being a highly supportive and inclusive community. We make ourselves available and support each other.
Designers must:
- attend and contribute to community meetings
- be open, share what works and what doesn’t
- communicate using plain inclusive language avoiding jargon
- suggest improvements to the community and practice
- set development goals and work to develop our skills
Act as an ambassador for interaction design in DWP and government
We are representatives of the Interaction Design practice and the user centred design discipline in DWP and government.
Designers must:
- aid understanding of interaction and user centred design
- advocate the benefits of working in a user centred way
- ensure the voice of the user is present in design decisions
Design Clinics
Design Clinics are sessions you can use to get feedback on your work or support on a particular design problem. The sessions are attended by a group of 4 experienced interaction and service designers. Before you attend you’ll be asked what you want to get out of the session and to provide some background.
What happens during a Design Clinic?
The Design Clinic is a 1 hour session where you get to present your work and get feedback.
Use this session to get help if you’re finding something particularly difficult or need help on what to try next. It may be something you’re trying to design, or a related problem like trying to bring people onboard with a particular approach.
Before the session
Provide some background on what you’re going to show or discuss. It’s up to you who comes along from your team, but no more than 3 members of your team. You’ll need to make sure they have the meeting invite and a link to the Mural board.
1 hour agenda
- 5 mins - Introductions and set up
- 5 mins - Background – set the scene
- 15 mins - Show the thing or frame the problem
- 25 mins - Discuss feedback
- 5 mins - Agree any actions or next steps
Stick to the agenda so there’s plenty of time for feedback and sharing ideas - that’s the most valuable part..
You can bring any artefacts you want to share, but it's not essential. The Design Clinic is a great way to get feedback on your work and to learn from other designers.
Prototyping
At DWP, we use GitHub to host the code for our prototypes and Heroku to deploy them for the purpose of usability testing. As a Designer, there are a few things to keep in mind and standards to follow when it comes to prototyping.
Prototypes are a tool to test ideas quickly
- Start small. Sketching is a great tool to work through ideas collaboratively before jumping into any kind of prototype
- Use the right tools that meet the need. If you don’t need an interactive prototype to test with users, don’t spend unnecessary time creating one.
- You don’t need to be a developer to use the GOVUK Prototype Kit
- The GOVUK Prototype kit was designed to be a quick tool to iterate and test prototypes
- Do what you need to do to test your design, don’t overdo it. They only need to be as a high fidelity as required for the testing you are doing.
- If the prototype works, don’t worry about having beautiful code.
- There are no Dev standards for writing prototype code
- There is lots of guidance for using the GOVUK Prototype Kit
Expectations for designers creating prototypes
- You have design documentation available for people to digest what design decisions have been made
- Your prototype is listed on Confluence with all the relevant information for people to see
- Your prototype does not have any data or sensitive information in it that is not suitable for public consumption
- You will use the GOVUK and DWP Design Systems as a starting point for testing designs. If the patterns, styles and components do not meet the needs of your users, you can use design systems from other government departments or propose a new one. If you propose a new pattern, style or component, it must be shared and reviewed via the appropriate channels
- You will regularly share your work
Tools
We use a range of tools to design and build services and systems.
It’s important we are using the same tools to aid collaboration across the department. At some point we’ll handover to another designer, using the same tools will make this transition easier for everyone involved. There’s an approved list of tools available to use on DWP MacBooks, which you can install using the Self Service App on your MacBook.
The tools we use
- Figma
- Sketch
- GitHub
- Heroku
- Confluence
- Jira
- Pen and paper
- Mural
The DWP Acceptable use policy provides guidance on the appropriate use of equipment and tools.
Design definition of done
- Understood user needs, and designed to meet them
- Understood business requirements, and designed to meet them
- Re-used existing proven solutions, where appropriate
- Considered and addressed impacts on end-to-end user journey
- Considered and addressed accessibility needs and best practice
- Validated design with research and data
- Shared with team and stakeholders
- Reviewed by UCD-specialist peers
- Checked for factual accuracy
- Documented decisions, evidence and any design debt
The definition of done does not tell you how to do these things. There are different methods and tools you can use. Our measures of success guidance includes examples of how you might meet each point.
Who decides what needs to be done
As the design professionals, you decide what needs to be done to tick each item off the checklist. You may also decide that a particular thing isn’t justified for the design you’re working on.
For example, you may decide you don’t need a fact check on a cosmetic design change, or that you don’t need to conduct research when fixing a typo.
If you can’t complete the checklist
It may be that you can’t complete the checklist but need to produce a piece of work anyway. Common examples include:
- delivery timelines mean you need to create and release something quickly
- you do not have access to sufficient data or research
- your team does not have access to accessibility testing tools
The product owner decides what is acceptable to be released. However, if you can’t complete the checklist it might mean that further work is needed to fully validate the design. You should record any design debt in your documentation.
Measures of success
Measures of success are how we validate we’re doing the right thing when we create or iterate design solutions.
The measures of success are reflected in our definition of done and should be used alongside that artefact.
Before you design
Understand user needs
Ways to do this include:
- work with user research to test as-is journeys and identify pain points
- contribute to, observe, and analyse research with real users
- work with data science and analysts to identify and understand performance data
- articulate and record user needs and hypotheses, based on research and data
Understand business requirements
Ways to do this include:
- work with business analysts to understand business requirements and processes
- identify subject matter experts and collaborate with them to understand the domain
- articulate and record clear business problem statements
While you design
Reuse proven solutions, where appropriate
Ways to do this include:
- use patterns and components from the GOV.UK Design system and DWP Design system
- share problems with other UCD professionals to seek advice
- adhere to departmental content, interaction and research standards
Consider the end-to-end
Ways to do this include:
- collaborate with other product teams in your area
- collaborate with non-digital stakeholders such as operation teams, policy and customer comms
- review the full journey - not just the part you’re currently working on
Ensure design is accessible
Ways to do this include:
- test designs with accessibility technology and different devices
- follow GOV and DWP accessibility guidance collaborate with accessibility experts
Research and iterate
Ways to do this include:
- contribute to UR discussion plans to gain insights about user understanding of your product
- refine and iterate design based on the outputs of research exercises
- evidence how design decisions are made based on user needs, research and business requirements
Work collaboratively
Ways to do this include:
- share work in feedback sessions with your product team
- pair-write and co-design with colleagues and stakeholders
- work closely with your UCD colleagues and other specialists to consider the full picture
Peer review
Ways to do this include:
- present work at community events and discussions
- participate in design and content crits with other designers
- invite peers to give a ‘second pair of eyes’ check
Fact check
Ways to do this include:
- work with business analysts and subject experts to ensure evolving designs meet requirements
- collaborate with stakeholder experts to have design and content fact-checked
When the design is live
Ways to do this include:
- understand your success metrics and hypotheses before your product or feature is made ‘live’ review performance data at regular intervals
- where appropriate and possible, use live experimentation techniques such as A/B testing
Collect and use feedback
Ways to do this include:
- collect user feedback in-product with feedback links and surveys
- work with call centres and agents to collect feedback from user contact
- build assurance periods into release plans to allow for rapid iteration based on feedback
Regularly review
Ways to do this include:
-
schedule regular reviews of your design and content
- present designs in show and tells with stakeholders and digital colleagues
- include existing journeys when researching new features
Document decisions and design debt
Ways to do this include:
- document design decisions and the supporting evidence, such as:
- user needs
- business requirements
- research findings
- supporting data
- document when design was limited by technical or delivery restrictions, recording things like:
- what limitations you encountered that restricted your design decisions
- what further work needs to be done to validate or iterate the design
- the potential risks the limitations to design cause
Documenting design debt
What design debt is
Design debt is when you have something that you know you need to revisit and do more work.
Some examples of design debt include when:
- your design is a temporary fix to mitigate a current technical limitation
- you’ve had to release something before it’s ‘done’ and need to iterate retrospectively
Make it transparent
Your design debt documentation should be an open artefact.
At minimum, your documentation should be accessible by everyone in your team and sharable with stakeholders.
Ideally, your design debt log should be accessible by everyone in DWP - but this may not be achievable.
Where to put it
To make your design debt as transparent as possible you should keep your documentation in a findable place.
A good choice would be to keep it in the same place as the rest of your team’s documentation, for example a team Confluence space, Mural board or SharePoint site.
If you keep your design debt documentation somewhere else you should provide clear links to it from your team space.
Talk about it
Design debt documentation is not a substitute for conversations with your team. If releasing a design will cause debt, you must raise this with the right people and explain the risks. In particular, your Product Owner should be informed and confirm that they want to proceed anyway.
What you should include
Your design debt documentation should include:
- the date the debt was created, or discovered
- a description of what the debt is
- an explanation of why it went live with debt
- a brief outline of the possible risks caused by the debt
- details of what needs to be done to remove the debt
This is the minimum that you must include, but you can include more if you think it’s needed.
Linking to other documentationMany teams document in other artefacts, such as Jira tickets and research reports. Your design debt documentation should give enough of a summary to understand the problem and proposed solution at a high level, but you can link out to other sources for additional detail and evidence.
How to use design debt documentation
Keep a record
Use the documentation to keep a record of debt, identified risks and actions needed to resolve.
Advocate for action
You should advocate for the inclusion of design debt into your team’s product backlog, risk log, prioritisation discussions and, ultimately, to be picked up as part of the workflow.
Keeping a record does not replace the need to advocate for action.
Working with performance analysts
What is a performance analyst?
Performance analysts develop success metrics and analyse the performance of a product against them. They help you find evidence to show if your service is meeting user needs, design hypothesis and product goals.
When to set success metrics
You need to outline your hypothesis and set success metrics before new features are made 'live' in your service. If you wait until something had already gone live you will have missed the opportunity to measure the immediate impacts, and it will be very difficult to accurately build a 'before' and 'after' picture.
If something has already gone live you should still engage a performance analyst, but you should try to avoid this happening.
How to find a performance analyst
The best way to define success metrics and collect data is by working closely with a performance analyst, or other data science professional. You may have dedicated performance and data professionals in your area of work or you may have to seek support from the wider Data Practice.
You can find a performance analyst in your area on the DPA community organisational chart
When to engage with a performance analyst
Earlier is better. If you engage with performance analysts early, while you are developing your hypotheses for a design, they can help identify success metrics early in the process and plan what data collection will be necessary in advance.
If you delay engaging a performance analyst until just before a design is about to go live then everyone, including you, will be rushed to try and work out what needs to be done before release.
If you wait until after something has been released you will have already missed the opportunity to gain meaningful insights and it will be difficult, perhaps impossible, to retrospectively plan effective success metrics.
Examples of when to engage
Exactly how you engage with your performance analyst will depend on how your individual team approaches work, but points in which to invite a performance analyst include when you:
- first receive a 'ticket' to start work on a new feature
- are developing hypotheses or examining user needs
- are sketching or wire-framing early design ideas
- analyse or present the outputs of user research
- finalise a new design or prototype for a user journey
- know a ticket is being prepared for the developers to implement a new design
What happens after you engage
You'll talk about what you're delivering and work out how best to measure performance. How you do this is up to you and the performance analyst - it could include conversations, workshops, prototype walkthroughs or sharing design documentation.
Once those success measures are agreed the performance analyst will source the data. If data is not immediately availably they'll either:
- raise a request for a technical build to collect it
- raise a request for a manual data collection
- raise a risk to the team that insight cannot be gathered to measure the feature
When enough data has been collected the performance analyst will report the impact of the change back to the team.
Giving and receiving feedback
GDS publish a series of posters on critique best practice. We follow this guidance in DWP but we’ve added further context and guidance based on our experience.
We start with the belief that everyone is doing the best they can with what they have to work with.
When giving feedback on work...
Talk about the work, not the person
Don’t make it personal.
Adjust your language to say things like “this could be” instead of “you haven’t done this”.
Be specific
Don’t make vague or confusing comments.
Explain your reasoning, clarify what you mean and give examples. This will make it easier for the other person to make changes based on your feedback.
Be constructive
Don’t give personal opinions, such as “I don’t like this”.
It’s likely you won’t be the user, so it doesn’t matter if you don’t like it.
Ask the person who did the work if they’ve tried alternative approaches instead.
When asking for feedback on work...
Give some background
You’ll get better feedback on your work if you help others understand why you’ve done it.
Explain who your users are, what their needs are and what you’re trying to achieve.
Make sure you include any constraints your working with.
Its a key skill not to over explain the background and use up all of your time.
Say exactly what you want feedback on
Tell people what you want to find out. This will help them focus their feedback, rather than make general comments about the work.
When receiving feedback on work...
Don’t talk too much
After you’ve explained the background to the work, let people review it in their own time. Try not to over-explain anything. Listen to what they have to say.
Take notes
You’ll need to remember what was said and why. If you can, ask someone else to take notes for you. This will help you focus on the conversation.
Documenting design decisions
As interaction designers it is important that we document design decisions around our work.
In terms of the essential documentation, as a community we agreed that the following would be the best starting point:
- Visualised User Journey Flows
- Versioned prototype with links to UR, WIP and hypotheses
- Summary (headlines) of what’s changed and why with design
- Project stage
- Links to decision logs / UR hypotheses
Working with Service Designers
How does the role of a Service Designer differ from the role of an Interaction Designer?
The best way to articulate the difference between the two roles is that Service Designers are more focused on breadth, whilst Interaction Designers are more focused on detail - in other words, they have different levels of 'zoom'.
Whilst Interaction Designers will tend to look at a single journey or zoomed in interaction, Service Designers tend to look across multiple.
Interaction Designers also tend to have more of a focus on digital channels than Service Designers, who will be more focused on all of the channels a user might use.
Interaction Designers focus more on things like accessibility, conformity to design patterns etc.
Service Designers on the other hand will be more focused on acting as the conduit between the service team and other areas such as operations, other benefits and other organisations.
Interaction Designers will ask: What's the best way for someone to claim their state pension at DWP?
Service Designers will ask: How would getting your state pension work with another service or another organisation?
When are Interaction Designers supposed to work with a Service Designer?
Mostly in pre-discovery, discovery and alpha, when you're trying to contextualise a transaction, benefit or sub-service within a wider landscape.
What should Interaction Designers work with a Service Designer on?
- Visualising current problems that a user is facing
- Framing problems, why are we doing this work, what outcomes will a user get?
- Envisioning how a user's journey will fit with back-end processes, operational processes, other benefits etc.
- Persona building, workshops, service mapping
- User journey mapping
- Service blueprinting (to work out aspects of the blueprint)
How can Service Design help me as an Interaction Designer?
Helps Interaction Designers understand the context of their journey in a wider landscape – i.e., if you're designing a chair, what's the room it sits in?
Service Designers can support Interaction Designers on where to join up with other parts of the organisation.
They can also help surface cross overs and possible areas for failure early on in a project to help mitigate these early.
Service Designers can also help identify similar work or activities undertaken elsewhere in the organisation that Interaction Designers can learn from or replicate in their area.