Early in my career, I thought I knew what made someone a great designer.

Strong visual instincts, tool fluency, a portfolio with clean grids and elegant typography. To cap it off, the ability to move quickly from a fuzzy brief to a polished mockup (print, brand, digital, UI, you name it).

I was good at those things, and for a while, I thought that was the job.

It took years and a lot of exposure to different kinds of work, different kinds of teams, and different kinds of problems to understand that what I'd been describing was actually the craft. Yes, craft while essential, is not the same thing as thinking.

The difference between a designer and a design thinker isn't skill level. It's the question they start with.

The Designer's Starting Question

A designer, in the traditional sense, starts with: What should this look like? Or sometimes: How should this work? These are good questions. They're the right questions in plenty of contexts. When you have a defined problem and a clear brief, craft is what delivers.

But here's the thing about most real-world problems: the brief is rarely right or complete.

The feature your stakeholder wants may not solve the problem your user has. The flow that makes sense in a product requirements document often falls apart when a real person tries to use it. The design challenge as presented is frequently a symptom of a deeper issue nobody has quite articulated yet.

If you only ask what should this look like, you'll miss all of that. You'll deliver exactly what was asked for and it won't work or have the expected impact.

The Design Thinker's Starting Question

A design thinker starts with: What problem are we actually trying to solve, and why?

This sounds simple ... it isn't. Because asking it seriously means being willing to push back on the brief, reframe the constraint, and challenge assumptions that have been baked into a project for months. It means slowing down before speeding up. It means spending time in ambiguity when everyone around you is demanding clarity.

Design thinkers are fluent in their craft ... they need to be, because eventually you have to make the thing real. But they hold the craft in service of something much larger. They know that the best interface for a broken process is still a broken process.

What distinguishes them isn't that they draw better or prototype faster. It's that they ask different questions, and they ask them earlier and continue to ask them.

Where This Shows Up in Practice

I've seen this distinction play out in every environment I've worked in ... consulting, product, and even in the classroom.

In consulting, the designer takes the client's brief at face value and produces deliverables that meet the stated requirements. The design thinker spends the first few weeks asking "why" until they understand what the organization is actually trying to accomplish ... and sometimes realizes the original ask was pointed at the wrong problem entirely, I have a great story here for another time 😉.

In product, the designer builds the feature on the roadmap, polished and on time. The design thinker questions whether the feature should be on the roadmap at all, brings data to that conversation, and sometimes saves the team months of work on something users never needed.

In the classroom, the design student executes the assignment. The design thinking student interrogates the assignment ... they want to understand every aspect of it and leave no store unturned.

I've taught at the university level, and this is the shift I watch happen in students. It's not always comfortable. Students who are used to getting feedback on execution start getting feedback on framing. That's disorienting at first. But the ones who make that shift, who learn to hold the question open a little longer before reaching for the solution ... those are the ones who become genuinely dangerous in the best possible way.

Can You Teach It?

Absolutely, or at least I think so. But it's less about learning a framework and more about developing a habit of mind.

The habit is this: before you make anything, earn the right to make it by understanding what you're making it for.

That means talking to users before opening Figma. It means asking your PM or your client "why do we think this is the right problem to solve?" before agreeing to solve it. It means treating the first version of any brief as a hypothesis rather than a contract.

It also means getting comfortable being the person in the room who slows things down ... while still being someone who can ultimately speed them up, because you helped the team avoid building the wrong thing in the first place.

What I'd Tell Myself Early On (If I had It Over Again)

Your portfolio doesn't get you the interesting problems. Your thinking does.

The designers who get handed the hard, messy, high-stakes work aren't always the ones with the most technical skill. They're the ones who've demonstrated that they can hold complexity without collapsing it too early. That they can navigate ambiguity without getting paralyzed. That they understand what the work is actually for.

Your craft gets you in the door. Thinking is what keeps you in the room.

Until the next volume, thanks for joining me. 
- Andrew Preble