UK Government departments and agencies are now following the GDS Service Design Manual when they design (or redesign) their digital services.
And the key (first) step in the life-cycle of any new service is a dedicated Discovery phase, before any progression to an Alpha version.
The idea is to take a little bit of time (4-8 weeks) to get to heart of what the service actually needs to do:
- develop a better (and shared) understanding of who the service’s users are – their needs, context, motivations, and behaviours
- understand how user needs are currently met (or not)
- challenge and validate assumptions about the users
- understand the tech and policy related constraints for the service
- explore the options for a service that satisfies both user and business needs
- begin to know what success looks like for such a service and how to measure it
- approach an Alpha phase with a clear, shared scope of the service
Thinking about running an in-house Discovery?
The GDS Service Design Manual’s Discovery section should be your first port of call. It’s full of guidance on how to run a successful Discovery phase.
But if you want to learn some hard-won lessons on how to get the most possible value from your next Discovery keep reading…
Mitigate the risks of running a discovery in-house
There are several advantages of running your own in-house Discovery phase:
- it’s already your job to think about how best to serve your users
- you (presumably) know your subject matter better than anyone else
- you (hopefully) have a close relationship with stakeholders
- and you have access to the stats and other research you need
However, if you decide to conduct a Discovery as an in-house team, there are risks to be mindful of:
Be willing to challenge your assumptions and internal bias
Organisations have a habit of collectively believing something to be true without much evidence to back it up, especially when it comes to the needs of service users.
Don’t blindly accept those assumptions during the Discovery. This is the time to truly challenge and validate them. Approach with fresh eyes and ask “why?” about everything.
Validate those assumptions and everyone can design the service with confidence.
Of course, many assumptions about user needs exist for good reason and will be true and a good Discovery will validate that.
Defy the inevitable
If the boss goes around telling everyone that you need a new service that does X before you truly know what the service needs to do (or if it even needs to exist!), then it can become an inevitable outcome with a momentum that is hard to stop.
This is how money and time get wasted. No one takes the time / has the confidence / or the authority to push back and say “but that’s not what our users actually need.”
The in-house team works consciously and unconsciously hard to build a case during Discovery to back up that conclusion because they understandably want to please the boss and play along.
But the default position should be this question: “why don’t we need this service”. Like a good scientist trying to test their hypothesis to breaking point, a Discovery should be attempting to do the same.
It is a perfectly ideal conclusion to reach at the end of the Discovery phase, that the service is not required, and not to proceed to an Alpha. This is the right and mature thing to do, especially with so much public money on the line.
Your professional pride will take a hit
Chances are your in-house Discovery team will be looking into an existing service they are fully or partially responsible for.
Admitting it needs improvement can be frustrating and hard to accept. For some it will feel like an admission of failure and a challenge to their authority and ability. There will be understandable reluctance to draw attention to it.
But if the Discovery isn’t allowed to explore and identify the good and the bad, it is impossible to identify the gaps that a new service should address.
Set expectations amongst the team and stakeholders that this is about the opportunity to make things better for users and not about pointing the finger.
Don’t be blind to your own blind spots
We are not best placed to see the faults in ourselves or in our own work.
An existing service may have longstanding issues because nobody in-house has the the knowledge or experience to see them.
Unfortunately, an in-house Discovery phase is only as good as the people conducting it and any blind spots in their collective knowledge will limit the effectiveness of the Discovery.
Observing usability testing of the current service is an excellent way to see things with fresh eyes from the perspective of users.
Also consider bringing in experienced outsiders to complement the in-house team with their objectivity and knowledge of industry best practice.
Lack of discovery skills and experience
An effective Discovery requires a range of professional skills and techniques: usability testing, data analysis, workshop facilitation, survey design, technical review, card sorting and high-level site architecture design…
These may not be the core skills of the in-house team as they won’t be primarily employed to run Discoveries.
Call in the experts to support your in-house team on their weak points and ensure they are coached up to do it for themselves next time.
Don’t assume you need a new service
The primary goal of a Discovery is to validate the need of potential digital service. The ideal conclusion should be that you don’t need to spend money and time on a new service.
An objective and thorough Discovery may conclude:
- No such service required – insufficient user need to meet or such needs are already being adequately met by your organisation or elsewhere
- New service not yet required – the existing service is sufficient, or will be with some modest improvements, and does not need to be re-designed and built yet
- A different service is appropriate – your initial idea / assumption for the new service is off the mark and the validated user needs would be better met in a different way
Tip: If you aren’t doing the Discovery in-house, be wary of Discovery suppliers and partners that stand to profit from the decision to build a new service.
Don’t rush it. Do it properly
If a job is worth doing, then it is worth doing well, and GDS recommend 4 to 8 weeks to do a Discovery well.
When you set those weeks against the wider life-cycle of a digital service, that really isn’t much time.
If your new service is a website or intranet, it is likely to exist for at least three years before the next big redesign.
You will feel the benefit of taking the relatively short time to run a comprehensive Discovery every single day over those years.
If you are looking into an entire website, take that full time (eight weeks). There is a lot to consider. A more nuanced service might be closer to four weeks.
You need the space to reflect on what you are learning at each stage of the Discovery. Move too fast and you won’t be able to react and follow interesting leads.
Of course a specialist Discovery supplier will be able to achieve more in that time as they are experienced at performing all the recommended activities.
Validate personas with qualitative and quantitative evidence
In-house teams have a habit of creating service user persona profiles that fit their established view of the world (see warning about challenging assumptions above).
The scenarios, behaviours, and needs captured in the profiles have to be based on more than assumption or poor decisions will be made about the design of the service later on.
To ensure your personas are accurate and worth using:
- develop them out of interviews and direct consultation with actual service users – not from internal stakeholders alone
- consult with colleagues that regularly deal directly with your end users – call centre staff for example know a lot about what users actually need
- review available data about users and their behaviour such as web stats, call centre stats, feedback correspondence
- validate assertions on the personas with larger surveys to quantify and prioritise what is genuinely most important
Put content in the spotlight
Regrettably content is often overlooked during the design of digital services, but this is the opportunity to learn the lessons that will help ensure the new service has good quality, sustainable content that meets user needs.
Try to answer these questions to your Discovery phase:
- What content does the existing service already have (volume, type, source)?
- Who owns the service’s content?
- How is existing content performing (stats, accuracy, relevance, quality)?
- What are the challenges for maintaining the current and future content for the service?
- Take the time to conduct a thorough content audit to truly get to the bottom of these key questions.
Beef up your in-house discovery skills
Your new digital service should exist in a state of continuous improvement (long after it goes Live). That means using Discovery skills and techniques over the months and years to identify and address issues.
Conducting usability testing sessions and analysing web stats are two obvious examples.
Consider calling in a specialist Discovery service supplier to coach your team and plug weak areas so they don’t let your service down.
Hopefully these pointers will get you in the right mindset to run successful Discovery phases.
Let us know how you get on and please share your best tips for a successful Discovery.
The Lagom Discovery Service
Lagom Strategy specialises in working with in-house teams to deliver first-rate Discovery phases for digital services that need to meet the UK Government’s Digital by Default Standards.
They’ll ensure you can make a smart and informed decision on if and how to proceed to an Alpha service stage before you waste time and money going in the wrong direction. Find out more about their Discovery Service.
- Government Digital Service
- Government Digital Service for visual style. Original image modified by Lagom Strategy to visualise relative lengths of time for each phase for a typical digital service.
This post was originally published on the Lagom Strategy blog.