User Flows and Wireframes for Non-Designers: A Practical Guide (2026)
How to map a user flow and sketch wireframes for your app idea with no design training, using paper or free tools, and test them before anything is built.
Key Takeaways
- Flow first, screens second. Decide the steps a user takes before you draw any screen. Most layout problems are really flow problems.
- Low fidelity is a feature. Grey boxes and real words get honest feedback about structure. Colours and logos invite opinions about taste.
- Use real content, not lorem ipsum. Real labels, real names and real button text reveal problems placeholder text hides.
- Test sketches with people before building. Nielsen Norman Group calls paper prototyping one of the fastest and cheapest techniques in a design process.
- Draw the unhappy paths too. Empty screens, errors and “what if they’re not signed in” are where real apps confuse people.
Quick-Start Prioritization Framework
| Step | Tool | Time | Output |
|---|---|---|---|
| Write the user’s goal | A sentence | 5 minutes | “A tenant reports a leak and knows it’s being handled.” |
| List the flow steps | Sticky notes or a list | 20 minutes | 5–8 steps, start to value |
| Add decisions and dead ends | Arrows and diamonds | 20 minutes | Branches for errors, empty states, sign-in |
| Sketch one wireframe per step | Paper, or a free tool | 1–2 hours | Rough screens with real labels |
| Test with 3–5 people | Printed sketches or clickable frames | 1–2 hours | A list of where people got stuck |
You don’t need to be a designer to work out what your app’s screens should be. You need two simple tools: a user flow, which lists the steps someone takes to get a job done, and wireframes, rough boxes-and-labels sketches of each screen in that flow. Together they catch most of the confusing parts of an app before anyone builds it, when changes cost a pen stroke instead of a rebuild. This guide shows you how to make both, with a worked example, and how to test them with real people in an afternoon.
What user flows and wireframes are
Designers use many overlapping terms. You only need two.
User flow
Nielsen Norman Group defines a user flow as a set of interactions describing the typical or ideal steps for a common task within one product. It is narrower than a user journey, which covers a person’s whole experience across channels and time. For a first app, the flow is what you need: the steps inside your app, from opening it to getting the result.
Wireframe
A wireframe is a simple drawing of one screen: where the heading, the list, the buttons and the inputs go, with real labels, but no colours, images or styling. It answers “what is on this screen and in what order?” and nothing more.
Why bother if an AI tool can generate screens
AI builders can produce good-looking screens in seconds, which makes it tempting to skip this step. But a builder can only design what you describe. If you haven’t decided what happens when a user isn’t signed in, or when a list is empty, the tool will guess. Ten minutes of flow mapping makes your description, and therefore the result, far more precise.
How to map a user flow
You need a goal, a starting point and an end point. Everything else is the steps between.
1. Write the goal as an outcome
State what the user has achieved at the end, in their words: “A dog owner books a walk for Thursday and gets confirmation.” Not “uses the booking feature”. An outcome tells you where the flow ends.
2. Pick the entry point
Where does the user start? A link in an email, the home page, a shared link from a friend? The entry point changes the first screen. Someone arriving from an invite email already knows what the app is; someone arriving from a search doesn’t.
3. List the steps in order
Write one step per sticky note or line: what the user sees, and what they do. Keep going until you reach the outcome. If you pass eight steps, look for ones you can merge or remove.
4. Add the branches
Now go back through each step and ask: what could go differently here? Not signed in. No results. Wrong input. Payment declined. The thing they want is taken. Draw each as a branch (a diamond for the question, arrows for each answer) and decide where it leads. This is the step most first-timers skip, and it is where most confusion in real apps lives.
A worked example: booking a dog walk
Here is a complete flow for a small app that lets a dog walker’s regular clients book walks.
The happy path
- Client opens the booking link from the walker’s text message.
- Signs in with email (first time: enters name and dog’s name).
- Sees the next two weeks with free slots highlighted.
- Taps Thursday 12:00.
- Confirms dog, adds a note (“Key under the mat”), taps Book.
- Sees “Booked: Thursday 12:00 with Jo” and gets a confirmation email.
The branches
| At step | What can happen | Where it leads |
|---|---|---|
| 2 | Already signed in | Skip straight to step 3 |
| 3 | No free slots in two weeks | Message “Fully booked until [date]” plus a waitlist button |
| 4 | Someone else books the slot first | Message “That slot was just taken” and the calendar refreshes |
| 5 | Client has two dogs | Checkboxes to pick which dogs |
| 6 | Client wants to cancel later | Link in the email to a “My bookings” screen with Cancel |
What the flow revealed
Mapping the branches surfaced three screens the founder hadn’t planned: a waitlist, a “My bookings” page, and a dog picker. It also raised a question for the walker: how late can a client cancel? Those are the kinds of decisions you want made on paper, not discovered in week three of building.
How to sketch wireframes
With the flow done, draw one wireframe for each step and each branch screen. Speed matters more than neatness.
Choose your tool
Paper and a thick pen are the best tool for a first pass: you can’t fuss over details, and you can throw away a screen without regret. Draw on index cards or phone-sized rectangles, since most people will use your app on a phone. When you want something shareable, a free design tool works. Figma’s Starter plan is free and includes UI kits and templates. Use whatever you can move fast in.
The anatomy of a screen
For each screen, draw these from top to bottom: where am I (a title), what can I see (the content, as boxes and real text), what can I do (buttons and inputs, labelled with the exact words), and how do I go back or elsewhere (navigation). Mark the one main action on each screen, the thing most people should do next, with a heavier box.
Write real words
Write “Book Thursday 12:00”, not “Button”. Write “No free slots until 14 March”, not “Empty state”. Real words force decisions and make tests meaningful, because testers react to what the screen says.
Draw the states, not just the screens
Many screens have several states. The calendar has free slots, no free slots, and loading. A form has empty, filled, error and success. Draw the ones from your branch table. They take five minutes each and save a lot of confused users.
Simple layout rules that work
You don’t need design training to make clear screens. A handful of rules covers most of it.
- One main action per screen, visually stronger than everything else.
- Put things in the order people need them: what it is, the details, then the action.
- Use the words your users use. If clients say “walk”, don’t label it “session”.
- Show the result of every action: a confirmation, a changed status, a message.
- Keep forms short. Every field should have a reason; ask for the rest later.
- Design for a phone first. If it works on a narrow screen, it will work on a wide one.
- Make empty screens helpful: say why it’s empty and what to do next.
Testing wireframes before building
Nielsen Norman Group describes paper prototyping as one of the fastest and cheapest techniques available, and notes that changing a design before code exists is far cheaper than changing it after. You don’t need a lab. You need three to five people who match your user and an hour.
How to run a paper test
Lay out the first screen. Give a task in one sentence: “Book a walk for next Thursday at lunchtime.” When they tap something, put the next sketch down. Don’t explain or help. Note every hesitation, wrong tap and question. If they ask “what does this do?”, ask back “what would you expect?”
How many people
Nielsen Norman Group’s research found that five users uncover about 85% of usability problems, and recommends several small rounds rather than one big one. Test with three to five, fix the sketches, test again.
Clickable prototypes
Once the paper version holds up, you can link screens in a design tool so testers tap through on their own phone, which helps for remote tests. Or skip straight to a rough working version: with AI builders, a real app with a database can be faster to make than a polished clickable mock-up, and it lets you test with real data.
From wireframes to a build
Your flow and sketches become the instructions for whoever builds the app.
Handing over to a person
Share the flow diagram, a photo or file of each wireframe labelled with its step number, and the branch table. Ask the builder to walk through the flow back to you. Gaps in their understanding are gaps in your sketches.
Handing over to an AI builder
Describe the flow in numbered steps, then each screen in words: what it shows, what each button says, and what happens on each branch. Many builders accept images too, so a photo of your sketch alongside the description works well. Build the happy path first, then add branches one at a time and test each.
Common mistakes
These are the traps non-designers fall into most often. All are easy to avoid once you know them.
- Starting with the home page instead of the main task. The home page is often the least important screen.
- Drawing in high fidelity too early, then defending a design instead of improving it.
- Using placeholder text, so tests can’t reveal confusing labels.
- Mapping only the happy path and forgetting empty, error and signed-out states.
- Putting several equally prominent buttons on one screen.
- Testing with the people who helped design it, who already know how it works.
- Explaining the screens during a test instead of watching what people do.
If you’d rather not do this by hand
If you’d rather not draw screens yourself, Floot, the AI app builder that publishes this site, has a design canvas that shows several page ideas side by side so you can compare them, then builds the chosen design as a working app with a live preview.
Frequently Asked Questions
What is the difference between a user flow and a wireframe?
A user flow is the sequence of steps someone takes to complete a task, usually drawn as boxes and arrows. A wireframe is a simple sketch of one screen in that flow. You map the flow first, then draw a wireframe for each step.
Do I need design software to make wireframes?
No. Paper and a pen are ideal for a first pass. When you want to share or click through screens, a free tool such as Figma’s Starter plan works.
How detailed should wireframes be?
Detailed enough to show what’s on each screen and what every button says, and no more. Skip colours, images and fonts until the structure has been tested.
What is the difference between a wireframe, a mockup and a prototype?
A wireframe shows structure in grey boxes. A mockup adds the visual design: colours, type and images. A prototype is clickable or usable, so people can try the flow.
How many screens should my first app have?
As many as your main flow and its branches need, often five to ten for a first version. If you have many more, the first version is probably doing too much.
How do I test wireframes with users?
Give three to five people who match your user a task, show them the first sketch, and swap in the next sketch each time they tap. Watch without helping and note where they get stuck.
Sources
- Nielsen Norman Group, User Journeys vs. User Flows https://www.nngroup.com/articles/user-journeys-vs-user-flows/
- Nielsen Norman Group, Paper Prototyping: Getting User Data Before You Code https://www.nngroup.com/articles/paper-prototyping/
- Nielsen Norman Group, Why You Only Need to Test with 5 Users https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
- Figma, Pricing, 2026 https://www.figma.com/pricing/