Design

Getting the scope of your transaction right

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 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 -
  • service landscape to show everything from both the user and organisation바카라 사이트™s perspective -

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.

바카라 사이트 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) 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 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 바카라 사이트 so it바카라 사이트™s easy to find.

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