Lately, Louise Downe and I have been working with the DVLA to think about what services and user journeys really are, and how we can build teams around them to design and make them. To do that, we have to return to user needs, and epics are an incredibly helpful way to do that. I want to talk a bit about what epics are, and why they’re so useful.
Services let you do something
First, it’s worth thinking about what a service actually is. Really, it’s just a thing which lets you do something. For DVLA, that something could be learning to drive. The form of that service is the journey the user takes. It’s made up of content a user may want or need to read, and the transaction to get it done.
For learning to drive, the highway code is an example of content, and applying for your provisional driving license is an example of a transaction the user needs to get done. (There are others, too).
It’s no good thinking about transactions and content in silos. Teams must own the whole user journey for services to be as easy to use as possible.
What’s an epic?
Epics are simply high-level user needs. If you identify those, it’s much easier to organise and prioritise the work. That work might be something the user sees, like a change to a service, or it might be a change to the way things are done internally.
They’re not a GDS invention, but we’ve tailored them to our needs. Leisa Reichelt came up with these three tests. For a user need to qualify as an epic, the answer to all of these must be yes:
- If you showed this need to a real end user, would they recognise it as their own need?
User needs should use the same words that a real user would use. - Does it help you organise and prioritise the work for your project?
User needs need to be specific/granular enough to help you on this project. - Does the need describe the problem, not the solution?
User needs should not describe a solution. They should be agnostic of the current mode of delivery or "branding" of services. They should remain the same over time and not reference technology, existing service names, or current government terminology.
Once we’ve identified an epic, we write a short document which:
- describes the user need
- identifies the possible end points of the user journey
- identifies related needs and services
- lists the types of users the need could apply to
- identifies the relevant internal users, people within the organisation whose work relates to the need
Then, we develop a user strategy which lists all the related problems users face, the challenges posed to the organisation, and the criteria we need to measure to make sure those problems and challenges are solved, and write a delivery plan for meeting the high-level user need.
We call the document an epic too. And though you might handle yours differently, the important thing is for it to set out the problems that need to be fixed so teams can explore them, and decide what they want to work on.
Why you should use them
With DVLA, we worked up an epic around this user need:
“As a user with a medical condition, I need to know whether it affects my driving, so that I can continue to drive safely or stop if I'm unsafe.”
By analysing that need, we were able to identify specific, quantifiable targets for improvement, and write a delivery plan for securing seed funding, identifying the discovery-stage user research that needs to happen, and listing our options for action.
It doesn’t set out the whole answer to the problem. Without more user research it’s too early to do that. But it does make it crystal clear what we’re going to do next.
It’s helpful to think of an epic as a live document. It doesn’t have to capture everything at the first attempt. You can add problems as they’re identified, and work can be re-prioritised as work gets done.
We’ve found that epics are a great way to simplify and breakdown programmes of work. They end up working as a sort of “funding umbrella”, helping teams allocate the time and resources to make sure the most important discovery work gets done. You can also see where and why user journeys begin and end, and you can see how how all the epics fit together across your whole organisation.
Finally, they’re a great way to let the organisation know what you’re doing for users, and they help us be open about the work we’re doing.
If you work in government service design, I can’t recommend epics highly enough.
