Start by understanding user goals and problems
Understand what users really need and what the problems are before jumping to solutions. We work to understand what users need to achieve rather than what they think they want or prefer. This means we can design solutions to solve the problem simply and effectively. Discovery research helps get to the root of what is causing frustration or delay, including problems users don’t know about, such as how our systems work. Talking with real people and mapping their experience helps us design services that work in the real world.
Design with everyone
It’s best when the people delivering, using, designing, and building services work together from the start. They can share the process to define the problems and design solutions together. We work with all council services to build common solutions to similar problems. This reduces confusion for the user and cost for the council. We collaborate, share open-source code, and publish our research findings for everyone to see. By working across service areas, we are able to help different services create one consistent digital offering with a similar look and feel across the council. We invite services to work with us to find ways to make things better for their users.
Design for everyone
Inclusion is central to our work, not a nice to have addition. All users should be able to access and understand our services without difficulty. Services should be accessible irrespective of a user’s digital experience, disability, or literacy level. We aim to include users with diverse needs and capabilities in every stage of our design process. It’s the law to make our website and apps accessible for people with disabilities, but research also shows that designing for everyone and using simple, plain English is best for everyone, including experts.
Start small and keep improving
We advocate for starting small with a minimal viable product and iterating as we go. This means that new features are only added when users identify they’re needed and ideas are quickly checked with prototypes or a beta phase before too much has been invested. We believe that the Government Digital Service (GDS) agile delivery approach to building digital services avoids making costly mistakes that can’t easily be changed. Delivering a digital service should be an ongoing process where we make changes based on direct feedback and services are open to change. We can still adapt and improve our services, even if we’ve provided it for a long time.
Build with, and on, the evidence
We are not our users. We build our understanding of users’ behaviours and needs by collecting and analysing quantitative and qualitative data, trying to avoid assumptions about who they are or what they need. We test our solutions with users to validate that they are understandable and intuitive.
Good quality data is the best basis for good quality decision making. As well as using existing data to understand our users, we are advocates for iteratively improving data quality wherever possible. We publish our findings and design decisions to add to the available evidence.
Zoom in, zoom out
We need to zoom in to get the basics right, for our services to work well and for users to trust us. Questions must be clear, links and phone numbers must work, communication should be proactive, and information needs to be on webpages rather than inaccessible PDF documents. These details determine whether users can get a task done. In Good Services, Lou Downe argues that public services often fail on these small things.
We also need to zoom out and look at a whole user journey to understand the context and how users come to our service. We aim to understand our users’ goals so that we design services that work together to resolve a complete problem, without dead ends or sending people round in circles.
Design it, don’t just make it
We aim to make complex services easy to use. Clear and accessible services are designed, they don’t occur by chance. Design involves doing the hard work of understanding and balancing the complexities of user needs, human cognition, organisational systems, and technological constraints, to ensure that services are simple and intuitive. If we build products instead of designing them, they may unintentionally reflect biases and the understanding of the builder and may not function as a user expects.
Keep it simple
Most of our users would rather be doing something else. They come to us to complete tasks they may have no choice about and may have no alternative place to go to. Our organisation can be complex and it’s our job to make sure our digital services make it easier to interact with. To help keep things simple and consistent, we try to re-use design patterns and code where possible and design our content to help users complete their tasks. Users should be able to access one consistent digital offering with a similar look and feel across the council.
Use our content style guide and design system. They are in line with the Government style guide, design principles, and service standard. These are based on lots of user research and establish good practice in our sector. This includes presenting and asking for information in plain English.
Sometimes, new research changes our understanding. User research may present us with stories, journeys, and needs we didn’t expect. We may discover we have been working on an old assumption that’s no longer fit for purpose. The best solution might be one that we didn’t expect. We may need to think about changing internal processes, iterating our designs, or making changes to things other than a website or program.
We should stay curious about the people who use our services and open minded about our solutions.