Getting the scope of your transaction right
Scoping your transaction means deciding what the transaction does and does not do, and which problem it solves for users.
If you scope your transaction too broadly or try to make it do too many things, it will not be obvious what problem it’s solving. Users will not able to get straight to the task they need to complete.
If the scope is too narrow, the transaction will not fully solve the user’s problem, meaning they do not get the outcome they need.
How transactions join up with a user’s wider journey
While transactions are certainly helpful in their own right, they’re often most useful because they help users work towards completing a bigger goal. For example, booking a theory test is only helpful because it helps you work towards learning to drive.
This means it’s crucial that a transaction joins up coherently with any related subtasks, so that users can do the thing they’re trying to do quickly and easily.
The ideal way to do this is to zoom out, look at what the user is trying to do, and break the journey into subtasks that make sense from their perspective. There’s guidance to help you map and explore user journeys in this way.
Most teams do not get to take this broad view, though. Instead, they’re given something to work on and have to scope it so it forms a coherent part of the user’s wider journey. This guidance will help you do that.
Understand where your transaction fits in the user’s journey
Unless there’s an existing map or service landscape you can use, it’s useful to map out the user’s overall journey when trying to scope your transaction. This will help you see all the tasks a user needs to complete and scope a transaction that makes sense as part of that overall journey.
You could use a:
- user journey map (sometimes called an ‘experience map’) to show all the tasks a user has to complete to do the thing they’re trying to do - read about using user journey maps in government
- service landscape to show everything from both the user and organisation’s perspective - find out how the Ministry of Justice uses service landscapes
Make sure everyone can edit any digital versions you make - something like a spreadsheet or slide deck works well.
Scope things how users see them - not how government sees them
Transactions tend to be more intuitive when they reflect a task a user would recognise. This might mean it’s best to merge things that government views as separate tasks.
For example, students can apply for a grant, loan and a bursary to help pay for their higher education.
Government views these as separate tasks, but to the user they’re part of the same thing: paying for university.
So bringing those ‘separate’ tasks into a single transaction makes sense: it solves a problem a user would recognise. It also means they do not have to provide government with the same information several times.
Always pay attention to how users talk about what they’re trying to do in research sessions. This will help you build something that makes sense to them.
Do one task per transaction
Do not bring tasks together into one transaction for the sake of it, though - especially if they’re not related, or users do not think of them as part of the same thing.
Users generally want to complete one government task at a time - so there’s usually no advantage in making transactions serve more than one purpose.
And if you try to address several tasks within one transaction, you’ll struggle to give it a descriptive name and users will not be able to work out what it’s for.
For example, the Environment Agency (EA) broke the ‘What’s in your backyard?’ service into several smaller transactions. Doing things this way lets the user access the thing they need directly, and makes it easy to give the transactions a descriptive name - for example, ‘Sign up for flood warnings’.
So start with one transaction per task. And only bring tasks together into a single transaction if:
- you see in research that users think of a group of tasks as part of the same thing, even though government sees them as separate
- you cannot solve a recognisable problem without bringing them together into one transaction
Do not let organisational structures or technical choices dictate the shape of your transaction
Users should not have to understand the structure of government to access services. So it’s important to scope transactions based on tasks rather than the organisations providing them.
And do not let technical choices dictate the shape of your service. For example, services that need it can use a common authentication system without necessarily being brought together into a user account.
If you start with separate transactions, you can always bring them together later. It’s usually much harder to do it the other way around.
Only put information inside a transaction if it needs to be there
It’s important that users can find the information they need. They will not find it if it’s hidden inside a transactional service, because content inside services does not come up in search results.
So only put information inside a transaction if it’s an integral part of the transaction.
For example, you might see in user research that a user is struggling with a particular question. It makes sense to provide more information at this point in the transaction: just enough to let the user answer the question. You’re providing information at the point of need.
If the information is not an integral part of the transaction, publish it as guidance on GOV.UK so it’s easy to find.
Updates to this page
-
Updated to reflect the fact that this guidance covers the scoping of transactions, rather than whole services.
-
Updated guidance on getting service scope right, when to put information inside a transaction
-
Guidance first published