The teams that win in the market spend the bulk of their time and budget creating prototypes and executing, when the important decisions are actually made. Design thinking gave teams a common language (e.g. empathy map, customer journey map, stickies brainstorm) but the winning teams use those as warm-up and get down to business after that.
Design thinking was never meant to be the finish line
None of this means design thinking should get thrown out; it means it needs a hard deadline and mandatory exit condition: every workshop needs to end with a commitment to a prototype, not a deck summarizing what was discussed.
Design thinking is great for framing a problem: getting everyone in the room on the same page as to who the user is and what they’re struggling with. However, teams often mistake the outputs of a design thinking workshop – a wall (or multiple walls) of post-it notes organized into nice neat affinity maps – and feelings of alignment for progress. A nice affinity map and everyone feeling good doesn’t ever tell you if a checkout flow will convert, if a development team can build this feature in the promised amount of time or even if your user will click that button.
Eventually though you have to build something and show it to real people to get real answers. So make sure you leave a design thinking session with a prototype that can be updated, iterated upon and tested.
Prototyping is where the real decisions happen
The point of a prototype is to answer questions. Will this feature cost too much to implement? Will users like the interaction? Will customers use it or quit after three steps?
High-fidelity prototypes can answer these questions, but low-fidelity prototypes (paper sketches, wireframes, click-throughs) can answer them too, and they’re faster and cheaper to make. Teams that invest lots of time and resources making polished prototypes before they test them are often polishing an assumption. A quick prototype, made in an afternoon, can give a team 80% of the insight of a polished, production-ready prototype.
The takeaway: make your prototype as ugly as it can be, as fast as you can, and test it with real users. If you can get fifteen people to try out your low-fidelity prototype in a week, that is better than a beautiful prototype that sits in a review deck for a month.
The fidelity of a prototype is driven by the question you’re trying to answer. Should this navigation hierarchy exist? A clickable wireframe prototype is sufficient. Does this little animation sequence bring enough delight that users will continue? To answer that question, you need something very close to production quality. Mature design teams make prototypes that directly answer the questions they need to answer, rather than relying on their design system to make certain prototypes easier than others.
Speed of iteration is a business metric, not a design preference
Companies in the top quartile of the McKinsey Design Index posted nearly double the revenue growth of their industry peers (McKinsey, 2018). According to McKinsey’s 2018 The Business Value of Design report, prototyping speed and iteration cadence are two of the strongest levers behind this gap.
Time-to-market is a real concern and not just a buzzword used by executives who don’t understand the importance of craft. If a team takes six weeks to develop a prototype that can be tested with users, that gives competitors six weeks to gain the same insight and ship before the team even gets market feedback. Every week that a prototype is left incomplete or untested is another week that a team goes without market feedback. The build-measure-learn loop of the lean startup isn’t just a buzzword; it’s discipline. Fast iteration helps teams kill bad ideas while they’re cheap to do so and let good ideas compound faster than competitors can copy them.
Where good ideas go to die: the handoff
Ask any engineering lead what kills product timelines and the answer is rarely “bad concept.” It’s usually handoff. A designer hands off a flat comp or a flow diagram, engineering builds something close but not quite right, and three (or more) rounds of back-and-forth burn time that should’ve gone into actual iteration. The idea was fine. The execution path around it wasn’t.
A prototype of the final interaction – not just the visual layer, but the actual behavior, states, and transitions – closes most of that gap before a single line of production code gets written. It gives engineers something concrete to estimate against instead of a static mockup open to interpretation. It also gives business stakeholders something they can react to honestly, instead of nodding along to a slide deck because they don’t know what else to say.
Accelerating product design without bleeding development capacity is a superpower that’s hard to master. Building that muscle in-house takes time most product teams don’t have, and the learning curve shows up as missed deadlines and frustrated engineers long before it shows up as a better product. Mid-market software companies can get the superpower right now by partnering with product design experts and getting time back onto the road-map.
Prototyping isn’t a one-time demo
One of the biggest mistakes I’ve seen product teams do is use prototyping as a one-off activity. “We’ll just build a prototype, show it to leadership and then move on to building the real thing.” Using prototyping in this way is design theater, and produces shallow validation, much like a well-attended sticky-note workshop (but with more glitz and glam).
B2B product teams should instead see prototyping as a regular part of the development cycle. Ship an early version of the product to a small group of real users, find friction points in their usage, iterate, and ship again. A prototype is not an activity, it is a product, that lives until launch (and often after launch too).
Prototyping is also the best form of empathy a product team can practice. Much better than any amount of design thinking. In design thinking, empathy usually comes in the form of workshops, surveys, and interviews. A prototype put in the hands of a user tells a team more in ten minutes than all the interviews and surveys could in a week. We may spend a lot of time listening to customers say one thing, but they constantly do another. A prototype cares not for what the user says, but for what the user does.
Measure outcomes, not approval
Award-winning designs that confuse users at checkout 40% of the time are misses, regardless of the trophy on the shelf.
Uninspiring, clunky prototypes that increase completion rates in the double digits are winners, regardless of how few people want to screenshot it for a case study.
Design teams that are heavy on design-thinking track stakeholder signoff, workshop attendance, and whether the final screens are pretty enough for the portfolio review. Those are vanity metrics. Switch to tracking conversion rates, task completion, revenue lift. Those are the metrics that know whether the product works. Designing for metrics changes what wins in the design review; designing for signoff changes everything.
Here’s a practical tip: In your design reviews, have stakeholders experience the prototype before the rationale. Explanations before experiences invite arguments about intent. Experiences before explanations invite comments about what actually happens.
Bring engineering and the business into the room early
Prototyping with only designers leads to great-looking prototypes that fall apart when presented to engineers for estimates. Bringing all relevant parties together for prototyping – engineers, product managers, sales or support – helps expose any sunk cost or feasibility issues early.
A product manager who’s seen the prototype tested and the points of friction, is less likely to argue over decisions later. An engineer who has signed-off on a prototype, and called out any issues, is less resentful when the spec is broken out into tickets during sprint planning. Prototyping as part of a cross-functional design review, with a build-feasibility checklist, rather than a personal-taste checklist, makes these reviews worth your while.
Design systems make execution velocity sustainable
When speed is prized over consistency, a product can feel like a hodgepodge of opinions from five different teams. That’s why design systems matter. A mature design system that’s well cared for prevents a prototyping team from having to design all its buttons, forms, and other navigation elements from scratch in each sprint. When a prototype is ready for production, the system’s components also align with those engineering can quickly develop and other product teams already use.
Pairing rapid prototyping with a disciplined design system can reduce how long it takes to go through a design cycle by weeks at a time, without compromising on the visual or interactive consistency that customers expect from a product, and that’s a sign of a mature organization, more so than the fineness of any particular workshop result.
What this means for teams starting their next project
Finding product-market fit almost always involves creating and iterating on a prototype. This means that teams hoping to achieve product-market fit should spend less time showing how impressive their design process slides are, and more time shipping prototypes, converting users, and ensuring those users actually love the experience.
Design thinking still has its place: specifically at the start of a new project when teams need to get on the same page about what problem they’re trying to solve. However, teams shouldn’t surprise participants with a lack of clear direction once a design thinking workshop has wrapped, and allow any energy or buy-in generated during the workshop to drift away before defining the prototype and next steps.
