Understanding User Flows

# CHAPTER 2

Understanding User Flows #

1. Introduction #

You cannot build a highway without a map. If you open Figma and start randomly connecting buttons to screens based on what "feels right" at the moment, you will create a chaotic, confusing maze. A prototype is merely the physical manifestation of underlying logic. That logic is called a User Flow. A User Flow defines the exact, step-by-step path a person takes through a product to complete a specific task. In this chapter, we will master Understanding User Flows. We will step away from the design canvas to map the psychological journeys, define strict navigation paths, and architect the interaction patterns that dictate how our digital environments behave.

2. Learning Objectives #

By the end of this chapter, you will be able to:

• Distinguish between the macro "User Journey" and the micro "User Flow."

• Diagram logical navigation paths using standard UX flowchart shapes.

• Identify the "Happy Path" versus alternate/error paths.

• Understand how common Interaction Patterns accelerate user learning.

• Translate a text-based User Flow into actionable prototyping requirements.

3. User Journeys vs. User Flows #

These terms are related but operate at completely different scales.

• User Journey (The Macro Map): Documents the entire relationship a user has with a brand across all touchpoints (e.g., Seeing a Facebook Ad -> Visiting the website -> Calling customer support -> Receiving a physical product in the mail).

• User Flow (The Micro Blueprint): Documents the exact, screen-by-screen mechanical clicks required to complete one specific software task (e.g., The sequence of clicks required to reset a forgotten password). *Prototypes are built entirely on User Flows.*

4. Diagramming the Navigation Logic #

Before prototyping, professional designers draw Flowcharts. Flowcharts use specific shapes to communicate logic to developers and stakeholders.

• Oval / Pill: The Start or End point of the flow (e.g., "Open App").

• Rectangle: A Screen or specific Action (e.g., "Login Screen").

• Diamond: A Decision Point. This is where the prototype's logic will split (e.g., "Is the password correct?"). The Diamond always branches into two paths: "Yes" and "No".

5. The "Happy Path" and "Edge Cases" #

A prototype that only tests success is a dangerous prototype.

• The Happy Path: The optimal sequence of events where everything goes perfectly. (User enters correct email -> clicks login -> views dashboard).

• The Edge Cases (Error States): What happens when the user clicks a button but the logic fails? (User enters wrong password -> clicks login -> ?). If your User Flow does not explicitly map the "No" path out of a Decision Diamond, you will forget to prototype the Error Screen, and the user testing session will hit a dead end.

6. Interaction Patterns (Don't Reinvent the Wheel) #

Users spend 99% of their time on other people's apps. They have subconscious expectations about how logic should flow. These are called Interaction Patterns.

• *Example:* When checking out on an e-commerce site, the Interaction Pattern is universally: Cart -> Shipping Details -> Payment Details -> Confirmation.

• If you try to be "creative" and build a prototype flow that asks for Payment *before* Shipping, you break the established pattern. The user will panic and abandon the cart. *Good UX relies heavily on predictable logic.*

7. Diagrams/Visual Suggestions #

*Visual Concept: The Flowchart to Prototype Translation* Provide a 2-panel visual.

• Top Panel (The Flowchart): A text diagram: [Rectangle: Product Page] -> [Arrow] -> [Rectangle: Cart Flyout] -> [Arrow] -> [Rectangle: Checkout].

• Bottom Panel (The Prototype): Three wireframe screens corresponding exactly to the rectangles above. A blue prototyping "noodle" arrow connects a button on Screen 1 to Screen 2, mirroring the logic of the flowchart perfectly.

This visual proves that the flowchart is the literal blueprint for the prototype wiring.

8. Best Practices #

• Scope Your Flows: Never try to map the entire application in one massive flow diagram; it will look like an unreadable plate of spaghetti. Break your logic into isolated, manageable chunks: "The Registration Flow," "The Document Upload Flow," "The Settings Update Flow."

9. Common Mistakes #

• Designing Before Diagramming: A junior designer skips the flowchart phase and goes straight into Figma to build a 20-screen checkout prototype. Halfway through, they realize they forgot a "Guest Checkout" option. They now have to rip apart 15 screens, break all their prototype links, and redesign the architecture. *The Fix:* Never open Figma until the Flowchart is 100% approved by stakeholders. Erasing a whiteboard marker takes 1 second; rebuilding a prototype takes 1 day.

10. Mini Project: Map a "Forgot Password" Flow #

Let's engineer a critical logic loop using text.

1. 1. Start [Oval]: User opens Login Screen.

1. 2. Action [Rectangle]: User clicks "Forgot Password" link.

1. 3. Screen [Rectangle]: User is taken to "Reset Request" screen.

1. 4. Action [Rectangle]: User enters email and clicks "Send Link."

1. 5. Decision [Diamond]: Does the email exist in the database?

• NO Path: -> Arrow goes to a new [Rectangle: Error Message "Email not found."]. Arrow loops back to step 4.

• YES Path: -> Arrow goes to [Rectangle: "Check your email" Confirmation Screen].

1. 6. End [Oval]: Flow terminates pending email receipt.

1. 7. *Result:* You now know exactly how many specific screens and error states you must wireframe and connect in your Figma prototype.

11. Practice Exercises #

1. 1. Define the specific difference between a "User Journey" and a "User Flow." Which one is focused entirely on the mechanical, screen-by-screen interactions inside the software?

1. 2. Explain the purpose of the "Decision Diamond" in a standard UX flowchart. Provide a real-world example of a software interaction that would require a Diamond shape to split the logic.

12. MCQs with Answers #

13. Interview Questions #

• Q: A client asks you to build an interactive prototype for a massive new social media app. Walk me through why it is a catastrophic workflow error to open Figma and start designing screens before you have finalized the "User Flow" diagrams.

• Q: Explain the relationship between "User Flows" and "Edge Cases." If you only diagram the "Happy Path" for a credit card checkout flow, what critical prototype screens will you inevitably fail to build for the User Testing phase?

• Q: Walk me through the standard UX flowchart shapes. What do Ovals, Rectangles, and Diamonds represent, and how do they communicate backend logic to the engineering team?

14. FAQs #

Q: Do I need special software to draw User Flows? A: No. A physical whiteboard is often the best tool for speed. For digital documentation, FigJam (by Figma) and Miro are the industry standards. They provide massive digital whiteboards with drag-and-drop shapes explicitly designed for rapid flowcharting.

15. Summary #

In Chapter 2, we established the unshakeable logic that dictates our prototypes. We learned that an interactive simulation is utterly useless if the underlying map is flawed. We mastered the vocabulary of flowcharts, utilizing diamonds to map critical decision points and logic splits. We recognized the danger of the "Happy Path" bias, ensuring we meticulously map the Edge Cases and Error States to prevent prototype dead ends. By relying on established Interaction Patterns and rigorously mapping the steps before drawing the screens, we guarantee that our prototypes will test objective usability, not confusing architecture.

16. Next Chapter Recommendation #

The logic is mapped. Now we must select the engine that will bring this logic to life. Proceed to Chapter 3: Prototyping Tools and Setup.