A useful interface connects an intention to an understandable outcome. A tidy collection of components is not yet a usable workflow.
By the end: describe a task, its necessary information, and the states that must exist before styling it.
This course emphasizes web applications and assumes familiarity with using websites, not professional design experience. Original Studio Desk examples teach practical refactoring, state handling, and critique. There is no required design software, earlier course, or framework knowledge. Examples use English and left-to-right layouts; localization and assistive-technology testing require additional work.
Identify the person and the outcome
Our fictional product, Studio Desk, helps people book workshops and helps an organizer manage places. A visitor asks whether a session suits them and whether a place is available. An organizer asks which booking needs attention. These are different tasks even when they use the same database.
Write the outcome in the person's language: reserve two places, change a contact address, or find an unconfirmed booking. Then identify what they must know before acting. Room names and internal record types may be useful to staff but poor starting points for an unfamiliar visitor.
Start with what the visitor already knows
Suppose you and a friend want two places in Clay basics. You know the workshop name, but you have never visited the building. A room-first entry asks you to supply information you do not yet have. Choosing West studio is easy only if you already know that Clay basics happens there. The interface has placed an internal classification before the visitor's decision. That is a task mismatch even if the room buttons are large, readable, and attractively arranged.
Work backward from a correct outcome. You need the right workshop and two places, with enough information to check the occasion and location. The workshop name establishes identity. Saturday and 14:00 help you check the time. West studio tells you where to go. Materials included may affect preparation. Those facts have different uses, so their order should follow the decision rather than the order in which a database happens to store them. No knowledge of database software is needed to notice the mismatch.
The same goal meets two entry questions
Reference entry, static excerpt
Choose a room
Choose a room first.
Room choices: West studio; East studio.
The visitor must know which room contains Clay basics.
Task-first entry, static excerpt
Choose a session
Session choices: Clay basics; Ink printing.
Each choice says Saturday · 3 places available.
The visitor can use the workshop name they already know.
Both entries can lead to Clay basics. Room-first entry requires prior room knowledge for this visitor; workshop-first entry exposes the known name. The difference is the required information, not merely one additional click.
The same room entry can suit a different person. An organizer checking what happens in East studio already knows the room and wants its sessions. Asking that organizer to open every workshop would add unnecessary searching. A design decision therefore needs both a person and a task. 'Rooms are confusing' is too broad. 'A first-time visitor cannot infer the room for a named workshop from these room names' identifies the missing information and suggests what the entry should expose.
Look at the two entry structures before selecting anything. In the reference, the first heading asks for a room. In the task-first example, both workshop names are available immediately. Predict which route requires you to guess for the Clay task, then choose West studio in the reference and Clay basics in the other. The useful observation is that one route requires prior room knowledge. The additional selection is a consequence of that requirement, not the entire reason to prefer a different entry.
A task description also sets a boundary on what counts as completion. Opening Clay basics is not reserving two places. Seeing its room is not confirming its time. A successful booking task must end with the requested workshop and quantity represented in an understandable result. In this lesson, that result is a local demo confirmation. The page cannot reserve real inventory or send a message. Treat a claim about a real booking as a separate requirement that this example does not satisfy.
Opening a review is different from finishing
Before confirmation, static excerpt
Review Clay basics
Saturday, 14:00. West studio. Materials included.
Seats: 2 selected
Next action wording: Confirm demo booking
After confirmation, static excerpt
Booking confirmed
Demo booking confirmed: 2 places for Clay basics. No payment or email sent.
Next action wording: Book another demo session
The result identifies the chosen session and quantity. It is evidence of the local transition only; the payment and email sentence prevents treating this result as a real service receipt.
For comparison, imagine a museum information page whose visitor only wants opening hours. Finding and understanding the hours may finish that task without changing anything. Studio Desk adds a different requirement because the visitor makes a choice that the interface must retain and later report. This difference explains why a visually clear workshop description is insufficient by itself. The interface also needs a path from choice to review to result, plus a way to reconsider the choice before committing it locally.
Try the interface
Your task: Book Clay basics in each flow. Go back from the review before confirming. Compare what you must know at each step.
Try two entry structures
Studio Desk demonstration. Actions affect this page only, not a real booking, account, or payment.
Reference flow
Studio Desk / Rooms
Choose a room
Choose a room first.
Task-first flow
Studio Desk / Workshops
Choose a session
Choose a session.
Stage
Available transition
Choose
Select a workshop, optionally through a room
Review
Change seats, go back, or confirm
Confirmed
Read the receipt or start another demo
The complete flow remains readable without running it.
The two flows are independent. Back retains the seat choice during review; Book another resets it. Reset flows restores both. Buttons change local example state, not browser history. There is no real inventory or payment service.
Follow a choice through the working flow
A state is the information the example currently holds, together with the stage it displays. In the flow, that includes a room, a session, a seat choice, and whether you are choosing, reviewing, or finished. An action changes some of that information. Selecting Clay basics records that session and opens review. Choosing two seats changes the quantity without leaving review. These distinctions explain why an interface can keep the same general appearance while the meaning of its next action changes.
Begin at review for Clay basics and choose two seats. Before confirming, use Back to sessions. The example returns to choosing and reports the previously selected session and retained seat choice. Open Clay basics again. Two should still be selected. This is a recovery path, not a second booking. You have changed the displayed stage while keeping relevant work. If Back instead silently restored one seat, a visitor could make an incorrect booking even after having entered the correct quantity earlier.
Back changes the stage without discarding the quantity
The local result reports 2 places for Clay basics.
This trace follows the working task-first flow. The quantity remains part of the current attempt while the visitor checks the session. Going back is not a second reservation.
Continue by confirming the demo booking. Read the complete result rather than treating the new heading as sufficient evidence. It names the number of places and the session and says no payment or email was sent. Those details let you compare intention with outcome. The demo result does not repeat every review fact, so the earlier time and location still matter. A real confirmation might need more information, but adding an imaginary receipt number here would describe a feature the model does not contain.
Now use Book another demo session. That action clears the session and restores the seat choice to one. It starts another local attempt instead of returning to the prior review unchanged. Compare this with Back to sessions, which retains the seat choice. The two actions have different purposes, so preserving everything is not always the correct policy. Retain work during reconsideration; deliberately reset the values that should not silently carry into a new booking. The labels should make that distinction predictable.
In the reference flow, return from review to sessions and then use Back to rooms. That clears the room and session, but the seat choice remains in this local flow until a new-booking action or reset restores it. Choose another room and open its workshop to inspect that consequence. A retained quantity can save re-entry, but it also needs checking against the newly chosen session. Here both sessions expose three places and the same seat options, so the model does not test changing availability between sessions.
Different return actions preserve different information
Action from the stated stage
Session after action
Seat choice after action
Back to sessions from review
Previously selected session retained
Retained
Back to rooms from reference session chooser
Cleared, along with room
Retained
Book another demo session from confirmation
Cleared
1
Reset flows
Both flows restored to their start
1 in both flows
Preservation follows the action contract. Back supports reconsideration within an attempt; Book another starts a fresh local attempt. Reset flows additionally restores both independent panels.
The two panels keep separate state. Selecting two seats in one does not change the other. Reset flows restores both panels to their starting choices. Stage and room changes focus the new heading so keyboard users have an orientation cue; the initial display does not force focus there. These are local controls inside a lesson, not destinations with separate addresses. Browser Back does not undo their steps. Use the example's own Back actions when exploring retained choices, or you will be testing a different navigation mechanism.
Describe states and transitions
A flow is a sequence of states connected by actions. Choosing a workshop, reviewing the choice, and receiving confirmation are different states. A button label should describe the transition it causes. A review page is useful when it allows someone to catch a consequential mistake, not simply because a template includes one.
The two working flows use the same sessions. One requires choosing a room before a workshop; the other starts with the workshop. Back preserves the selected context. Neither sends a real booking. Fewer clicks is not automatically better: a useful review can reduce mistakes, while a shorter but ambiguous flow can increase them.
Find failures between apparently valid screens
A transition can fail the task even when both its starting screen and ending screen look reasonable. Imagine choosing two seats, returning to check the workshop name, and finding one seat selected on review. Each screen could look complete in isolation. The failure lies in the connection between them. This is why inspecting screenshots alone misses important interaction problems. You need to compare the value before the action with the value afterward, then decide whether the change matches what the action promised.
The flow's review stage allows quantity changes, returning to sessions, or confirmation. These options separate correcting a choice from committing it. A useful review supplies information that can reveal a mistake and an available way to repair it. If it only repeats a decorative title and offers Continue, it may add work without increasing control. In this example, select three seats, reconsider, and choose one before confirming. The confirmation should report the final quantity, not the value you considered earlier.
A review supplies facts that can change the choice
Static review excerpt
Review Clay basics
Saturday, 14:00. West studio. Materials included.
Seats: 2 selected
Available actions: Back to sessions; Confirm demo booking.
Session identity, time, location, and the selected quantity allow a visitor to catch a mistake before confirming. A review with no identifying facts would add a stage without supplying the same opportunity to check.
Distinguish a constraint from a preference. The review offers one, two, or three seats. You cannot explore four seats through this selector, and the three-place display never changes because another visitor books. Those are boundaries of the demonstration. They do not establish that a production service checks current inventory. If capacity could change during review, a real service would need to reject or revise an unavailable request without pretending that an earlier availability label guaranteed success. That failure case needs an additional implementation.
Consider a wording change on paper, not a hidden option in the lab. Suppose the session-choice button said 'Book Clay basics' but merely opened review. Some visitors might expect immediate completion, while others might expect another step. 'Review Clay basics' would make the transition more explicit, although its suitability would still depend on the surrounding context. The mechanism is prediction: the label gives the person an expectation, and the next state either fulfills it or forces them to reinterpret what they just did.
Recovery also requires knowing what has not happened. Before Confirm demo booking, selecting a session and changing seats only prepare a choice. After confirmation, the page reports a local result, not a payment. A visitor who cannot distinguish those stages may repeat an action unnecessarily or leave before finishing. Check the review and result language separately. A strong visual treatment on Confirm can help locate it, but cannot compensate for a result message that leaves the person unsure which session or quantity the action used.
Recognize the wrong session before correcting it
Static review excerpt
Review Ink printing
Saturday, 14:00. East studio. Materials included.
Seats: 2 selected
Available actions: Back to sessions; Confirm demo booking.
Static review excerpt
Review Clay basics
Saturday, 14:00. West studio. Materials included.
Seats: 2 selected
Available actions: Back to sessions; Confirm demo booking.
These are successive static excerpts, not two real bookings. Back to sessions connects the mistaken Ink review to the corrected Clay review. The differing names and rooms make the error visible; the retained two-seat choice avoids re-entry.
Try a deliberate wrong-session path. In the task-first panel, open Ink printing when the intended goal is Clay basics. Review names Ink printing and gives East studio. Use Back to sessions, select Clay basics, and verify West studio before confirming. The correction depends on visible identity and an available return action. It does not require you to understand how state is stored. If the interface hid the selected workshop behind a generic 'Your choice' heading, the same available Back control would be less useful because the mistake would be harder to recognize.
Choose evidence that matches the goal
Observe whether intended users can complete the task, recognize the outcome, and recover from a mistake. Time alone misses wrong bookings and uncertainty about whether a save happened. A preference poll answers a different question from successful task completion.
This course uses original interfaces and constructed failure cases, not a reproduction of Refactoring UI or empirical proof that every revised treatment wins. It focuses on web applications, with visual craft and behavioral details considered together. An informational site may chiefly help someone find and understand content; these examples also require editable state, consequential actions, and recovery. No prior design course is required.
Judge the route by a complete task
Compare the flows using a specific goal rather than asking which looks nicer. For example, ask someone to arrange two demo places in Clay basics, check the choice, and report whether the task is complete. Do not include West studio in the instruction if discovering the appropriate entry is part of the question. Giving away the room would remove the very uncertainty the comparison is meant to expose. The instruction should specify the desired outcome without naming every control that achieves it.
Record what the person actually does and says. They may choose a room, pause, go back, or ask whether confirmation already happened. Separate those observations from your explanation. 'Opened East studio, then returned to rooms' is an observation. 'Did not know where Clay basics was listed' is an interpretation unless the person says so or other evidence supports it. This distinction helps avoid treating every pause as confusion or every quick click as understanding. A wrong choice made quickly remains wrong.
Keep an observed action separate from its explanation
Constructed observation note, not study data
The visitor opened East studio, returned to rooms, then opened West studio.
The final local result said 2 places for Clay basics.
What the note does and does not support
The path included a wrong-room detour and ended with the requested workshop and quantity.
The note alone does not reveal why East studio was chosen.
An action trace can establish a detour and a correct local outcome. Inferring missing room knowledge needs further evidence, such as the visitor explaining what they expected. This invented note illustrates the distinction without claiming a usability study.
A useful comparison includes correctness, recovery, and recognition of completion. For this constructed task, check whether the final result says two places for Clay basics, whether the person can change an earlier choice, and whether they understand the local nature of the result. Click count describes one kind of effort. It cannot tell you whether a route required an unsupported guess, whether the person noticed the seat count, or whether they mistook the demonstration for a real reservation that would persist after leaving.
Testing both routes in sequence introduces learning. After discovering that Clay basics is in West studio, the same person no longer faces the initial uncertainty in the reference flow. A faster second attempt may reflect remembered content rather than a better design. If you compare routes with other people, vary which they see first and keep the task and starting conditions explicit. Such precautions improve the interpretation of observations, but this lesson provides no participant results, timing measurements, or measured claim that one route always wins.
Change the task mentally while holding the interface fixed. For a visitor who knows Clay basics, workshop-first entry avoids room knowledge. For an organizer inspecting the west room, room-first entry may be direct. For someone choosing by date, neither starting structure fully answers the question because the chooser provides little schedule detail. This last case is not a reason to invent a date filter in the lab. It is evidence that the current interface supports a bounded set of tasks and leaves other needs unresolved.
Change the task and the useful starting information changes
Visitor task
Arrange two places in Clay basics.
Known information: workshop name and quantity.
Workshop-first entry exposes the known name.
Organizer task
Inspect what happens in West studio.
Known information: room.
Room-first entry exposes the known room.
A route is appropriate relative to a question. These goals need different starting information, so the visitor comparison cannot establish that room-first navigation is universally worse.
Apply the distinction to an ordinary settings page. A person who wants to change a receipt address needs to find the setting, edit it, understand what Save does, and recognize the accepted result. Counting how many panels they open omits whether they changed the right address or lost the old value after a failure. Studio Desk's local flow teaches the same connection between intention, action, and evidence. It demonstrates retained choices and explicit stages, while leaving server acceptance, persistence, and real-world availability outside its claims.
Exercises
Replace an internal task label
A visitor wants an evening printing class. The entry button says "Create allocation record." Propose a better entry and explain what must follow.
Hint
Name the visitor's goal, not the database mutation.
Worked answer
Internal concept
Visitor-facing need
Allocation record
A place in a workshop
Room identifier
Where the session happens
Write succeeded
Booking confirmation
Translate the task, not just the nouns.
Use an entry such as "Find a workshop" or "Book a place," depending on the next screen. Show dates, availability, and the information needed to choose. Do not label an action "Book" if it only opens unrelated account settings. The wording must match the transition.
Evaluate an extra review step
A new review adds a click but exposes the selected session and number of seats. Is removing it necessarily an improvement?
Hint
Ask what mistakes it catches and whether the preceding choices are reversible.
Worked answer
Measure
Question
Correct completion
Was the intended session booked?
Recovery
Could the choice be changed?
Time
Did the review add useful or avoidable work?
A workflow should be judged against its consequences.
No. Compare correct completion and recovery as well as clicks or time. A clear, editable review can catch a wrong session or seat count. If it repeats a trivial reversible action, it may add unnecessary work. Test the actual task rather than optimizing a click count in isolation.
Sources and further reading
Selected guidance and technical definitions were reviewed, not a complete usability literature or accessibility audit. The interfaces are original teaching examples. They do not establish measured improvements in task performance. These optional links are not runtime dependencies.