User Flows & User Stories
User Flows & User Stories in Detail
From root cause analysis to surgical optimization: structural deconstruction of complex workflows for fast developer handovers. Enterprise software becomes usable when you decompose it from the user's perspective — not from the feature's perspective.
Sequence Diagrams for Clear Workflows
User flows are modeled as sequence diagrams. Interactions are grouped on the Y-axis, focus areas are defined on the X-axis to drastically reduce complexity. That means: you see immediately where users get stuck — not after a six-week redesign.
Surgical, Point-by-Point Adjustments
The modeling targets the weakest link in the chain. Expensive, blind full redesigns are consistently avoided and changes are kept extremely cost-efficient. That means: you pay for a precision intervention, not open-heart surgery.
Version-Secure Git Documentation
All findings, diagrams, and user stories are maintained version-securely in a Git repository and are available as PDF for management at any time. That means: your design decisions are traceable — in two years, and for auditors too.
Agile Integration & PO Handover
Transparent participation in dailies for direct reporting. The preparation takes the form of user stories so that the Product Owner can seamlessly integrate them into the backlog. That means: your development team receives precise, actionable specs — not blocking wireframes.
Practical Example: Authentication Flow
Clear mapping of interactions, screens, and sub-processes via PlantUML.
To ensure clarity and technical precision, I use PlantUML sequence diagrams to map the interactions between users and the system. My methodology is based on Contextual Design and puts the mental state of the user at the center – instead of pure UI components.
- User Flow
- A user flow is a chronological sequence of steps that a person performs to achieve a specific goal within the application (e.g., registration and login). It describes the path from an entry point through various focus areas to a successful outcome. While a workflow describes the overarching business process, the user flow focuses on the direct interaction with the software.
- Focus Area
- A focus area is a coherent functional workspace developed to fulfill a specific user goal. The concept comes from Contextual Design: it provides all necessary functions and data for a particular intention without distracting users with inappropriate features.
The apartment analogy: A kitchen is a focus area for food preparation; a bathroom is a focus area for personal hygiene. No one would put a stove in the shower because the goals are completely different. In software development (e.g., SaaS), however, we often violate this simple logic by overloading interfaces with unrelated “features” – leading to feature bloat and frustration. Focus areas prevent this by horizontally decomposing system complexity into manageable, intention-driven units.
In my diagrams: Focus areas are represented as participants with the
stereotype <<Focus Area>>.
Naming focus areas: The name of a focus area should be a “noun of intent.” It must describe what the user is currently doing or what state they are in, rather than reflecting the technical implementation.
- Avoid technical jargon: Do not use terms like “Settings Page,” “Data Grid,” or “Modal Window.” These focus on UI widgets, which confuses laypeople and derails design discussions.
- Use nouns of intent: Use abstract but precise terms that reflect
the mental state of the user:
- Attention: The entry point where we capture the user’s interest.
- Identity: Where the user defines who they are (registration / authentication).
- Insight: Where system status is monitored or data is analyzed.
- Adjustment: Where parameters are fine-tuned or configurations are changed.
Noun-of-Intent as a Design Philosophy
The noun-of-intent rule is a theory about mental models. I claim that users do not think in “settings pages” and “data grids,” but in states and intentions. They think: “I want to adjust my profile,” not “I open the settings page.”
I force the design to speak this language. When the names of focus areas reflect the mental language of users, stable, discussable interfaces emerge. Technical jargon disappears from the concept — and from design discussions along with it.
Methodological Maturity
My flows document a psychological sequence, not a technical one. I describe the mental phases of a new user, not the system calls.
- Error cases inline
- Errors are not modeled as a separate “error flow.” They appear where they actually occur. This is more realistic and prevents artificial branches.
- Modularity
- Every flow consists of manageable, reusable blocks. This makes the diagrams readable and flexible.
- Focus on mental states
- The sequence follows the user’s understanding, expectation, and trust — not the technical architecture.
FAQ: User Flows & User Stories
Why Sequence Diagrams Instead of Flowcharts?
Flowcharts show what happens. Sequence diagrams show who interacts with whom and in what order. That is a fundamental difference.
In a flowchart, the system is often a black box. In my sequence diagrams, every participant is an actor with a role: User, Attention, Registration, Selection, Reading, Confirmation, Overview. I model the interaction between user and system as a dialog, not as a flowchart.
That is exactly the perspective that matters in an enterprise context. There, workflows span multiple systems — not single click paths. Sequence diagrams make these actors, roles, and handoffs explicit.
Why do you use PlantUML for modeling user flows instead of classic tools like Figma or Miro?
PlantUML generates text-based sequence diagrams that are extremely precise and easily versionable. By dividing user activities on the Y-axis and focus areas on the X-axis, the complexity of extensive system workflows can be drastically reduced and iteratively measured.
Does the UX analysis inevitably lead to an expensive and time-consuming redesign?
No, that is exactly what is prevented. The modeling isolates the weakest link in the interaction chain. Instead of a generic complete redesign, only minimal, surgical adjustments are made at the actual bottlenecks. This saves budget and development resources.
Do our developers receive ready-made tickets for the backlog?
The problems are fully documented in the form of diagrams and concrete user stories. However, direct entry and prioritization in the backlog remains the responsibility of your Product Owner (PO) to preserve your internal processes and agility.
Where and how are the analysis results documented for my team and management?
All results, diagrams, and user stories are transparently and version-securely structured in a Git repository. For management and uninvolved stakeholders, a clear PDF document is additionally generated from it.
How much time does our product team need to invest during this phase?
The effort remains extremely low. If desired, I participate in your daily stand-ups to briefly and directly report on progress and findings. Further coordination takes place flexibly and according to your team’s needs.
Used In
This tool is part of the following consulting offers.