Niss BerrySenior Product Designer
← Back to work

Workflow UX · Setup flow · Product logic

Route Builder Wizard

Reducing friction in a fragmented setup workflow.

Design completed and handed over for development.

Bluehook had the right setup pieces — locations, routes, scan tags, mappings, and actions — but the experience expected users to understand the system before the interface guided them. I reframed the flow around the user’s goal, moving the thinking toward a guided wizard-based setup that keeps context in one place, makes dependencies clearer, and reduces cognitive load.

Product area
Admin setup / route configuration
Focus
Workflow UX, product logic, adoption
Role
Product design, UX strategy, prototyping
Status
Design completed — handed over for development
Hero scenario
A guided setup flow that brings route stops, scan tags, readiness, and missing requirements into one connected journey.

01 / Context

Context

The setup journey was technically complete, but practically fragmented.

Bluehook’s route setup relied on several connected pieces: locations, routes, scan tags, scan mappings, actions, and templates. Each piece made sense on its own, but the user had to understand how they related before the interface helped them move forward.

For experienced users, this structure could be learned. For smaller teams or new admins, it created unnecessary cognitive load before they could complete a basic setup task.

The product had the ingredients. The experience needed the recipe.

02 / The friction

The friction

The problem was not one broken screen. It was the handoff between screens.

Users had to move across separate areas to create locations, build routes, assign scan tags, and connect those tags to actions. The setup flow expected them to remember dependencies, understand system terminology, and know which piece came next.

This made the experience feel more complex than the task itself.

Fragmented setup

Related pieces lived across separate screens.

Hidden dependencies

Users needed to understand what had to exist before the next step made sense.

Too much memory work

The interface relied on users holding the system model in their head.

Before
The pieces existed, but the journey was fragmented.

03 / What users had to hold

What users had to hold

The user was not just creating a route. They were mentally mapping the product architecture.

To complete setup, users needed to understand questions like:

  • Which location belongs to which site?
  • Does this route need checkpoints?
  • Which scan tag belongs to which route stop?
  • What action should happen when a tag is scanned?
  • Which form or template should open next?

These questions are important, but the interface should not ask users to solve all of them from memory.

If the user has to understand the system before they can use the system, the interface is doing too little of the work.

Thinking artefact
Mapping the early route and scan-tag dependencies before turning them into interface decisions.
Thinking artefact
Untangling how routes, locations, templates, scan tags, and actions needed to relate.

04 / The shift

The shift

I moved the thinking from system-led setup to goal-led configuration.

Instead of asking users to jump between separate setup areas, the wizard direction keeps the task in one flow. Each step introduces only the information needed at that moment, while still preserving the relationships between locations, routes, scan tags, mappings, and actions.

This reframes setup around what the user is trying to do, not how the database is organised.

Before

Create pieces separately, remember what connects, then manually stitch the setup together.

After

Follow a guided setup flow that keeps context visible and makes the next step clear.

From rough logic to product structure
Turning rough system logic into a more structured product direction.

05 / Wizard direction

Wizard direction

The wizard becomes a guided path through the setup logic.

The proposed flow helps users create or connect the right setup pieces in sequence:

  1. Choose or create the location.
  2. Decide whether the scan belongs to a standalone point or a route.
  3. Add route stops if needed.
  4. Assign or create the scan tag.
  5. Map the scan to the right action or template.
  6. Review the setup before activating it.

This gives the user a clearer mental model while reducing the chance of missing a dependency.

Featured · Route stops
Route stops become ordered, movable, and visible in context, with missing Scan IDs shown before publish.
Decision point
Standalone scan tags get a clearer decision point: link to a location or keep as a standalone scan-to-form tag.
Readiness
Readiness becomes part of the workflow instead of something users discover later.

06 / What this proves

What this proves

The value of the redesign is not just fewer screens. It is less uncertainty.

The scenario shows how a fragmented setup experience can become easier to adopt by making relationships visible, sequencing decisions more clearly, and reducing the amount of product logic users need to memorise.

This is especially important for teams that do not have the time, training, or support to decode the system before getting value from it.

Clearer setup path

A sequenced flow replaces guesswork across disconnected screens.

Lower cognitive load

Users hold less of the system model in their head at any one moment.

Better adoption for new admins

Smaller teams can reach value without learning the architecture first.

This scenario shows that I can

  • See beyond isolated UI issues.
  • Understand product dependencies and system logic.
  • Reduce cognitive load in complex admin workflows.
  • Design for users who do not already understand the product.
  • Reframe fragmented screens into a guided journey.
  • Think about adoption, not just interface polish.

07 / Reflection

Reflection

The strongest product move was not adding more explanation. It was changing where the explanation happens.

Help content can support a user, but it should not carry the entire experience. In this scenario, the better move was to let the flow itself teach the product logic as the user moved through it.

That is the kind of product work I keep coming back to: making complex systems feel less intimidating by designing the path, not just polishing the screen.