Understanding UX and User Flows

# CHAPTER 2

Understanding UX and User Flows #

1. Introduction #

2. Learning Objectives #

• Define the difference between a "User Journey" (Macro) and a "User Flow" (Micro).

• Map out step-by-step navigation logic using standard flowchart shapes.

• Identify the "Happy Path" versus "Edge Cases" (Error states).

• Understand how user goals dictate the architectural layout of a wireframe.

• Create a text-based interaction path for a core software feature.

3. User Journeys vs. User Flows #

• The User Journey (The Macro View): This maps the user's entire relationship with the company. *Example:* "User sees an ad on Instagram -> Clicks ad -> Lands on website -> Reads blog -> Signs up for trial -> Receives welcome email -> Uses software." It includes emotions and external touchpoints.

• The User Flow (The Micro View): This is the strict, step-by-step mechanical path inside the software to accomplish a specific task. *Example:* "Login Screen -> Enter Credentials -> Authenticate Database -> Dashboard Screen."

4. Mapping the Interaction Path (The Flowchart) #

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

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

• Diamond: A Decision Point. This is where logic splits (e.g., "Is Password Correct?"). This creates two branches: "Yes" and "No".

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

• The Happy Path: The ideal scenario where the user does everything perfectly. (User adds item to cart -> Enters valid credit card -> Payment succeeds -> Success Screen).

• The Edge Cases (Error States): What happens when things break? (User enters invalid credit card -> Payment declines -> ?). If you don't plan an Edge Case flow, the developer won't code an error screen, and the user will be stuck on a broken page. *Wireframing requires you to design the Error Screens just as carefully as the Success Screens.*

6. How Flows Dictate Wireframes #

• *The UX Fix:* You consolidate the flow. You decide to put the "Upload Picture" button directly on the main Dashboard.

• *The Wireframe Impact:* Now, when you draw the Dashboard wireframe, you know you *must* allocate space for an "Upload Profile Picture" widget. The Flow dictated the structural requirements of the Wireframe.

7. Diagrams/Visual Suggestions #

[OVAL: Start: Open App]
        |
        V
[RECTANGLE: Login Screen]
        |
        V
[DIAMOND: Is Account Valid?]
       /      \
  [YES]        [NO]
    |           |
    V           V
[RECTANGLE:   [RECTANGLE:
Dashboard]    Error Toast Notification]

This diagram trains the student to think in non-linear logic loops before drawing linear screens.

8. Best Practices #

• One Goal per Flow: Do not try to map out the entire 500-page application in one massive flowchart; it will become an unreadable plate of spaghetti. Create isolated, specific flows: "The Checkout Flow," "The Password Reset Flow," "The Onboarding Flow." Keep it modular.

9. Common Mistakes #

• The "Dead End" Screen: A beginner draws a beautiful wireframe for a "Registration Success" screen, but forgets to put a "Go to Dashboard" button at the bottom. *The Failure:* The user flow hits a dead end. The user is trapped on the success screen with no way forward. *Every wireframe must have a clear exit path.*

10. Mini Project: Map an E-Commerce Checkout Flow #

1. 1. Start: [User views Product Page]

1. 2. Action: User clicks "Add to Cart".

1. 3. Decision: [Diamond] Is user logged in?

• NO Path: -> [Login/Guest Checkout Screen] -> (Proceed to Checkout)

• YES Path: -> [Checkout Screen]

1. 4. Action: User enters Credit Card.

1. 5. Decision: [Diamond] Is payment approved?

• NO Path: -> [Show Error Message on Checkout Screen]

• YES Path: -> [Order Success Screen]

1. 6. End: [Order Success Screen] contains a button -> "Return to Homepage".

1. 7. *Result:* You have mapped exactly how many wireframes you need to draw (Product, Login, Checkout, Error State, Success State, Homepage).

11. Practice Exercises #

1. 1. Define the difference between a "User Journey" and a "User Flow." Which one is focused specifically on the mechanical, screen-by-screen clicks required to complete a software task?

1. 2. Explain the purpose of the "Diamond" shape in a standard UX flowchart. Provide a real-world example of a digital decision point that would require a Diamond shape to split the user flow into "Yes" and "No" paths.

12. MCQs with Answers #

13. Interview Questions #

• Q: A client asks you to wireframe a new feature for their app. Walk me through why it is a massive mistake to open Figma and start drawing rectangles immediately, and explain why you must demand a "User Flow" mapping session first.

• Q: Explain the concept of the "Happy Path." If you only design wireframes for the Happy Path, what critical UI screens will you inevitably forget to hand off to the development team?

• Q: How do you handle a "Dead End" in a user flow? Give an example of a common app screen that often traps users, and explain the specific UI component you would add to the wireframe to rescue them.

14. FAQs #

15. Summary #

16. Next Chapter Recommendation #