The designers who win don’t pretend to know

Most of what we’re taught about design assumes a world that doesn’t exist.

The methods are clean. You research the users, map the problem, frame the opportunity, ideate, prototype, validate. The diagrams have arrows. The arrows make it look like the information flows in the right direction at the right time.

In the real world, you’re handed a vague brief. You go looking for the information you need. You find some of it. The documentation you do find is partial, contradictory, or out of date. Some of the people who should know the answers don’t. The company doesn’t fully know what it wants, the users haven’t been studied with any rigor, and the research team you’d want to consult either doesn’t exist or is bottlenecked on something else.

And yet you have to design something anyway.

This is the actual condition of design work in most companies. Not a failure mode — the default mode. Nothing in the canonical design education prepares you for it, because the canon assumes a problem space you can fully map before you commit. You almost never can.

So the real skill — the one that doesn’t show up in any framework — is learning to design well without the inputs you were taught to require. Designers who only ship pixels are going to lose, and at the pace AI is now setting, they’re going to lose faster. The ones who think strategically — who treat the work as solving a problem, not decorating a solution — are the ones who survive.

But strategic thinking has a problem: nobody can see it. It lives in your head. Your Figma file shows the output. Your vibecoded prototype shows the output. Neither shows the reasoning — the trade-offs you weighed, the assumptions you’re standing on, the constraints you accepted, the alternatives you considered and ruled out, the thread that connects one decision to the next.

That’s what a strategy deck — or a design memo, call it what you want — is for. It makes the strategy visible. It’s not a deliverable someone is waiting on. It’s a tool you reach for to align your own thinking, surface the gaps, document the rationale while the reasoning is still fresh, and be honest, on the page, about what you can propose with the inputs you have.

It’s how you show your work to yourself before you show it to anyone else. And when you do show it, other people can follow the same thread.

‍Two kinds of designers

There are two kinds of designers when it comes to this.

The first says “here is the answer”. Confident, clean, certain. It reads well. Easy to nod along to.

The second says “here is the best answer I can give, here are the dependencies it rests on, and here’s what I’d do if those dependencies break”. It sounds less confident. The reader has to hold more in their head.

Most of us default to the first. It’s what we’ve seen senior people do. It’s what gets approved. Naming what you don’t know feels like the thing junior designers do before they learn better.

It’s backwards.

Strategic thinking includes thinking about the gaps

Here’s why. Design proposals built under uncertainty are often partly wrong. Not because the designer was sloppy — because the inputs were incomplete. The users you couldn’t talk to behave in ways you didn’t predict. The technical constraint you didn’t know about reshapes the solution. The business priority shifts. The mental model you built of how a workflow operates turns out to be slightly off.

Design with the first posture and reality intrudes: you look like you oversold. You claimed more than the evidence supported. People feel it, even if they don’t say it.

Design with the second posture and reality intrudes: you look like someone who thought carefully. You named the pre-conditions. You documented the fallback. You spotted the failure modes before they happened. You moved the work forward because it needed to move forward — but you were honest, the whole way, about what you were standing on.

The intuition is that naming uncertainty makes you look weaker. It doesn’t. It shows you’ve reasoned through the scenarios. You didn’t have all the information. You moved forward anyway — trying to light the way, not pretending the room was already lit.

That’s not a weakness to manage. It’s the strategy.

The deck thinks. You talk.

A strategy deck can carry the rationale, but it can’t carry the room. The document does part of the work. The conversation does the rest. A designer who can write a sharp deck but can’t talk through it is only half-equipped — and a designer who can talk but never writes anything down is the other half of the same problem.

Communication isn’t a soft skill. It’s a vital one. The deck thinks; you talk. Both have to be good.

In conversation, the framing matters. When you walk stakeholders through a deck full of named dependencies and open questions, they need to hear — from you — that this is rigor, not hesitation. Something like “this is the proposal I stand behind. These are the dependencies I’m watching, the ones that could require us to adapt”. That kind of framing makes the document’s honesty land as confidence, not as doubt.

The deck does its job. You do yours. Together they make the strategy legible.

The honest state

None of this works, though, unless you accept something first: in any sufficiently complex domain — and most design problems are — not having all the answers is the honest state.

When the documentation is incomplete and the people closest to the problem still have open questions, a proposal that claimed total certainty would be the suspicious one. It would mean you didn’t read carefully enough to notice the gaps, or you noticed and chose to paper over them. Neither is good.

The small discomfort you feel when you publish your assumptions — when you commit them to the page — is probably a sign you’re doing it right. Confidence without that discomfort is usually unearned.

Don’t apologize for being honest

One thing to be careful about: don’t apologize for the honesty when the deck meets an audience.

The work is honest. Let it be honest. When someone asks “are you sure this will work?”, the answer isn’t a flinch:

“The strategy is sound given current inputs. Here are the pre-conditions it depends on. Here’s what we do if those don’t hold”.

That’s not hedging. That’s the actual answer.

The work shows up on the page as named dependencies, documented fallbacks, credited open questions. In the room, it shows up as someone who is calm about the limits of their own knowledge — because they’ve already reasoned through them.

The frameworks alone won’t save you

Design thinking won’t save you. The double diamond won’t save you. Not because those tools are wrong, but because they assume a world where you can complete each phase before moving to the next. You can’t. The inputs you need to validate phase one will arrive while you’re in phase three, and some of them will never arrive at all.

AI accelerates this. The pressure to skip the thinking has never been higher, and the designers who get left behind won’t be the slow ones — they’ll be the ones who shipped a lot and never wrote down why. Speed without documented reasoning is velocity in a direction nobody can audit later, including you.

What actually carries the work is a different skill: the ability to make your best strategic judgment, name what it’s resting on, and stay honest about the gap between what you know and what you’re proposing.

You’re not designing blind. You’re designing with your eyes open, including about the limits of your own knowledge. That’s the harder thing to do, and the better thing to do.

The design work people remember as good wasn’t the work that sounded most sure. It was the work that turned out to be right about what it didn’t know.

Confidence is cheap. Calibration is rare. The designers who win are the ones who know the difference.

‍This article was originally featured on Medium.

‍

About the writer

Solange Bauer is a Senior Product Designer at Tech9 with a background in Industrial Design and experience designing products across public safety, healthcare, edtech, and real estate. She is passionate about product strategy, UX design, and sharing lessons learned from real-world product challenges.

‍