Claudio Lassala's Blog

I was in my mid 40s when I realized something that should have been obvious: not everyone thinks the way I do. I’m not talking about the types of thoughts.

I think in pictures. Always have. When someone describes a scenario, I see a movie playing in my mind. When I’m designing software, I visualize the screens, the flows, the interactions, but most importantly, I visualize the people in their environment using the software.

I assumed everyone thought in pictures. Turns out, I was wrong.

“Our Vision”

I was in a meeting where someone said, “I have a great idea for a new product. Let me share my vision.”

They put up a slide with 565 words.

I looked at it and thought, “That’s not a vision. That’s a wall of words.”

So I asked, “Do you have an image in your mind that goes with this?”

They paused. “No, I can’t actually picture it.”

That’s when it clicked. They weren’t being lazy or unclear. They genuinely think differently from me.

Some People Think in Words, Not Images

I’ve since learned that people process information in different ways. Some think visually. Some think verbally.

None of these is better or worse. They’re just different.

But when we’re building software, designing products, or facilitating conversations, we often assume everyone processes information the same way we do.

That assumption creates problems.

The Prototype Solves the Translation Problem

Someone in one of my sessions said, “A lot of people can’t visualize it, so the more you can put a prototype in front of them, the sooner they get it.”

Exactly.

If someone gives me a vision statement full of words and they can’t picture it themselves, I don’t push back. I ask the people who can think in images to sketch it. To create a prototype. To build something concrete.

Then we put those prototypes in front of the person with the vision statement and say, “Is this what you meant? Or this? Or this?”

Now we’re working with something tangible. The vision gets refined. The interpretation becomes shared.

Cover the Spectrum

I used to think my job was to translate my visual thinking into words so others could understand.

But that’s only half of it.

The other half is recognizing that some people need the words first. Some need the pictures. Some need to interact with a working prototype before it makes sense.

So now I try to cover the spectrum:

• Write the vision statement for people who think in words

• Sketch the interface for people who think in images

• Build a clickable prototype for people who need to experience it

It’s not either-or. It’s all of the above.

A Real Example: The Warehouse Visit

A few years ago, I visited a client’s warehouse. They dealt with produce distribution.

I spent the day watching people work. I took pictures. I observed their processes.

One thing I noticed: the accounts payable person had a stack of handwritten forms on their desk. Forms filled out by buyers. The AP person couldn’t read half of them because of the handwriting.

I took a photo of that stack. Later, when we were designing a solution, I showed that photo to the team.

For some people, that image said everything. They immediately understood the problem and started sketching solutions.

For others, I had to describe it verbally: “Buyers fill out vendor forms by hand. AP can’t read them. This causes delays and errors.”

Same problem. Different entry points.

Vision Statements Leave Room for Interpretation

Here’s the thing about vision statements: they’re useful, but they’re incomplete.

If someone writes a vision statement and can’t picture what it looks like, that’s not a failure. It’s an opportunity.

It means there’s room for creative people to come in and say, “Here’s one way this could work. Here’s another. Here’s a third.”

Then you refine. You iterate. You converge on something concrete.

But you have to recognize that the vision statement alone isn’t enough for everyone.

Design for Different Thinkers

I’ve started thinking about this in everything I do. When I’m preparing a presentation, I don’t just write slides with bullet points. I include images, diagrams, and stories.

When I’m facilitating a sprint review, I don’t just describe the features. I show screenshots, play videos, and walk through scenarios.

When I’m mentoring developers, I don’t assume they’ll “get it” from my explanation. I ask them to sketch it, build it, or show me what they’re thinking.

This is about meeting people where they are.

How do the people on your team think? And are you designing for all of them?