Lesson 02B / UX Process
User Flows And Task Models
Map what people are trying to do, where they enter, what decisions they face, and how an interface supports a successful path.
Course Role
Studio Support
Best during work sessions, critique, debugging, project planning, or final polish.
Teacher Notes / In-Class Use
Demo Live
- Model a common student project as a user task before drawing any screens.
- Add one edge case live so students see how flows reveal missing states and screens.
Try In Class
- Have students map one primary task from their current project.
- Ask students to add three edge cases or recovery paths, then revise the screen inventory.
Submit Or Check
- The flow should include entry point, success condition, primary action, decision points, and at least one state.
- Students should connect the flow to a screen inventory and one HTML outline.
Watch For
- Students naming screens before naming the user task.
- Flows that only include the perfect path and ignore errors, empty states, or recovery.
Learning Goals
- Describe a user goal as a task, not only as a screen or feature.
- Map entry points, steps, decisions, success paths, and edge cases.
- Use task models to decide which screens, pages, states, and content are necessary.
- Turn a flow into a buildable interface plan with clear routes, actions, and feedback.
Start With The Task
App and web projects often go sideways when students start by naming screens. A screen is only useful if it helps someone do something. A task model keeps the design focused on the person, the goal, and the decisions needed to complete that goal.
Before designing a homepage, dashboard, details screen, form, or checkout flow, write the task in plain language. If the task is unclear, the interface will usually become a pile of unrelated features.
- Weak: The app needs a profile screen.
- Stronger: A student needs to check whether their profile has the right contact information before submitting a portfolio.
- Weak: The site needs a project page.
- Stronger: A visitor needs to understand what the project is, what role the student played, and where to see the live result.
Core Vocabulary
| Term | Meaning |
|---|---|
| Actor | The person using the interface, such as a student, visitor, organizer, or client. |
| Goal | The outcome the actor is trying to reach. |
| Entry point | Where the task begins: search, homepage, link, notification, dashboard, or shared URL. |
| Step | A meaningful action or decision in the task. |
| Decision point | A moment where the user must choose between paths. |
| State | The condition the interface is in: empty, loading, error, success, signed out, or complete. |
| Exit point | Where the task ends, such as confirmation, saved item, submitted form, or next recommended action. |
A Simple Flow Formula
Use this sentence before drawing boxes and arrows. It forces the interface to serve a concrete scenario.
As a [type of user],
I want to [complete a task],
so I can [reach a useful outcome].
The task starts when [entry point].
The task succeeds when [success condition].
The most likely problem is [edge case or barrier]. Flow Types
| Flow Type | Use It When | Example |
|---|---|---|
| Linear flow | The user completes steps in a clear order. | Sign up, checkout, submit a project. |
| Hub-and-spoke flow | The user returns to a central screen between tasks. | Dashboard, course portal, event app. |
| Browse-to-detail flow | The user scans a list, then opens one item. | Portfolio projects, events, articles, products. |
| Create-edit flow | The user makes something, saves progress, and may return later. | Profile editor, project planner, post editor. |
| Recovery flow | The user hits a problem and needs a way back. | Forgot password, failed upload, empty search. |
What To Map
- The first screen or page the user sees.
- The primary action on each step.
- The information the user needs before choosing that action.
- Where the interface gives feedback.
- Where the user can go backward, cancel, edit, save, or recover.
- What happens if there is no data yet.
- What happens if something fails.
- What success looks like at the end of the flow.
From Flow To Screen Inventory
| Flow Need | Possible Screen Or Page |
|---|---|
| User chooses from many items | Listing, gallery, dashboard, search results, or filtered view. |
| User needs details before acting | Detail page, modal, expanded card, or review step. |
| User submits information | Form page, multi-step form, or inline editor. |
| User waits for a response | Loading state, progress indicator, or optimistic feedback. |
| User has no content yet | Empty state with explanation and next action. |
| User makes a mistake | Error state with specific message and recovery path. |
| User completes the task | Confirmation, saved state, success message, or next step. |
Edge Cases Are Part Of The Design
A flow that only works when everything goes perfectly is incomplete. Edge cases reveal missing screens, copy, states, and controls before the project is built.
- What if the user has not signed in?
- What if the list has zero items?
- What if the image fails to upload?
- What if the user enters invalid information?
- What if the user changes their mind?
- What if the task takes longer than expected?
- What if the user arrives from a shared link instead of the homepage?
Studio Activity: Map One Primary Flow
- Choose one current project task.
- Write the task using the flow formula.
- Draw the happy path from entry point to success.
- Add at least three edge cases or recovery paths.
- Turn the flow into a screen inventory.
- Choose one screen and write the HTML outline needed to support it.
Submission Checklist
- The flow starts with a user goal, not a feature name.
- The entry point and success condition are clear.
- Each step has one primary action.
- Decision points and recovery paths are labeled.
- The flow includes at least one empty, error, loading, or success state.
- The screen inventory matches the flow instead of adding unrelated screens.
Checkpoint
Before moving on, make sure these feel true.
- I can define a user task with an entry point and success condition.
- I can map a happy path, decision points, and recovery paths.
- I can turn a flow into a screen inventory and semantic implementation plan.
Project Connection