DESIGNING THE PATHS
USERS ACTUALLY TAKE
FROM INTENT TO
OUTCOME

I design the paths users take from intent to outcome: onboarding, configuration, creation, error recovery, edit and undo, multi-step setup. Here are four recent flow projects in enterprise B2B SaaS, each a complex creation or migration experience rebuilt around how people actually work, grounded in research I ran myself.

Role
Lead Product Designer
Discipline
Flow design, UX research, prototyping, spec
Context
Enterprise B2B SaaS platform
Flows in this study
04
FLOW 01 / 04
Bulk link creation
3
Milestones sequenced; upload-and-validate path shipped first
14
Research participants across media, entertainment, financial services
5/7
Named error recovery the top blocker, setting priority
The problem

Enterprise customers needed links at scale, whether thousands at once or tightly-named batches of a handful, yet the only path was a single-item form repeated by hand or a homegrown spreadsheet workaround. A CSV-based bulk creation wizard existed in prototype, with no evidence it worked for the people who'd use it daily.

What I did

I ran usability research across three groups, moderated with internal team members and unmoderated with current customers and external growth marketers, then synthesized the findings into a phased download-template, fill, upload, validate, create flow scaled to tens of thousands of records per file. Validation runs up front, returning valid, invalid, and blank counts before anything is created, and a two-tab preview splits clean records from errors so users can download just the failed rows, fix them, and re-upload. Sequencing the work into three milestones put the highest-value path in customers' hands first.

Error states are universally the biggest blocker. Users hit errors they couldn't resolve. The flow works, but it doesn't teach. Research synthesis, cross-group findings
STEP SYSTEM VALIDATION ROW ERROR ONE FLOW TEMPLATE, FILL, UPLOAD, VALIDATE, CREATE DOWNLOAD TEMPLATE FILL THE FILE UPLOAD VALIDATE ERRORS RETURNED UP FRONT, BY ROW CREATE MANY LINKS AT ONCE TENS OF THOUSANDS PER FILE, EACH WITH ITS OWN STATUS TWO ROWS FLAGGED, THE REST CREATED
Fig. One flow in, thousands of links out, every row with its own status
FLOW 02 / 04
Bulk link editing
3
Tiers of editable fields unified in one flow
5
Flow gaps surfaced and resolved through structured critique
0
Silent edits: affected links always shown before apply
The problem

Links go stale: app paths change, tags get set wrong at creation, onboarding mistakes compound, and customers could only fix them by pinging an admin one link at a time. The flow had to edit across three tiers of fields, analytics tags, routing and behavior, and social metadata, without letting someone accidentally change the wrong set of links.

What I did

I mapped the flow from the PRD, then ran a design critique that surfaced the gaps: no back navigation, undefined cancel behavior, an unenforced selection limit, an unresolved partial-success state. The redesign, a stepped wizard with a persistent left rail listing the selected links, keeps the affected set visible before any change applies, so nothing edits silently. Customer interviews reinforced that safety requirement directly.

Before the last screen, make it perfectly clear which links you're editing. Show me the list. Enterprise customer, media & entertainment
SELECTED SET FIELD TIER EDGE CASE DEFINED PICK THE SET THE LEFT RAIL KEEPS EVERY SELECTED LINK VISIBLE RAIL THREE OF FIVE SELECTED EDIT ONCE, APPLY EVERYWHERE A STEPPED WIZARD ACROSS THREE FIELD TIERS ANALYTICS TAGS ROUTING + BEHAVIOR SOCIAL METADATA CONFIRM THE AFFECTED SET APPLIED TO EVERY LINK PARTIAL SUCCESS: DEFINED, NOT LEFT OPEN CRITIQUE FIXED THE GAPS: BACK NAV, CANCEL, SELECTION LIMIT
Fig. The stepped wizard: the selected set stays visible, one edit applies everywhere
FLOW 03 / 04
A/B test variants
1–20
Variants supported, interface adapting at each count
6+
Edge cases resolved in spec before engineering handoff
3
Enterprise customers validated the flow live before refinement
The problem

The campaign builder needed an A/B testing section so marketers could test creative variants against each other. Experimentation flows are deceptively complex: traffic must sum correctly, the control case must be unambiguous, and the interface must behave with one variant or twenty.

What I did

I pinpointed every flow and edge case before handoff: entry states for one versus multiple variants, traffic that doesn't sum to 100 percent, the can't-delete-the-last-variant rule, maximum variant count, holdout group behavior, and what control actually means. One diagram mapped them all, and the spec let engineering build without coming back with questions.

Scope

Variant management from one to twenty variants, per-variant traffic control, and adjustable holdout groups, validated live with enterprise customers before refinement.

VARIANT HOLDOUT BLOCKED CASE SPLIT THE TRAFFIC ONE TO TWENTY VARIANTS, CONTROL ALWAYS UNAMBIGUOUS A VALID SPLIT VARIANT A 40 VARIANT B 30 CONTROL 20 10 HOLDOUT SUMS TO 100? SAVE AN INVALID SPLIT 45 40 25 ADDS TO 110: BLOCKED AT SAVE EDGE CASES SPECCED MAPPED IN ONE DIAGRAM BEFORE HANDOFF DOES NOT SUM TO 100 BLOCKED DELETE THE LAST VARIANT PREVENTED ONE VS MANY VARIANTS ENTRY STATES SET TWENTY-VARIANT MAXIMUM ENFORCED HOLDOUT BEHAVIOR DEFINED
Fig. Traffic that must sum to 100, with every edge case specced before handoff
FLOW 04 / 04
Configuration migration
2
Features migrated as paired configuration and runtime flows
3
Entry paths (create, edit, apply) converge on shared runtime
0
Breaking changes: configurations auto-migrate, behavior preserved
The problem

A legacy feature set was migrating into a redesigned platform experience, and two configuration surfaces had to move without disrupting the customers depending on them. The job: make the new location feel like an upgrade while preserving existing behavior exactly.

What I did

I mapped both features as paired configuration and runtime flows: where settings live in the new navigation, and what the end user experiences when a link fires. Create, edit, and apply converge at a shared runtime, and automatic migration carried existing configurations over with behavior preserved and no customer action required, an upgrade that broke nothing for the customers depending on it.

Carry the old behavior over untouched, and let the new home earn the move on its own. Design principle, migration work
LEGACY NEW HOME PROTECTED IN TRANSIT LEGACY HOME TWO CONFIG SURFACES, CUSTOMERS DEPENDING ON THEM CONFIG SURFACE 1 CONFIG SURFACE 2 MIGRATED AUTOMATICALLY, BEHAVIOR PRESERVED EXACTLY THE NEW HOME CREATE, EDIT, APPLY CONVERGE AT ONE SHARED RUNTIME CONFIG SURFACE 1 IN THE NEW NAVIGATION CONFIG SURFACE 2 IN THE NEW NAVIGATION CREATE EDIT APPLY SHARED RUNTIME WHAT FIRES WHEN A LINK IS USED FEELS LIKE AN UPGRADE, WORKS LIKE BEFORE
Fig. Two config surfaces moved to the new home, migrated automatically with behavior preserved
A-6 / CASE STUDY
← ALL CASE STUDIES