How to scope one product workflow

Find the task inside the request

“Can you audit the portal?” could mean dozens of unrelated things. So we always start by finding the task someone needs to complete. A team admin inviting a colleague is one task. Setting up billing, managing access and exporting reports are three others, even if they all sit in the same menu.

A good scope statement has a simple shape: a named user role needs to achieve a specific outcome, starting from a clear trigger and finishing at a recognisable end point. Add the device and any access assumptions. That gives everyone the same boundary without pretending the rest of the product doesn’t exist.

Set a real beginning and end

The first screen in your design file is rarely where the experience starts. An email invitation, a conversation with support or a decision made the week before can shape what someone expects. Include enough of that context to understand the workflow, even if redesigning the email itself is out of scope.

The end should be an outcome for the user, not a button click. When someone submits a request, they usually need a confirmation, a reference number and a sense of what happens next. A form that posts successfully but leaves people unsure will still generate repeat contacts and duplicate submissions.

Count the states, not just the screens

Screen counts are handy for agreeing effort, but they don’t tell you how complex something is. One page with five permission levels and several failure modes can take more work than a sequence of ten simple pages. So list the conditions that change what the user sees or can do.

Take an invitation flow. You’d want to include an invitee who already has an account, an invitation that’s expired, an admin who doesn’t have permission to invite, and a request to resend. It’s also worth asking whether the admin needs to see where the invitee has got to. Get the business rules straight before trying to simplify the interface.

A compact scope inventory covers:

• The trigger and the intended outcome.
• The main role and their permissions.
• The main path and the alternatives that matter.
• Empty, error and completion states.
• Dependencies and known technical constraints.
• The evidence available for the review.

Keep a list of adjacent issues

Any review will turn up problems outside its boundary. Write them down in a separate list with a line explaining the connection. Don’t quietly expand the job, and don’t throw a relevant issue away just because it sits elsewhere.

For example, an invitation problem might really come from the way the organisation’s roles are set up. The audit can point that out, and the team can decide separately whether to redesign access management. The immediate work stays manageable, and the product owner gets a clearer picture of what could come next.

Agree how you’ll work together

Before starting, confirm who can give access, who answers product questions and who makes decisions. Note any data you can’t get and how that limits the conclusions. And agree what counts as a change in scope, so that conversation happens early rather than midway through.

Our UX Audit is built around one product, workflow, main role and device, with up to ten agreed screens or states. Use the scoping conversation to pick a coherent journey. Don’t choose 10 screens just because they fit the allowance.