WIREDGOV

Blog posted by: Eliot Hill, 7 September 2018 – Categories: Agile, Design.

When we’re designing a service, there’s lots we need to understand and we have lots of questions. We don’t always find answers to these questions quickly.

We often face short deadlines and need to deliver services despite not knowing all the answers. In such cases, how can we still deliver something that users will be able to use?

Making assumptions

As designers, we take time to understand users, processes, policy and operations. We can then hypothesise about the best approach to design. User researchers put our initial designs to the test to find out what works and what does not.

When deadlines are much shorter, there might be fewer rounds of research and iterations, so our assumptions might carry more risk.

Interactions have different levels of risk

Risks will always exist when we choose one thing over another. Deciding which thing to choose will be determined by different factors – professional experience, usability research, a collective public knowledge, and shared experiences of all these across the government community, or through existing design patterns.

Confidence can rise and fall in the course of a user journey, depending on what we know at that time.

That's why we’ve started to use an indicator to communicate the ‘relative confidence’ we have in a particular part of a user journey at a particular time.

This helps the team, and the wider organisation, understand and prioritise what needs more work.

How we measure risk

Our confidence relates to the level of risk. These tags are high (colour coded red), medium (yellow) and low (green). They’re based on 3 things:

1. The range of participants we’ve researched with.
2. The design pattern’s prevalence – who else uses it?
3. Our understanding of the question, why we're asking it and how we use it.

These tags quickly illustrate how confident we are with an interaction – what parts of the service should not change, could change or definitely will change.

They also remind us what we need to revisit and prioritise what we work on next.

Grouping the designs and iterations into milestones also helps snapshot what was delivered, how it’s intended to look and what will be included next.

This system is an art rather than a science and I’d love to hear ways other teams are documenting design.

You may also be interested in:

• Design ops: how we design Home Office services at scale

Moving towards Continuous Delivery at DDaT