We’ve made our design patterns publicly available in the Service Design Manual, where anyone can take GOV.UK elements and combine them to meet common user needs when creating public services.
We've tested our design patterns
Our design patterns have been tested with people using our services. This means we’re basing our design decisions on evidence, not speculation and assumption.
We're in constant dialogue with the team
At GDS, user researchers and designers have a symbiotic relationship. GDS user researcher, John Waterworth wrote about this in his post, From chickens to pigs:
We sit with the team day to day, soaking up background information, joining in discussions and continually adapting and refining our research questions. We do everything we can to make the insights we’ve gathered from users part of the team DNA.
When creating design patterns, our user researchers are in constant dialogue with designers, developers and content designers regarding how elements and interactions have tested with users. Using this information, we refine, or completely change, the design patterns so that everything we’re designing is answering user needs.
An example: date of birth
Joe Lanman, an Interaction Designer at GDS, wrote about this in his post, Asking for a date of birth. Joe describes how the Register to vote project tested different design patterns for inputting a date of birth.
We posted the findings and recommendations, generated from this research, on our design patterns hackpad. We also updated the Service Design Manual so that anyone else designing government services can use tried and tested methods.
You should get involved too
We’re always looking to make the design patterns better for our users. We want to know what works and what doesn’t.
If you know of a better approach to a particular design pattern, or have seen something in user research and want to contribute to the conversation, get involved with the design patterns hackpad.
Keep in touch. Sign up to email updates from this blog. Follow Will on Twitter.