> Blog post by Lokesh Saini
> Canonical (HTML): https://www.lokeshsaini.com/blog/prototyping-in-the-wrong-tool

I have Figma open. The task is to test whether a new interaction pattern works for a companion app that talks to a hardware device over Bluetooth. I close Figma and open VS Code instead.

Not because I can't prototype in Figma. I can. But the question is: "Does pairing feel trustworthy when you're holding the phone and the device is blinking at you from across the table?" Figma shows me the screens. It can't put the screens in my hand next to a real device.

## The tool matches the question, not the fidelity

In practice, I pick the tool based on a simpler question: what am I trying to learn?

"Does this layout work?" Figma. Drop the components, squint at the composition, check the hierarchy. Five minutes.

"Does this interaction feel right when you're holding the phone?" Build it. Run it on the device. Hand it to someone. No Figma prototype captures the feel of a thumb reaching for a button at the bottom of a 6.7-inch screen while you're distracted by what's happening on the hardware in your other hand.

"Are we even solving the right problem?" Draw it on paper. In the meeting. While the stakeholder watches. That rough sketch does more work than a polished deck ever will.

The phase you're in doesn't determine the tool. The question does.

## When code prototyping beats design tools

Some questions can only be answered with a working build on a real device.

I was designing a companion app for a hardware product that used BLE for pairing. The pairing sequence had three states: scanning, connecting, and connected. I prototyped the flow in Figma. Screens linked, transitions timed, loading states mocked. It looked right.

Then I built it and ran it on a phone sitting next to the actual device. The Bluetooth scan took anywhere from 2 to 11 seconds. Sometimes it failed silently. The "connecting" spinner that felt fine in Figma felt broken in real life because you were staring at a physical device whose LED wasn't responding yet.

I redesigned the entire pairing flow based on what I learned from that 30-minute code prototype. The Figma version told me the layout worked. The code version told me the experience didn't.

This pattern repeats with anything involving hardware interactions, real network latency, haptic feedback, actual scroll physics, or touch targets tested with actual thumbs. If the question involves the physical experience of using the thing, you need the thing.

## When paper beats everything

I once walked into a stakeholder meeting with a printed Figma mockup of a dashboard. Full color, real data, pixel-perfect. The stakeholder said, "Looks great, approved." Meeting over in four minutes.

Three weeks later, after engineering started building, the stakeholder came back: "Actually, this isn't what I meant at all."

Contrast that with a different project where I brought a rough sketch on paper. Drew it during the meeting, in fact, while the stakeholder was explaining what they needed. The roughness changed the conversation. Instead of "approve or reject," the stakeholder started pointing at the sketch saying, "No, this part should be here, and this data is more important than that data."

The fidelity of the artifact controls the feedback you get back. A polished mockup says: this is decided, your job is to approve. A rough sketch says: this is open, your input shapes it.

## The cost of the "right" tool

Every prototyping tool has a cost, and it's not just time.

A high-fidelity Figma prototype takes hours. By the time you've built it, you're emotionally invested. A hundred small decisions about layout, color, copy, spacing. When someone suggests a different direction, part of your brain resists because you've already "built it." The sunk cost is real even when the pixels are free.

Paper takes 30 seconds. It costs almost nothing, which means throwing it away costs nothing. You get honest feedback because nobody feels bad about marking up a napkin sketch.

The question is not "which tool is best?" It's "what is the cheapest way to answer the question I actually have?" If I'm checking visual hierarchy: Figma. Physical ergonomics: code on a device. Whether the stakeholder and I are even talking about the same thing: paper.

## The deliverable is a decision

Process orthodoxy says wireframe, then mockup, then prototype, then test. That progression makes sense as a default. It's a map, not the territory.

Real practice is messier. I've gone from a paper sketch straight to code because the interaction question was more urgent than the layout question. I've gone from a coded prototype back to paper because the code revealed we were solving the wrong problem. The tool should serve the question, not the calendar.

The deliverable is not a Figma file or a code branch. It's a decision, made with confidence, at the lowest possible cost.