Design Prototyping for React: Where the Architecture Actually Starts

The way most engineers relate to a design file is as a target to hit. The designer hands over a Figma frame, and the job — as everyone tacitly agrees — is to make the screen look like the picture. Pixel for pixel, color for color. Reproduce it, get it approved, move on.

I want to push on that framing, because I think it's the root of a lot of avoidable pain. A design isn't a picture you copy. It's the first draft of your component architecture, whether anyone treats it that way or not. The structure of that screen — what repeats, what nests, what varies, where the boundaries fall — is the structure of the code you're about to write. Which means the most consequential architectural decisions in a feature are often made in a design tool, by someone thinking about spacing and hierarchy, long before an engineer opens their editor. And when the design's structure and the code's structure disagree, you get the codebases everyone recognizes: technically matching the mockup, quietly miserable to maintain.

So this article is about reading a design the way it deserves to be read — as architecture — and why that shift changes both what you build and how you work with the people who design it.

A Design Has Structure, Not Just Appearance

Look at any real screen and there are two different things present at once. There's the appearance — the colors, the fonts, the shadows, the exact pixels. And there's the structure — this card repeats six times, that button is the same button as the one on the other screen, this panel contains a header and a list, these three stats are the same shape with different data.

Reproducing appearance is the shallow job. Reading structure is the real one, because structure is what maps to components. When you see six cards, the architectural fact isn't "six cards" — it's "one Card component, rendered six times." When you see a button here that's clearly the same button as three other screens, the fact is "this is one shared Button, not a thing I restyle locally each time." The design is quietly telling you what your components are, what your reusable primitives are, and how they compose. A developer who only sees the picture reproduces the pixels and invents an ad-hoc structure underneath. A developer who reads the structure lets the design hand them their component boundaries for free.

A mockup shows you what the screen looks like. Read carefully, it also shows you what your components are, which ones repeat, and where they compose. The second reading is the one that keeps your codebase sane.

Same Component, Different States — the Thing Static Mockups Hide

Here's where the "design is a picture" framing does the most damage, and it's the single most valuable thing to internalize about prototyping for React.

A static mockup shows you one moment. But a React component is never one moment — it's every state that data can put it in. The screen you were handed shows a list with eight items. Your component also has to handle: zero items (the empty state), one item, hundreds (does it scroll, paginate, virtualize?), the loading moment before any data arrives, and the error case when the fetch fails. The mockup showed you one of five or six realities, and if you only build the one you were shown, you'll ship a component that looks perfect in the demo and breaks the first time real data is empty or slow.

This is why the most useful thing you can do with a design isn't to start coding it — it's to interrogate it. Before writing the component, I go looking for the states the mockup didn't show. What does this look like with no data? While it's loading? When it fails? When the text is three times longer than the placeholder? When there are two hundred rows instead of eight? Half the time the honest answer is "the designer didn't think about that yet," and surfacing it before you build is enormously cheaper than discovering it in QA. The static frame is the happy path; your component is responsible for all the paths, and prototyping is where you find the missing ones.

This Is a Conversation, Not a Handoff

That interrogation is exactly why I don't think of design-to-code as a handoff. A handoff is one-directional: design finishes, throws the result over a wall, engineering catches it. But the questions that matter — what are the empty and error states, is this really the same component as that one, does this pattern already exist in our system — can only be answered together, and answering them early is where the leverage is.

When engineering engages with design during prototyping instead of after, a few things change. Reusable pieces get spotted before they're built five slightly-different times. Missing states get designed instead of improvised by whichever developer hits them first. And the design starts to align with the components that already exist — which connects straight back to the design systems idea: a prototype built from the components you already have is a prototype that ships in a fraction of the time, because the answer to "how do I build this" is "you mostly already did." The handoff model forecloses all of that by making the conversation happen too late, after the structural decisions have already hardened on both sides.

I'm not arguing engineers should design. I'm arguing that the boundary between "design work" and "architecture work" is far blurrier than the org chart suggests, and pretending it's a clean line — a wall with a handoff over it — is how you get designs that fight the code and code that fights the design.

How I'd Approach It

Strip it to decisions:

• Read a design for structure, not just appearance. What repeats, what nests, what varies — that's your component tree, handed to you.
• A static mockup is one state. Before coding, hunt for the ones it hides: empty, loading, error, overflow, huge data. Build all the realities, not the one you were shown.
• Interrogate before you implement. The cheapest place to discover a missing state is a design review, not QA.
• Treat it as a conversation, not a handoff. Engaging during prototyping surfaces reuse and missing states while they're still cheap to fix.
• Prototype from your existing components. A design aligned to the system you already have ships far faster than one drawn from scratch.

The reframe that changed how I work is small but load-bearing: the design tool is where architecture starts, not where it waits. The person arranging cards and spacing is making decisions about repetition, hierarchy, and composition — the exact decisions I'll be encoding in components an hour later. When I treat the mockup as a picture to copy, I throw all that structural information away and rebuild it, worse, in code. When I treat it as the first draft of the architecture, the design does half the hard thinking for me — and the half it left out becomes a conversation instead of a bug.

Next, the flip side of building components well: documenting them — so the reusable pieces you and your designers just agreed on actually get reused instead of quietly rebuilt for the fifth time.

If your team's design-to-code process feels like reproducing pictures and constantly rediscovering missing states in QA, that's the handoff model doing its usual damage. Tell me where it hurts — the reuse, the missing states, the drift — and I'll tell you where the conversation needs to move earlier.