Show the Why, Don’t Tell the What

I’ve always been a visual thinker, and I would rather show the why than tell the what.

If I can show you something instead of explaining it, I will. Not because explanation is useless, but because it rarely sticks on its own. People don’t store information as cleanly as we like to think. They compress it. What stays with them is not the full explanation, it’s the impression it left.

That changes how I approach the work.

Show the Why Before the Comfort of the What

Most projects start with a list of deliverables because it feels like progress.

We need a website.
A brochure too.
And a campaign.

It sounds clear, it gives everyone something to point at, and it creates the illusion that the problem is already defined.

I’ve learned that this is where things quietly go off track.

Because the what assumes the why has already been figured out. Most of the time, it hasn’t. Simon Sinek made a similar case in his well known talk on how great leaders inspire action, arguing that people respond to purpose long before they respond to the details of what is being offered.

What People Actually Respond To

When something works, it is rarely because the deliverable was well executed in isolation. It works because it connects to something underneath it.

There is always a layer below the surface:

• what someone is trying to understand
• where they feel unsure
• the belief they need before they act
• and what actually matters to them

That layer is where decisions happen.

You can describe a product, a service, or a brand all day, but if it never connects to that underlying tension, it stays informational. It doesn’t move anything.

How I Learned to Look For It

This comes from how I learn.

When I’m trying to understand something, I don’t start by accepting it as it is. I take it apart. I strip it down to the essentials so I can see what is actually doing the work. Then I rebuild it with only what is necessary to make the idea hold together.

That process forces clarity.

It also makes it obvious when something is built on explanation instead of understanding.

Because once you remove the extra layers, you’re left with a simple question: does this still make sense?

If it doesn’t, the problem was never the execution. It was the foundation.

Showing Creates Understanding

When people ask how I did something, I could walk them through every step, every option, every decision.

That usually doesn’t help.

Instead, I show them a couple of ways it could exist. Not the final answer, just enough to make the idea visible.

Once someone can see it, they start to understand it. Once they understand it, they can start to make decisions.

That’s the shift.

Explanation asks someone to follow along.
Showing lets them arrive at the conclusion themselves.

What this looks like in practice

This way of thinking shows up in almost everything I do.

It goes well beyond branding or messaging. It applies just as much when I am designing marketing materials, writing copy, troubleshooting a broken process, learning a new system, or building something technical from scratch.

The surface problem changes. The approach does not.

I start by asking questions.

Not just to gather information, but to understand what is actually going on underneath the request. I try not to take anything at face value, because there is almost always another layer behind it. Something unclear, something assumed, or something nobody has fully thought through yet.

That is where most of the real work is hiding.

So I take the time to dig.

I break things down. I look at how they connect. I try to understand what is actually driving the problem before I decide how to solve it.

Once that part is clear, the path forward tends to simplify.

That is when I start building.

Sometimes that means designing something visual that makes the idea easier to understand. Other times it means restructuring information so it flows logically, or writing something more clearly. And sometimes it means building a tool or system that removes friction entirely.

Different outputs, same foundation.

Understand first. Then design the approach to match.

That applies whether I am working on something creative or something technical. The tools change, but the thinking does not.

If I skip that step and jump straight into execution, I might still produce something that looks right. But it is more likely to miss the point.

If I take the time to understand it fully, the work tends to land in a way that holds up.

The Shift

If you focus on the what, you end up describing things.

If you focus on the why, if you show the why instead of just describing the what, you give people something they can understand, react to, and remember.

That difference is subtle, but it shows up in the work.

One version fills space.

The other actually lands.