Design

Getting the scope of your transaction right

Give feedback about this page

From:
Design community

Scoping your transaction means deciding what the transaction does and doesn’t 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 won’t be obvious what problem it’s solving. And users won’t be able to get straight to the task they need to complete.

If the scope is too narrow, the transaction won’t fully solve the user’s problem, meaning they don’t 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 would be to zoom out, look at what the user’s trying to do and break up 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 don’t 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:

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 don’t 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.

Don’t try to address more than one task per transaction

Don’t bring tasks together into one transaction for the sake of it, though - especially if they’re not related, or users don’t 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 won’t be able to work out what it’s for.

For example, the Environment Agency (EA) is breaking 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 can’t solve a recognisable problem without bringing them together into one transaction

Don’t let organisational structures or technical choices dictate the shape of your transaction

Users shouldn’t 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 don’t 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 won’t find it if it’s hidden inside a transactional service, because content inside services doesn’t 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 isn’t an integral part of the transaction, publish it as guidance on GOV.UK so it’s easy to find.

From:
Design community
Last updated
over 5 years ago
Last update:

Updated to reflect the fact that this guidance covers the scoping of transactions, rather than whole services.

  1. Updated guidance on getting service scope right, when to put information inside a transaction

  2. Guidance first published