伊人直播

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

If the scope is too narrow, the transaction won鈥檛 fully solve the user鈥檚 problem, meaning they don鈥檛 get the outcome they need.

How transactions join up with a user鈥檚 wider journey

While transactions are certainly helpful in their own right, they鈥檙e 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鈥檚 crucial that a transaction joins up coherently with any related subtasks, so that users can do the thing they鈥檙e trying to do quickly and easily.

The ideal way to do this would be to zoom out, look at what the user鈥檚 trying to do and break up the journey into subtasks that make sense from their perspective. There鈥檚 guidance to help you map and explore user journeys in this way.

Most teams don鈥檛 get to take this broad view, though. Instead, they鈥檙e given something to work on and have to scope it so it forms a coherent part of the user鈥檚 wider journey. This guidance will help you do that.

Understand where your transaction fits in the user鈥檚 journey

Unless there鈥檚 an existing map or service landscape you can use, it鈥檚 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 鈥榚xperience map鈥�) to show all the tasks a user has to complete to do the thing they鈥檙e trying to do -
• service landscape to show everything from both the user and organisation鈥檚 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鈥檚 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鈥檙e part of the same thing: paying for university.

So bringing those 鈥榮eparate鈥� tasks into a single transaction makes sense: it solves a problem a user would recognise. It also means they don鈥檛 have to provide government with the same information several times.

Always pay attention to how users talk about what they鈥檙e trying to do in research sessions. This will help you build something that makes sense to them.

Don鈥檛 try to address more than one task per transaction

Don鈥檛 bring tasks together into one transaction for the sake of it, though - especially if they鈥檙e not related, or users don鈥檛 think of them as part of the same thing.

Users generally want to complete one government task at a time - so there鈥檚 usually no advantage in making transactions serve more than one purpose.

And if you try to address several tasks within one transaction, you鈥檒l struggle to give it a descriptive name and users won鈥檛 be able to work out what it鈥檚 for.

For example, the Environment Agency (EA) broke the 鈥榃hat鈥檚 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鈥檛 solve a recognisable problem without bringing them together into one transaction

Don鈥檛 let organisational structures or technical choices dictate the shape of your transaction

Users shouldn鈥檛 have to understand the structure of government to access services. So it鈥檚 important to scope transactions based on tasks rather than the organisations providing them.

And don鈥檛 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鈥檚 usually much harder to do it the other way around.

Only put information inside a transaction if it needs to be there

It鈥檚 important that users can find the information they need. They won鈥檛 find it if it鈥檚 hidden inside a transactional service, because content inside services doesn鈥檛 come up in search results.

So only put information inside a transaction if it鈥檚 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鈥檙e providing information at the point of need.

If the information isn鈥檛 an integral part of the transaction, publish it as guidance on 伊人直播 so it鈥檚 easy to find.