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...

Reasons not to build a service

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:

• It costs money, lots of it - a big upfront cost to build it, and an ongoing cost to maintain it
• Can take a long time - half a year by the time you’ve procured a supplier, run a Discovery, built an Alpha, and then a Beta
• It will be a big distraction for your in-house colleagues from their other priorities
• Never a silver bullet - building something new won’t automatically resolve other issues around resources, internal process, skills and governance

A good business case considers and articulates each of these reasons carefully. And a good Discovery phase can give you just what you need.

Prove there is a genuine and significant user 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:

• Explore and define the service’s audience (called user types)
• Run usability testing with real target users on the existing service
• Analytics review - most un/popular content, top search terms etc
• Interview current and prospective service users
• Talk with people in your organisation that have direct contact with the service users, e.g. call centre staff
• Develop personas and user flows for the primary user types - with direct input of actual users
• Run user surveys to validate user needs with a larger, quantitative sample

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:

• Persona profiles that articulate the context, needs, motivations, and behaviour of the service’s target users
• Analysis of web stats and user surveys with extracted insights and recommendations
• A prioritised backlog of user stories to articulate which needs the service must meet

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:

• How many people (users) actually have these needs, and how often? Is that enough to worry about or to be a priority?
• Are these needs really more important than other user needs you know about (perhaps met by other services)?
• Are you already meeting these user needs on the current service? It might be doing a better job than first thought or just needs some tweaking
• Is it really for you to meet these needs?
• Are these needs already being met by someone else?

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.

Consider hiring in some discovery experts

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:

• They have the skills and experience to get the most value out of each discovery activity
• Give an independent and objective voice can win over internal skeptics (and are harder to ignore)
• Give full focus to the discovery (which is hard for in-house teams with their other responsibilities)
• Quickly cover all the activities in a comprehensive discovery
• advise you how to approach your business case

Is there sufficient user need to proceed?

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.

Make the financial case

Most things boil down to money, so a good discovery needs to begin to answer these questions:

1. How much does the current service cost us?

Talk to the people that run the current service to get some numbers against these items:

• Licenses - for the CMS or other propriety software the service is dependent on
• Hosting
• Supplier and contractor fees for maintenance and updates - do you make one-off requests and payments or have a support contract?

What about offline services?

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?

2. Where can the savings be made?

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:

• We won’t continue to pay expensive licences (with a move to open source Software or to cheaper cloud based tools)
• We can significantly reduce our current hosting fees by switching
• Our in-house Tech Team will be able to update the service’s functionality (instead of paying our current expensive supplier)
• Staff will find it much simpler to update content which saves time

What about offline services?

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.

3. How much money could we save?

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:

• How much quicker could it be for users to complete common tasks on the service? (run usability tests to explore this)
• How much quicker will it be to update and publish new content on the service?
• How much quicker will it be to make functional changes to the service?
• How much will we save if we don’t need to pay for these licenses (opting for open source technologies for example)?
• Are we paying too much for our hosting?

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.

Take the time to benchmark the current service

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.

Calculating cost per transaction for your 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.

4. How much money will the service cost to build and maintain?

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.

Prove the new service can be sustained

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:

• Does the service currently have a service manager (or equivalent)?
• Are they [the service manager] pro-active? Is it in their job description? How much time can they dedicate to it?
• Do they and the wider team have the necessary skills to run the service?
• Is the content in a good state (accurate, relevant, up to date)?
• Does all the content have assigned, and pro-active owners to maintain it?
• Does any sort of content review and archiving policy exist?
• Will there be additional resources available to support the service?
• Any upcoming recruitment round planned?
• Will more services be introduced / decommissioned that will affect the resourcing for this service?
• Is the service’s analytics being regularly reviewed (a basic install of Google Analytics is not sufficient)?

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:

• Employ a dedicated service manager to lead the build phases and take ongoing ownership in Live
• Implement a content review policy with dedicated content owners
• Implement an evaluation plan with KPIs to monitor and improve the service

Getting ready for successful digital transformation and content delivery

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.