What is Discovery?
Discovery is where we discover. It sounds trite but it’s true. Discovery is where we explore how government services might be presented online so that people can do what they need to do, without having to understand how government works.
I think the Discovery stage is one of the most important – but probably the least understood – in the whole design process. It can be tempting to jump in and just start building something, but before you do, you need to create a picture of what users need – not what you think they need.
We need to make sure that we have an accurate, human-centred (not project-centred) understanding of our users and what they want from us. For example, people don’t renew their passport because they want to, they renew because they have to so they can travel abroad or prove who they are. Understanding the context of why people are engaging with us helps us design better services.
We recently completed a Discovery stage for the GOV.AU prototype. Here’s what we did to make sure we got our work off to a good start:
Focus on user research
Understanding your users is the most important thing in Discovery and will take the most effort. Make sure you have a full-time embedded user researcher in your team from day one – ideally someone who will stay with the project into Alpha – get out in the field with them as quickly as possible to meet and observe end users.
You should be doing mostly qualitative user research, and ideally in the context of use (their home or workplace for example). Don’t just gather together all the research that has ever been done before… this is useful, but it doesn’t take the place of your team doing hands on research.
Understand the big picture
Make sure you understand the wider context for your project - what is the actual thing that people are doing when they encounter your service (eg. they’re not just registering their company name, they’re starting a business). Pay attention to the role that others are playing in the user’s broader journey – these influencers might include other parts of government or commercial or charitable organisations.
You can make journey maps (based on real customer experiences, not ideal workflows), maps of user needs, Wardley maps, and maps of the service environment (this is a great example from the UK) Make sure that you don’t need domain knowledge or jargon to understand these maps, and you’ll create a great basis to ensure anyone working in or with the team can get a shared understanding quickly.
Don’t start designing just yet!
It’s tempting to start designing and building things quickly. That’s great, but try not to validate your early ideas too fast or before you’ve developed a good understanding of the problems and issues.
Remember, Discovery is for discovering, not validating. The time for designing and making things is Alpha, and that’s coming soon!