From the spec to a user flow

In From idea to one-page spec you wrote the smallest useful version of the reorder app: Ravi signs in, sees his last orders, repeats one in three taps with quantities he can adjust, sees the order's status and gets a weekly summary. A spec lists what the app must do. It does not say in which order things happen, what the owner sees at each moment, or what happens when something goes wrong. A flow does.

A user flow is the path one user takes through the app to finish one task. Write it as numbered steps, and give each step three parts: the screen the user sees, the action they take, and what the app does in reply. Write one flow per task, and start from the user's goal in their own words: "Order the same as last Monday, with two more cases of cooking oil." Then write the steps.

1. Home: Ravi sees his last three orders as cards. He taps last Monday's order. (tap 1)
2. Order detail: he sees the 22 items and the total. He taps Repeat. (tap 2)
3. Review: the same items appear with last week's quantities. He changes cooking oil from 6 to 8 cases and the total updates. He taps Place order. (tap 3)
4. Status: the app shows that Mangrove received the order and the delivery day.

That list is the happy path: everything works and the user makes no mistakes. It is where you check the spec's promise. Count the taps. The "three taps" in the spec are open, repeat and place. Changing a quantity costs an extra tap or two, and that is fine because it is optional. Writing the count down early stops a common drift, where each review adds "one small confirmation" until the core task takes seven taps.

Then go back over each step and ask what else could happen there. Ravi has no orders yet. An item from last week is out of stock. The price of rice went up. The network drops while he taps Place order. Each answer is a branch, another way out of that step. You do not need to design every branch today, but you must list them, because each one becomes a screen state, a rule in the API or a test later. A good rule for a first flow: one happy path, and for each step the two or three branches that will happen every week.

Sketching screens: one job each, every state

Now draw each step as a screen, on paper, on a whiteboard or as boxes in a design tool. Keep it at low fidelity: grey boxes, real words, no colours or logos. Low fidelity helps you. People criticise a rough sketch more freely than something that looks finished, and you can redraw a sketch in two minutes while the shop owner watches.

Give each screen one main job and one main action. The Review screen's job is "check this order and send it", and its main action is the Place order button. Everything else on the screen supports that job: the item list, the steppers, the total. Put the information a user needs for a decision on the same screen as the decision. Ravi decides whether to send the order partly from the total, so the total belongs on the button itself: "Place order, $412.60". Use real data in sketches: real product names, real quantities, prices with cents. Placeholder text like "Item 1" hides the very problems you are looking for, such as a long product name that wraps onto three lines on a small phone.

Every screen that loads data also has several states. Sketch each one, because each needs its own words and layout:

• Loading: the data is on its way. On patchy mobile data this can last several seconds, so show what you can, such as the orders saved on the phone last time, instead of a blank screen.
• Empty: there is nothing to show yet, as for a new shop with no orders. Say what will appear here and what to do next.
• Error: loading failed. Say what happened in plain words and offer one action, usually Try again.
• Partial: some of it works, such as an order where two of the 22 items are out of stock.
• Normal: the screen as you first imagined it.

Draw for the real conditions. Partner shop owners use their own phones, often cheap Android phones with small screens, used with one hand while a customer waits at the counter. Keep the main button near the bottom where a thumb reaches it, and make tap targets large. Android's accessibility guidance asks for at least 48 by 48 density-independent pixels, and Apple's asks for at least 44 by 44 points. Design for PMs and Designing for frontline work go deeper into hierarchy, accessibility and working conditions.

Designing the unhappy path: slow, failed or unknown

The most important branch in the reorder flow comes after Ravi taps Place order. On a fast connection the reply comes back in under a second. In a shop with patchy mobile data, one of three things happens. The server replies that the order is placed. The server replies with an error. Or no reply arrives before the app stops waiting, which is called a timeout. The third case is the dangerous one, because the app does not know whether the order reached the server. The request may have been lost on the way, or the order may have been saved and only the reply lost.

If the screen says "Failed, try again" in that case, Ravi taps again and may get two deliveries of 22 items. If it says "Placed", he may wait for a delivery that never comes. Neither is acceptable for an app whose purpose is to be more reliable than a phone call, when about 1 phone order in 12 is corrected after delivery today. So the flow needs a third message, such as "Checking your order", and a rule: the app asks the server whether the order arrived before it offers to send it again.

Protect the screen from double taps, too. From the moment Ravi taps Place order, the button shows "Sending" and cannot be tapped again. Each order attempt gets an idempotency key, a unique ID the app creates once and sends with every retry of that same order, so the server can recognise a repeat and return the first result. You will build the server side in Data model and API and the app side in Building the app, and the idempotency lesson in the API course goes deeper. At this stage your job is to put the states on paper, so the people who build them know they exist.

Testing the flow with a partner shop

A flow on paper is still your guess. Before anyone writes code, put it in front of the people who will use it. Testing ideas cheaply explains usability tests in full. Here is the short version for one developer and one flow.

Make a paper prototype: one card per screen and per important state, drawn at roughly phone size. You play the computer. When the owner taps a button with his finger, you put down the next card. When he taps Place order, you put down Sending, wait three seconds, and then put down the result you planned to test, including Not sure. A clickable prototype in a design tool such as Figma or Penpot works too, and it runs on the owner's own phone, which is closer to the real thing. Paper is faster to change between sessions.

Run each session in the shop, at a quiet time the owner chooses, for about 20 minutes:

1. Explain that you are testing the design, not him, and that nothing he does can be wrong.
2. Give one task as a goal in his words: "Your delivery comes Thursday. Order what you ordered last Monday, with two more cases of cooking oil." Never name the button.
3. Ask him to think aloud, and do not help. If he asks what to do, ask what he would try if you were not there.
4. At each step, write down where he hesitated, what he tapped that did nothing, what he said and how many taps it took.
5. At the end, ask what he expected to happen after Place order, and how he would know the order went through.

Three to five shops, in one or two days, will show you most of the serious problems. Then sort what you saw by severity. A blocker stops the task or makes the owner finish it wrongly. A slowdown makes the task slow or uncertain. A cosmetic problem is everything else. Fix every blocker in the sketches, then run a second small round with different owners to check that the fixes worked. Keep your notes and the list of changes: the course project asks for them.