Skip to content

02 · Napkin sketch to app prototype ​

At a glance ​

OutputA mobile or desktop interface prototype
Time20 to 40 minutes
TypePrototype
You needA sketch. Drawing badly is fine.

The situation ​

There's an interface in your head you can't describe but can draw. Or the reverse — you can rough it out but you can't do visuals.

The insight here: a sketch carries structure and layout intent, not craft. A circle and a rectangle read as "avatar here, content card there".

How ​

Step 1 · Draw it ​

Paper, iPad, whatever. Care about three things:

  • Which blocks exist, and roughly how much space each takes
  • What's above what, and what sits beside what
  • Which action is primary (circle it)

No icons, no lettering, no accurate proportions.

Step 2 · Save it as a file ​

Photograph or export it into the project directory.

Step 3 · The prompt ​

text
This is a hand-drawn interface sketch.

Build a mobile screen following its structure.

The sketch elements map to:
- [circle, top left] = user avatar
- [horizontal bars, centre] = a list of tasks
- [rectangle, bottom] = the primary action button
- [small shape, top right] = filter entry point

What the screen is for: [purpose]
When it gets opened: [context]

Requirements:
1. Follow the sketch's layout. Do not rearrange it on your own judgement.
2. Visuals come from the current design system.
3. Cover all states: empty, loading, error, one item, many items.
4. Use realistic sample content — no Lorem ipsum — but label the
   sample data as sample.
5. Touch targets at least 44×44.

Build this one screen only.

Why it's written this way ​

Mapping each sketch element explicitly is the critical move. Left to guess, it will guess, and a wrong guess costs a regeneration. Thirty seconds of mapping beats two rebuilds.

"Do not rearrange it" has to be said. Its default is to "improve" your layout toward something more conventional, and the layout is exactly why you drew a sketch.

"This one screen only" bounds the work. Five screens at once leaves you nothing you can fix precisely.

Acceptance ​

  • [ ] The layout matches the sketch
  • [ ] All five states exist
  • [ ] Touch targets are thumb-sized
  • [ ] Sample data is labelled
  • [ ] Checked at real phone widths (375px and 430px)
  • [ ] The primary action is findable at a glance
  • [ ] No Lorem ipsum left

Variants ​

Extend to a flow

text
Using this screen's design language, build the rest of the flow:
1. The form after tapping "new"
2. The success feedback after submitting
3. The detail view after tapping an item

Keep components, spacing, and motion identical to the first screen.
Every screen covers all states.

Make it clickable

text
Wire these screens into a clickable prototype:
- Primary action → form
- Submit → success → back to the list
- List item → detail, with a back affordance

Use restrained slide transitions. No bounce.

Sketch to image rather than interface

The same approach produces illustration and posters. Draw a crude shape, ask for a finished image. Genuinely useful for people who can't draw — all you need is compositional intent.

Questions that come up ​

It changed my layout.

Push harder: "the relative positions and area proportions in the sketch are design decisions. Do not optimise them. If you think something is wrong, tell me instead of changing it."

It looks like a generic template.

The sketch supplies structure; register comes from the design system. Pick one, or do playbook 04 and extract your own.

The sketch is too abstract for it.

Two fixes: map the elements in more detail, or write labels directly on the sketch — it reads them.

Mine is a complex form.

Spell forms out separately: fields, validation rules, when errors appear. Lean on the craft rule: "handle validation per the form-validation rules — when validation fires, how errors reach assistive technology, and which layer owns the rule."

An unofficial community guide · compiled from open-design.ai public material and hands-on notes · the official docs win where they differ