Why start with paper
Changing a drawing takes seconds. Changing a built screen can take hours, and changing a whole structure after the code is written can take days. Sketching first moves your mistakes to the stage where they are cheapest to fix.
Paper also keeps the conversation honest. A rough sketch invites comments about structure and flow, such as “where do I go from here?” Polished mock-ups tend to attract comments about color and fonts, which are the wrong questions at the start. Nobody feels precious about a sketch, so people are more willing to say it is confusing.
You do not need drawing skill. Boxes, lines and labels are enough.
What you need
- Plain paper, index cards or sticky notes
- A pencil and an eraser, or a thin marker
- A ruler, if you like neat boxes
- A printed or drawn phone outline, ideally close to actual device size
- A few people willing to try it
Printed templates with phone outlines are easy to find, or you can trace around a real phone. Using the actual size matters because it shows how much room you genuinely have and how large a fingertip is compared with your buttons.
Steps for a first pass
1. Write down the task
Before drawing, state in a sentence or two what the person is trying to do. For example, “add an expense and see this month’s total.” Short user stories work well here. You are designing a path through the app, not a collection of attractive screens.
2. Sketch many quick versions
Draw the main screen several different ways in a few minutes. Do not fall in love with the first idea. Trying a list, a grid, and a single large action button side by side will teach you more than polishing one layout. Aim for quantity at this stage.
3. Pick one and draw the flow
Choose the most promising version and draw each screen needed to complete the task, one per sheet or card. Add arrows showing what each tap leads to. Mark the buttons and give them real labels, since vague stand-in labels hide problems.
4. Check the structure
Spread the sheets out and look at the whole. Are there dead ends? Can people get back? Is the same thing done differently on two screens? This is also the stage to decide how screens relate, using familiar navigation patterns such as tabs or stacked screens.
5. Test with a person
Place the first screen in front of someone and ask them to do the task. They point where they would tap, and you swap in the next sheet. This is called paper prototyping. A few rules help:
- Explain the task, not how to do it.
- Stay quiet and watch. Resist helping.
- Ask them to think out loud.
- Note every hesitation, wrong tap and question.
- Thank them, and never defend the design.
Testing with even three to five people often reveals the biggest problems, although the exact number is less important than the habit of watching someone try. People who match your intended audience give the most useful feedback.
What to look for
- Places where people cannot tell what to tap
- Labels that mean something different to users than to you
- Steps that feel unnecessary
- Missing screens, like what happens when there is no data yet or when something fails
- Controls that are hard to reach one-handed, which you can judge by holding the printed outline and considering thumb reach
- Text that would be too small once printed at real size
Sketch the awkward cases as well as the happy path: an empty list, a long name that does not fit, an error, a slow connection. These are easy to forget and painful to discover late. Offline behavior is a good example, discussed in offline mode.
From paper to something clickable
Once the sketches stop changing much, you can move to a more detailed wireframe: a cleaner drawing in a simple design tool, still without colors and imagery. Some tools let you link screens so they can be tapped through on a phone. You can also photograph your paper screens and link them in a presentation app. The point is the same, to test behavior before building.
Only after the flow works should you add visual design such as colors, typography and imagery. At that point, matters like color contrast and dark mode design become relevant. Layering them on too early distracts from structure.
Keep the sketches useful
Date your versions and keep them, even the rejected ones. They record why a decision was made, which helps if you work alone and plan across weeks. Notes from your tests are valuable, so write down what you changed and why. These records support solo app planning and give you something concrete to share with a developer if you later hire help.
Common mistakes
- Jumping to polish. Beautiful screens are not evidence that the flow works.
- Designing alone. You know too much about your own app to see its confusion.
- Testing with friends who want to be kind. Ask for honest criticism and watch behavior rather than relying on opinions.
- Skipping the unhappy paths.
- Trying to draw everything. Cover the main task first.
Paper will not replace testing on a real device later, but it will make that later testing far more productive. If a rough sketch can’t be understood, a finished app probably won’t be either.