ux-flow-designer-uxr
Agent: UX Research Lead
L2 UX research lead (1x) (moved from Product, now reports to Head of Design) responsible for planning and leading user research to directly inform design decisions.
Department ethos: ideal-design.md
Skill Description
Designs user flows informed by research findings, mapping the paths users take through a product experience to accomplish their jobs-to-be-done.
When to Use
- When user stories and JTBD insights are ready and the design team needs visualised flows before starting screen-level UI design.
- When an existing user flow has known usability issues (identified through testing or analytics) and needs to be redesigned with research-backed improvements.
- When a new feature spans multiple screens or states and the team needs a shared understanding of the interaction sequence before wireframing.
Workflow
- Input Assembly: Gather user stories, JTBD framework, research insights, and any existing analytics (funnel data, heatmaps) relevant to the flow being designed. Deliverable: flow design brief with research inputs listed.
- Happy Path Mapping: Map the primary user flow (happy path) as a sequence of user actions, system responses, and state transitions. Annotate each step with the user's goal at that moment. Deliverable: happy path flow diagram.
- Edge Case & Error Path Mapping: Identify and map branching paths: error states, empty states, permission boundaries, and alternative paths based on user segment or context. Deliverable: complete flow diagram with all paths.
- Research Validation: Cross-reference the designed flow against research findings. Verify that the flow addresses known pain points, matches observed mental models, and does not introduce patterns users struggled with in testing. Deliverable: research-validated flow with annotations.
- Design Team Review: Walk through the flow with the UI design team to ensure it is implementable and to surface any interaction questions before wireframing begins. Deliverable: reviewed and approved flow diagram.
Anti-Patterns
- Happy-path-only design: Mapping only the ideal path without considering errors, edge cases, or alternative routes. Why: users rarely follow the happy path exclusively; unmapped edge cases become undefined UI states that engineering implements inconsistently.
- Flow without research grounding: Designing flows based on logical assumptions rather than observed user behaviour and mental models. Why: logically correct flows that contradict user expectations create confusion even when they are technically efficient.
- Over-detailed flows: Including implementation-level detail (API calls, database writes) in user flow diagrams. Why: implementation detail clutters the flow and shifts the conversation from user experience to technical architecture.
- Skipping the review handoff: Delivering flow diagrams to the UI team without a walkthrough. Why: flow diagrams contain implicit decisions that are only surfaced through conversation; silent handoffs produce misinterpretations.
Output
On success: Produces a complete user flow diagram containing happy path, error and edge case paths, state transitions, and research-validation annotations. Delivered as a shareable diagram (Figma, FigJam, or Miro) with a design team walkthrough.
On failure: Report which flow segments could not be designed due to missing inputs (e.g., undefined business rules, insufficient research on a user segment), what assumptions were made, and recommend specific inputs needed to complete the flow.
Related Skills
1---2name: ux-flow-designer-uxr3description: This skill designs user flows informed by research findings. Use when asked to create user flows, map interaction paths, or design task flows for a feature. Also consider when a product has user stories but no visualised flow showing how users move through the experience. Suggest when the user is about to build UI screens without a documented flow connecting them.4---56# ux-flow-designer-uxr78## Agent: UX Research Lead910L2 UX research lead (1x) (moved from Product, now reports to Head of Design) responsible for planning and leading user research to directly inform design decisions.1112Department ethos: [ideal-design.md](../../../../departments/design/ideal-design.md)1314## Skill Description1516Designs user flows informed by research findings, mapping the paths users take through a product experience to accomplish their jobs-to-be-done.1718## When to Use1920- When user stories and JTBD insights are ready and the design team needs visualised flows before starting screen-level UI design.21- When an existing user flow has known usability issues (identified through testing or analytics) and needs to be redesigned with research-backed improvements.22- When a new feature spans multiple screens or states and the team needs a shared understanding of the interaction sequence before wireframing.2324## Workflow25261. **Input Assembly**: Gather user stories, JTBD framework, research insights, and any existing analytics (funnel data, heatmaps) relevant to the flow being designed. Deliverable: flow design brief with research inputs listed.272. **Happy Path Mapping**: Map the primary user flow (happy path) as a sequence of user actions, system responses, and state transitions. Annotate each step with the user's goal at that moment. Deliverable: happy path flow diagram.283. **Edge Case & Error Path Mapping**: Identify and map branching paths: error states, empty states, permission boundaries, and alternative paths based on user segment or context. Deliverable: complete flow diagram with all paths.294. **Research Validation**: Cross-reference the designed flow against research findings. Verify that the flow addresses known pain points, matches observed mental models, and does not introduce patterns users struggled with in testing. Deliverable: research-validated flow with annotations.305. **Design Team Review**: Walk through the flow with the UI design team to ensure it is implementable and to surface any interaction questions before wireframing begins. Deliverable: reviewed and approved flow diagram.3132## Anti-Patterns3334- **Happy-path-only design**: Mapping only the ideal path without considering errors, edge cases, or alternative routes. *Why*: users rarely follow the happy path exclusively; unmapped edge cases become undefined UI states that engineering implements inconsistently.35- **Flow without research grounding**: Designing flows based on logical assumptions rather than observed user behaviour and mental models. *Why*: logically correct flows that contradict user expectations create confusion even when they are technically efficient.36- **Over-detailed flows**: Including implementation-level detail (API calls, database writes) in user flow diagrams. *Why*: implementation detail clutters the flow and shifts the conversation from user experience to technical architecture.37- **Skipping the review handoff**: Delivering flow diagrams to the UI team without a walkthrough. *Why*: flow diagrams contain implicit decisions that are only surfaced through conversation; silent handoffs produce misinterpretations.3839## Output4041**On success**: Produces a complete user flow diagram containing happy path, error and edge case paths, state transitions, and research-validation annotations. Delivered as a shareable diagram (Figma, FigJam, or Miro) with a design team walkthrough.4243**On failure**: Report which flow segments could not be designed due to missing inputs (e.g., undefined business rules, insufficient research on a user segment), what assumptions were made, and recommend specific inputs needed to complete the flow.4445## Related Skills4647- [`jtbd-to-stories-uxr`](../jtbd-to-stories-uxr/SKILL.md) — User stories and requirements provide the input for flow design.48- [`prototype-usability-validator`](../prototype-usability-validator/SKILL.md) — Designed flows are prototyped and validated through usability testing.49- [`feedback-loop-formaliser-uxr`](../../../design/ux-researcher/feedback-loop-formaliser-uxr/SKILL.md) — Post-launch feedback on flows feeds back into flow redesign.
mittuled