Skip to main content

Designing How It Flows

Share

Share this page

Pass it to someone who needs it.

Star on GitHub

Key takeaway: Design the path to done

Chapter 10 of 15 · Harden

Make it a solid, complete product

Your app works and your system runs it, and it is still not a product. This part rounds the rough edges into something real: a proper interface, real accounts, safe data changes, and the reliability that keeps it standing when things go wrong.

By the end of this part, you can:

  • Turn a rough build into a finished, usable product
  • Handle accounts, payments, and email the right way
  • Change your live data without losing any of it
  • Make it hold up when something inevitably fails
Done:Automate·You are here: Harden·Next:Secure

Your app has screens, and each one works. But someone landed on it to get one thing done, and the path from opening it to done winds through more steps and dead ends than it should. That path is the product, more than any single screen is. This chapter gets you the shortest clear route to the goal, with every screen ready for the ways real use goes sideways.

10.1.1Design the shortest path to done

A user came for one job: send the invoice, book the room, save the note. The user flow is the path they take across screens to reach it: an entry point, a few steps, the goal reached.

Designing the experience means designing that path, the journey between screens, not the styling of any one of them. Styling each screen is its own job; here you design how they connect. The goal at the end is the one from the spec you wrote when you planned, the reason the whole app exists.

10.1.2Map the main flow before you judge it

You cannot shorten a path you have not drawn. Write the main flow as a single line, entry to goal, one box per screen the user actually touches: Open app -> Pick a template -> Fill three fields -> Saved.

Laid out like that, the extra step jumps out at you: the confirmation nobody needs, the settings screen between the user and their goal. Read the line and ask of every box: does the user have to be here to reach the goal?

10.1.3Cut the steps the agent piles on

Left alone, an agent adds. It offers a settings page nobody asked for, a confirmation step, a field that could default itself. Each one is friction: a place the user has to stop and think, and every stop loses some of them.

Your job is subtraction. Fewer steps, sensible defaults so the common choice is already made, and a next action that is always obvious. When you truly cannot cut a step, make it the only thing on that screen.

Ask it of every step; cut what the user does not need to reach the goal.

10.1.4Every screen has four states, not one

Here is the flow lesson the agent skips hardest. It builds each screen for the one moment when everything is present and correct, and ships only that.

A real screen has four states: empty (no data yet), loading (working), error (it failed), and success (it worked). Name all four or you get only the last one. The empty and error states are where flow is won or lost. An empty screen should show the first step instead of a blank box, and an error should say what broke and how to fix it.

Every screen, four states: [ ] Empty no data yet: show a first step, not a blank [ ] Loading working: show it is busy, not a frozen page [ ] Error it failed: say what went wrong and how to fix it [ ] Success it worked: the result, and the obvious next action

10.1.5Make every screen usable by everyone

Some of your users move by keyboard, some by screen reader, some at 200% zoom, and a flow they cannot finish is a customer you cannot bill. Five checks are the floor, and your agent adds every one of them once you name them:

Accessibility floor, every screen: [ ] Keyboard every action reachable without a mouse [ ] Focus a visible ring showing where you are [ ] Labels every input tied to a real label [ ] Alt text on every image that carries meaning [ ] Contrast text readable in daylight

The deeper pass, making the whole app fast and properly accessible, comes later in the book.

This prompt maps your flow, marks the friction, and designs all four states:

Ready prompt
Act as a senior product designer. Do not restyle anything yet; work on the flow. Read my spec, my must-have stories, and my screen map first. First, map the main flow as a line of screens from entry to the one goal my spec says users come for. Keep it to the fewest screens that reach it. Then flag friction: every extra step, field, or choice on that path I could cut, default, or merge. Recommend the shortest version. Then, for each screen in the flow, design all four states: empty (no data yet), loading, error (what failed and how to fix it), and success (the result plus the next action). Then check each screen against the accessibility floor: reachable by keyboard alone, a visible focus ring, every input labelled, alt text on meaningful images, and readable contrast. Give me the flow and the cuts first, for my approval, before you design the states. Where a cut drops something my spec promised, say so instead of dropping it quietly, and record the cuts I approve in my decision log. If you need the full reasoning behind this step, read https://zalt.me/guides/vibe-coding/harden/designing-the-flow My app and the one job users come to do:

Do this now: paste the prompt and describe your app and the one job users come for. Have your agent map the flow, mark the steps to cut, and design all four states for each screen, before you polish how any of it looks.

Mahmoud Zalt

Mahmoud Zalt

Software engineer, 16+ yrs · built Sistava.com in 3 months, idea to production, using these methods

Resources
Star on GitHubContribute
Donate

Support my work

A small tip keeps the free work coming.

© 2026 Mahmoud Zalt. Free to read, not to republish.
Copyright & license