Paper, Pencil, and a Prompt. Why Low-Fi Is Beating Figma.

The founders shipping fastest right now are not spending their first week in Figma. They are sketching on paper, describing what they drew to Claude Code, and iterating on working software before their competition has finished a moodboard.

That is not a productivity hack. It is a workflow that matches what actually needs to happen at idea stage.

What low-fi to AI actually means

Low-fi prototyping with AI is a four-step loop. Sketch the rough structure of a screen on paper: boxes for content areas, labels for navigation, arrows for user flow. Photograph or describe the sketch to Claude Code. Prompt for a working implementation. Iterate on the output until the behavior is right. Then and only then, bring it into a more refined tool if you actually need to.

The key word is "working." The output of this loop is not a mockup or a wireframe. It is a functional interface that does the thing it is supposed to do. A real user can interact with it. That changes what you learn from it.

Why seed-stage Figma is often malpractice

At seed stage, the highest-value uncertainty to resolve is whether the core concept works. Does the thing you are building solve the problem you think it solves? Can users figure out how to use it?

A polished Figma prototype cannot answer those questions. Click-through mockups produce what researchers call "desirability bias": users react to how the product looks rather than how it works. They say it looks great. They cannot tell you whether the user journey is broken because they are clicking through predetermined paths, not actually navigating an interface.

A working prototype built from a paper sketch and a Claude Code prompt can answer those questions. It is rough. It has no visual polish. It works. Real users navigating it will find the navigation assumptions that were wrong, the missing states that were forgotten, and the feature that seemed obvious but isn't.

Finding those problems with a rough working prototype costs almost nothing to fix. Finding them after three weeks of Figma work and another two weeks of development means rebuilding something that was already expensive to build once.

A real example: sketch to working UI in 48 hours

A founder working on a project management tool for creative freelancers sketched their onboarding flow on paper: four screens, rough boxes for the main content areas, handwritten labels. They described the sketch to Claude Code in three paragraphs, including the core actions on each screen and what needed to happen after each one. Forty-eight hours later, they had a working onboarding flow that real users could navigate. The first user test revealed that screen three was confusing because it asked for information the user had already provided on screen one. That insight cost nothing to find. Fixing it took two hours.

Under a traditional Figma-first workflow, that insight would have cost three weeks of design time plus however long it took to build the prototype before the first user test. The sketch-to-Claude path collapsed that to two days.

When to graduate from low-fi

Low-fi AI prototyping is the right tool for validating whether something works. It is not the right tool for finalizing how something looks, building a scalable design system, or presenting to investors who will evaluate visual quality.

The signal that it is time to graduate: you know the core user journey works because real users have navigated it and you have watched them. At that point, bringing the interface into Figma for visual refinement and design system documentation is the right move. Not before.

The founders who skip this transition and try to build investor-ready visual quality into their rough prototype too early end up polishing something that still has fundamental flow problems. The order matters. Rough and working first. Polished and working second. Polished and wireframe-only is not a step in this sequence.

Sketch on paper. Describe to Claude. Build something real. Everything else comes after that.