I’ve been involved with a lot of GOV.UK Service Standard assessments. The first part of the assessment is when the team has 20 minutes to demo the service.

When a team demos their service well, they can:

• help the assessment team understand what exactly the service is so that they can focus their questions
• reassure the panel that the team understands the full journey as well as most valuable journey to get right
• save time by starting to give evidence about user research, design decisions, and analytics meaning those sections can be more about a deep dive

However I haven’t seen this happen very often. This may be in part because there are no examples online of how to do this.

Structuring a service demo

I’d suggest that a good service demo has the following sections:

1. Background – scene setting
2. The cast – your users
3. The lead (or leads) – the primary user(s)
4. The setup – how they get to the service
5. The action – using the service
6. The payoff – What happens next

1. Background – scene setting

What’s the reason that this service is even being worked on? Crafting a short (2 minute maximum) summary of the policy intent for your service helps everyone start from the same footing.

Depending on the reasons you’re working on your service, you may explain :

• the new or changed policy – if you’re working on a service because of a policy related change
• the policy in general – if you’re replacing a legacy system

If your service is part of a bigger system then this may be a chance to show a map to help the panel understand where yours sits. Just remember that this is just setup, you want to get to showing your service!

This is also a chance to mention the overarching user need before you switch from the context to…

2. The cast – your users

Show the different types of people using your service. It could be personas, behaviours, or user types – more than anything it’s about showing some breadth and giving a hint that you know who uses your service. It can be as simple as just showing an image, you’ll have time to talk about this later.

3. The lead (or leads) – the primary user(s)

Introduce the person we’ll be following through today for the journey. Who are they? What lens that’s most useful to demonstrate the service?

On some services this will be the most common journey. For example, when I worked on Inheritance Tax the service manager chose a user dealing with their mum’s fairly simple estate, since this was representative of most of our service users.

However, for others it may be a stress journey that is most important to get right. On a feedback related service I assessed the key journey was whistleblowing as dealing with confidentiality for this user group would also benefit for other user types.

If you’re developing a system for both citizens and caseworkers, you may want to point out the two leads, but then only focus on the first person. You can then talk about the second person in more detail when they appear in the story.

4. The setup – how they get to the service

No one magically gets to a start page. What made your person need to interact with your service? How did the find out – did they get a leaflet, ring up, talk to someone or use google? Once you know what this journey will be, see if there are ways to show it rather than just talk about it. For example, I’ve mocked up proposed government emails and tweets, letter, and even google search results. I’ve also altered existing guidance pages to show what it would look like were the service available. Ideally you might even have these artefacts to hand if you’ve been doing user research on them.

If you have a lot of artefacts in different places it can be useful to have one person assigned to drive the demo, even if they’re not talking. Someone may need to have a prototype, live service, and other artefacts ready, and be comfortable with switching between them.

5. The action – using the service

How does your person use the service? What do they fill in and what don’t they fill in? This is an opportunity to bring data to life. For example, on Inheritance Tax the user didn’t complete a complex gifts section because they — like over 90% of people using the service—answered ‘no’ to a particular question.

I recommend getting your designers, user researcher and performance analyst together to agree the details of what you will and won’t show, and potentially create a shared crib sheet with all the details (for example, addresses, values and so on). This may seem like a lot of work, but will make sure you use details that everyone feels are appropriate. On larger services it also means that whoever is showing screens can pre-empt the presenter if needed – for example if the presenter says “they add their address” everyone will know that the person showing screens won’t accidentally put in a Scottish address that shows a ‘not eligible’ screen and so on.

Deciding the details can also give you a chance to highlight key successes, particularly when someone has to do some manual tasks just to get to the next screen. For example, with Inheritance Tax when there were a lot of sections to answer ‘no’, the presenter was able to use the time to talk about using analytics to learn that most people said no to these sections.

6. The payoff – what happens next

Just as the start page isn’t the start of a user’s journey, most of the time getting a confirmation page isn’t the end. What’s the actual end? On some services I’ve had to show a prototype of a confirmation page since we couldn’t use the developed service to show it, and I’ve also shown example emails and letters.

As mentioned earlier, for some service teams this may be the start of a second demo by a different person who processes the case. I haven’t seen this demoed much, let alone well, but would suggest considering a second loop with the person, though potentially with slightly less about finding the internal service (while they may need to have been trained and told about the service, that is too much to tell in one narrative and again can be talked about in more detail later).

Now… practice!

I strongly recommend that a team do at least one run through of their demo. This is a chance for the team to edit (get rid of tangents, there’s time later to talk about successes) and then looking for opportunities to make the actual service both realistic and impressive. The service manager for Inheritance Tax managed to demonstrate a service of potentially 200 screens in 20 minutes (partly be realising that the most common journey was far simpler, but also from a lot of practice including tightening up the scene setting).

Over to you

I’m interested hearing your feedback on this framework, and am interested in working with a team to make a case study.