Why I Stopped Wireframing & Started Designing at the Speed of Freight

I used to wireframe everything. Marker on whiteboard, pencil on paper, Figma frames full of grey boxes and placeholder copy—it was all part of the rhythm. Sketch first, think later. Build up fidelity as the idea became more solid.

But over time, the habit faded.

Not because I thought less about design. Not because I stopped caring about the structure or flow. But because the work I was doing—especially in logistics—started to demand something else entirely. Something sharper. Faster. More immediate.

The products I spend most of my time with tend to sit deep within the operational machinery of freight and logistics. Systems that deal with volatile data, changing regulations, hundreds of edge cases, and an audience that rarely has time for ambiguity. These are not your polished, marketing-led interfaces. They’re tools. Tools for people who need to get things done—quickly and accurately.

And that’s the thing. When the problems are urgent and the feedback loops are short, grey boxes don’t do much. People don’t respond to abstract layouts. They don’t engage with placeholder buttons or “Lorem ipsum” fields. They want to see something real. Something they recognise. And they want to react to it—instantly.

That shift in environment nudged me away from wireframes and into a different kind of workflow. I started building with the end in mind—not just visually, but structurally. I created a component system that mirrored the real products I was designing for. Dropdowns that behave exactly how they should. Tables that paginate, sort, and filter. Forms that validate. All styled, all functional, all built to resemble the actual system they’d be deployed into.

So now, instead of sketching boxes and annotating them with "this will be a filter", I just drag the filter in. And if someone in a call asks, "Can we add a multi-select here?", I do it on the spot. They see it update in real time. They test it. They poke at the logic. And suddenly, the conversation shifts from "what might this be?" to "this feels right, but what if we moved that to the top instead?"

That change has had a massive impact—not just on how I design, but on how others engage with the process. I remember one meeting clearly. We were reviewing a new web app concept. Rather than a slide deck or mockups, I shared my screen and started building with real components, live. As the client asked questions, I moved things around. We tested ideas together, on the fly. It was collaborative, fast, and clear. By the end of the session, we hadn’t just reviewed a concept—we’d co-designed the first working version.

There’s no ambiguity when you work like that. No endless back-and-forth about what something might eventually become. It is what it is. And because people are seeing something that feels like the final product, their feedback becomes sharper. More useful. More honest.

Wireframes, for all their value, don’t tend to spark that kind of dialogue. They ask people to imagine. To fill in the blanks. And most of the time—especially when you’re dealing with domain experts who aren’t designers—that just leads to confusion. Or worse, disengagement.

Working this way means I can move quickly without sacrificing clarity. I can build new screens in hours, not days, knowing that what I’m putting together is grounded in reality. It’s not hypothetical. It’s usable.

That doesn’t mean I’ve abandoned the early sketching phase. I still think on paper. Still map out flows and scribble ideas on whiteboards. But I don’t linger in the in-between. I move to high fidelity as soon as I can, because that’s where the real work starts. That’s where people start to understand—not just what we’re building, but how it will actually behave.

Building this kind of system took time. A lot of trial and error. I’d tweak a modal here, refine a button style there, and gradually, a library started to emerge. One that wasn’t just a collection of pretty elements, but a toolkit that reflected how the product really worked. And every project I touched fed back into it. New requirements led to new components. Edge cases became features. What started as a set of visual styles turned into a living system, shaped by real use.

And the payoff? It’s in the speed. The conversations. The confidence.

When you can put something in front of someone that feels like the real thing—within hours, not weeks—you build momentum. You make decisions faster. You sidestep the awkward translation layer between designer and engineer. And you spend less time interpreting feedback and more time acting on it.

I’ve found this especially valuable in logistics, where the stakes are high and the windows for change are small. People don’t want to sit through a design process that feels theoretical. They want to see what’s possible—and they want to shape it with you.

That’s why I shifted my approach. Not to skip steps. Not to cut corners. But to get closer to the work that matters. Closer to the real thing.

So no, I don’t wireframe much anymore. I build. I iterate. I respond. And I try to make the design process feel as immediate and useful as the tools we’re ultimately building. Because in the end, that’s what makes the difference. Not just how quickly you can prototype—but how quickly people can understand what you're building, and help you make it better.