Designs that move

Most people think designing solutions is about sitting down, thinking hard, and coming up with something clever. That’s not quite right. The real test of a solution isn’t how smart it sounds in a room. It’s whether it moves—whether it does something in the world.

“Designing solutions that move” sounds poetic, but it’s actually very literal.

A solution that doesn’t move is just an idea. And ideas, on their own, are cheap. You can generate dozens in an afternoon. The hard part is getting one to travel—to go from your head into reality, and then from reality into other people’s lives.

Movement is what filters good ideas from useful ones.

You start noticing this when you look at projects that actually work. They don’t begin as grand, perfect systems. They begin small, often awkward, but with one key property: they can go somewhere. They can be tested, stretched, broken, improved. They have momentum.

Momentum is underrated in design.

We tend to admire elegance—clean interfaces, polished branding, clever language. But elegance without motion is fragile. It’s like a beautifully designed vehicle with no engine. It might look complete, but it won’t take you anywhere.

The opposite is more interesting: something slightly rough, maybe even a bit ugly, but already in motion. You can push it. Others can interact with it. It creates feedback. And feedback is what shapes real solutions.

This is where many designers get stuck. They design for stillness.

They optimize for how something looks at launch, not how it behaves over time. They assume the goal is to get it right the first time. But solutions aren’t paintings. They’re more like conversations. They evolve as people respond to them.

So designing something that moves means designing for change.

It means asking different questions. Not “Is this perfect?” but “Does this work enough to begin?” Not “Do people understand it immediately?” but “Will they keep engaging with it long enough to understand it better?”

There’s also a deeper layer to this.

Movement isn’t just about iteration. It’s about impact. A solution that moves changes something. It shifts behavior, unlocks access, reduces friction, creates opportunity. You can trace a line from its existence to something being different in the world.

And that’s surprisingly rare.

A lot of things are built, launched, even celebrated, but they don’t actually change anything. They sit there. People might notice them, maybe even admire them, but their lives continue unchanged.

That’s a sign the solution didn’t move.

Designing for movement forces you to stay honest. You can’t hide behind aesthetics or theory. The question becomes uncomfortable but clear: what does this actually do?

If the answer is vague, that’s a problem.

If the answer is concrete—even if small—that’s a start.

Interestingly, movement often begins in very local ways. One user. One use case. One small win. That’s enough. In fact, it’s better than trying to design something that works for everyone from the start.

Because movement compounds.

Once something works in one place, you can extend it. Once it helps one person, you can understand how to help ten. Then a hundred. The solution grows not because it was designed to scale from day one, but because it was designed to move from day one.

There’s also a kind of humility in this approach.

You accept that you don’t fully know what the solution should be yet. You let reality participate in the design process. That can feel uncomfortable, especially if you’re used to being the one with answers. But it’s more truthful.

And in the long run, truth is a better design partner than certainty.

So if you’re building something—anything—it might be worth asking a simple question:

Does this move?

Not in theory. Not in a presentation. But in the real world, with real constraints and real people.

If it doesn’t, strip it down until it does.

Because a small thing that moves will always outperform a big thing that doesn’t.

 

Author: Lawrence Kosgei


Leave a Reply

Your email address will not be published. Required fields are marked *