Building or re-designing a digital service is always a big undertaking, and you are usually required to pull together a business case for it. Which is fair enough. The answers and insights from a discovery phase can be extracted into your business case with demonstrable thought and rigour.
This post's advice is mainly for the scenario of re-designing an existing digital service, but still relevant if you're building a brand-new digital service, perhaps to improve on a current offline, manual process / service, e.g. submitting a paper-based order form application.
But first things first...
I know you are keen to build something great, but let’s take a minute to look at why you should NOT build a digital service:
A good business case considers and articulates each of these reasons carefully. And a good Discovery phase can give you just what you need.
Assuming there is a user need for your proposed digital service is no longer good enough. The UK Government’s Digital by Default Standards are very keen on this. It is Standard number one on the list!Fortunately, a good discovery will get you to the heart of this question and a combination of these activities will help you to explore, identify, and validate the user needs:
The GDS Service Design Manual has fantastic guidance on how to perform all of these activities.By the end of the discovery phase you will have these valuable outputs to work with:
Once you have done this initial round of intense user research during the discovery phase you need to subject your findings to a bit of a grilling:
It is really hard not to be biased at this point, especially when you are getting answers you might not want to hear. But these are the sorts of questions you are going to be subjected to later, so better to get it straight now.
Some teams like to run the entire discovery in-house, but bringing in experts, such as seasoned user researchers, can be a great return on investment:
By the end of the discovery you should be much clearer on the user needs for the service and whether they are a sufficient priority.If they there is little user need and/or it isn’t a sufficient priority then you shouldn't proceed to an Alpha.Don’t see that as some sort of failing - it is a good thing. You will save a lot of money, time, and general heart-ache on a service that isn’t justified.And if there is a genuine and sufficient user need, you can be confident to proceed to an Alpha with user-centred gold to work into your business case and wider communication of the project.
Most things boil down to money, so a good discovery needs to begin to answer these questions:
Talk to the people that run the current service to get some numbers against these items:
If the current service is an offline, manual process such as a paper based order form service, you should still find out what it costs to operate. Mail costs? Staff time to process the forms?
Once you know what you are spending money on for the current service(and how much) you can begin to explore where and how savings can be made. Examples might include:
Again, focus on which bits of the manual service will no longer be required or could be scaled back by introducing a digital version of the service.
It goes without saying that it is better to put some numbers against these claims to show evidence for your case.So ask these sorts of questions during your Discovery and remember savings aren’t just measured by the dollar:
You will struggle to be specific at this point because you don’t know yet what the new service will actually be, but you will start to see patterns of what seems unreasonably high and what to focus on in the business case.
If it is difficult to update and publish content on the current site, consider observing and timing this so you have a benchmark to retest against if you build an Alpha and Beta service.I worked with a client that timed (benchmarked) how long it was taking for staff to update content on the digital service. It was a painfully slow process.They already knew how much it cost per hour to employ their salaried staff at each band, which meant they were able to calculate the monetary cost (waste!) of content updates. Quite a lot it turned out. That went straight into their business case.You could also record the time it takes for users to complete common tasks on the current service when you run usability tests.Word of caution: asking people to perform tasks they are familiar with will skew things. They will have overcome their initial stumbles and make the service user experience look better than it actually is.Watch out for that and try to test with people who are unfamiliar with the existing service.
GDS likes to measure the cost per transaction and then monitor that over the life-cycle of the service. Their guide tells you how.This is a killer metric for a business case if you can demonstrate (with some working out) the anticipated saving a new service will bring.
Realistically you can’t possibly know the answer to this question yet. You still don’t know what the service actually needs to be. And won’t have a really good idea until you have built an Alpha.But consider this: building a new service and maintaining it properly always costs serious money. As soon as you engage outside experts the bill will start ratcheting up with day rates for digital specialists ranging from £500 to 1,000.Talk through your discovery findings with some potential suppliers and they will be able to give you a stronger steer on the price to proceed to an Alpha and Beta. You can then work that into your business case.A good discovery will potentially reveal many “quick(er) wins” you can implement before you engage in a much larger, expensive redesign and build project.That might mean you can spend this year’s budget on something more pressing, but still make big steps to improve the service.So exhaust your “low hanging fruit” first and tell that story in your business case. Demonstrate that you aren’t naively throwing money at some silver bullet solution.
Building a digital service you can’t sustain longer-term is an expensive, time wasting, reputation damaging, and demoralising own goal. Great.But if you take the time to ask the right questions about your current service (and your other comparable services) you will be able to largely predict your ability (or not) to sustain a new service.Use the discovery phase to dig around these questions:
Building a new service will NOT solve underlying issues around sustainable governance.Pull through these insights from your discovery into the business case. Demonstrate your grasp of this challenge and what you intend to do about it to ensure any new service can be sustained.Steps could include:
When you submit a business case for a digital service you are putting your reputation on the line. You are staking a claim about the need for a new service and proposing the outline of a solution.You are asking your organisation to commit money, time and focus on this project.You really don’t want to get this wrong.Taking 4 to 8 weeks to run a thorough discovery that digs into everything we’ve briefly looked at here will give you that extra confidence.You will test and rehearse your own arguments before putting your head above the parapet. And most importantly, you will all be working towards the right thing.
Liam is Founder of Lagom Strategy, a UK consultancy specialising in digital user research and sustainable content strategy.
With over a decade of content production and strategy experience in the UK and Australia, Liam has built up a wealth of practical knowledge on how to put content back at the heart of web projects.
He has led content strategy work for many organisations including the Royal Air Force, UK Department of Health, the Australian Royal Flying Doctor Service and Vodafone Australia.
Liam was previously Senior UX Architect / Content Strategist with Sydney agency, Digital Eskimo, where he introduced and led the agency’s successful content strategy services. Before heading to Australia in 2009, Liam was a Web Producer at the UK Parliament and the Senior Web Editor at the UK Foreign Office.
Liam also has a Masters degree in Web Journalism.