A designer on my team once asked me to review a landing page mockup. She'd spent two days perfecting the gradient on the hero section. It looked stunning…the kind of thing that design school students probably drool over. But when I asked her what problem the page was supposed to solve, she went quiet.

She could tell me the hex codes. She couldn't tell me why someone would convert.

This happens more than we want to admit. Somewhere between design school and the real world, "design thinking" got compressed into "make it look professional." We hire talented people, send them to workshops about personas and journey mapping, then watch them default to the same pattern: receive brief, open Figma, start pushing pixels.

The gap isn't talent. It's how we frame the work.

The Aesthetic Trap

When someone says they need "design thinking" applied to a problem, they usually mean one of two things: either they want a prettier version of what already exists, or they want a workshop with sticky notes that produces a journey map no one will reference again.

Neither is actually design thinking. Both are theater.

Real design thinking starts with a different question. Not "how should this look?" but "what job is this doing?" I learned this the tedious way: by watching projects that looked gorgeous fail in market, while scrappier work that solved the actual problem outperformed everything.

The distinction sounds obvious until you're in the room. A product team wants a new dashboard. The impulse is to start with layout, typography, color theory. But the question that matters is: what decision is this dashboard supposed to enable? If you can't answer that, visual polish just makes a useless thing more attractive.

Teaching the Shift

An effective way I've found to teach this is asking designers to write the problem statement before touching any tool. One sentence: "This [thing] helps [person] do [action] so they can [outcome]." If they can't complete it, they shouldn't start designing yet.

I was a little hesitant about doing it at first; designers gonna design… that’s kind of the whole reason they're there instead of a million other career paths. Making them write sentences before opening their tools felt like bureaucracy or some weird form of mentoring-by-torture. But after a few weeks, they stopped asking me for prescriptive design solutions and started asking the real, important grown-up questions.

Instead of "what colors do you want?" they asked "who makes this decision and what do they need to know?" Instead of "modern or traditional?" they asked "what happens if someone wants something that’s just wrong here?"

The work got cleaner, not necessarily because the aesthetics improved, but because they were solving for something specific. A designer who understands the problem will make better visual choices than one who's just trying to make something look current or good or nets a “that’s cool!”

What This Means for Hiring

When I'm interviewing creatives now, I don't always ask about their process or their tools. Sometimes, I ask them to walk me through a project where the obvious solution was wrong.

The answer to this often tells me everything I need to know. Some people talk about pushing back on stakeholders who wanted the logo bigger. That's fine, and it’s evidence they have opinions. But the ones I want can articulate the underlying problem the stakeholder was actually trying to solve, then explain the non-obvious path they took instead.

"We made it bigger" isn't strategic thinking. "We realized they wanted more prominence because adoption was low, so we changed the navigation model instead" is.

The leaders who can elevate teams are the ones who reframe requests. They hear "make it pop" and translate it into "increase conversion by making the value proposition more obvious.” They take aesthetic feedback and extract the business concern underneath it.

This matters more as you scale. Early on, you can art direct every decision. But if your team can't operate strategically without you, you've built a production studio, not a true design team.

The Business Case

Here's what changes when design operates as a business function instead of a service org: projects get faster, not slower. Revision cycles shrink because the team is solving for defined outcomes rather than subjective preferences. Stakeholders trust the work more because designers can connect decisions to business impact.

And the work is just better. Not because the pixels are more perfect, but because every choice ladders up to something that matters.

We've overcomplicated design thinking; started hiding behind overwrought frameworks and expensive workshops when the real shift is simpler: teach people to solve problems before they make things pretty. The aesthetic skill matters, and it always will, but it should be the last 10%, not the first 90%.

If your team's instinct is still to open Figma before they understand the problem, you haven't failed at design thinking. You've just never actually implemented it.