Go past the Post It’s on the wall!
Design thinking transformed the way organizations solve problems.
It gave us a framework for moving away from boardroom assumptions and toward the people actually experiencing the problem, the users. It encouraged designers, managers, and developers to ask questions before jumping to answers, to empathize before designing, to explore multiple possibilities before committing to one, and to test our assumptions rather than simply trusting them.
The principles behind Design Thinking matter — a lot. In fact, I’d argue they matter more than ever. But design thinking was never supposed to end with a wall full of Post-it notes.
And too often, that’s exactly where organizations get stuck.
First, what exactly is design thinking?
At its simplest, design thinking is a human-centered approach to solving complex problems. Its roots stretch back decades across engineering, industrial design, and cognitive science, but the approach we recognize today was largely shaped and popularized through the work of Stanford University and IDEO. In the 1990s and 2000s, IDEO helped bring these methods into mainstream business, while Stanford’s d.school, founded in 2005 by IDEO founder David Kelley and others, helped formalize and teach the approach across disciplines.
Together, their work helped transform design thinking from a designer’s toolkit into a widely adopted framework for innovation.
Rather than beginning with a predetermined solution, teams begin by trying to deeply understand the people they are designing for, define the right problem, explore possible solutions, prototype those ideas, and test them with real users.
The framework most people recognize today is often described through five stages:
Empathize → Represent → Ideate → Prototype → Test
Importantly, those stages were never intended to function as a rigid, linear checklist. Design is iterative. Testing can send you back to ideation. A prototype can reveal that you misunderstood the problem entirely. New research can challenge what you thought you knew.
And that’s the point.
The ideas behind design thinking also have a much longer history than the workshops and Post-it-covered walls we tend to associate with the term today.
At Stanford, for example, John Arnold began advancing a more creative, systems-oriented approach to engineering design in the late 1950s. Robert McKim subsequently emphasized human-centered design, visual thinking, needfinding, sketching, and rapid prototyping, practices that Stanford identifies as foundational to its design education today. The Hasso Plattner Institute of Design, better known as the Stanford d.school, was established in 2005 and helped bring these methods to a much broader interdisciplinary audience.
IDEO also played an enormous role in bringing human-centered design and design thinking into mainstream business and innovation practice.
Meanwhile, other models helped organizations understand the same fundamental pattern of problem solving. Because before design thinking became common practice, organizations were far more likely to start with an answer.
Design thinking changed who gets to define the problem.
For decades, product and business decisions were often driven from the top down. Sadly, many companies still experience this approach to product development and business decision-making.
An executive had an idea they deem brilliant. A single customer asked for a feature. A competitor launched something you decide is worth copying.
And someone started building.
Design thinking challenged that approach by asking a deceptively simple question: Do we actually understand the problem we’re trying to solve?
That shift was transformative because it centered and elevated user research. It encouraged cross-functional collaboration and began to break down silos. It made experimentation safer and evidence and data king. It gave organizations permission to explore multiple solutions instead of immediately committing resources to the first plausible idea. It pushed businesses to prototype before building.
Most importantly, it put actual human beings at the center of innovation.
Instead of asking: What can we build?
Organizations began asking: What do people actually need?
But somewhere along the way, many organizations became better at doing design thinking than at actually solving problems.
When the process becomes the product
I’ve participated in, and led, more design thinking sessions than I could possibly count. When they’re done well, they’re powerful.
But I’ve also seen what happens afterward. The Post-it notes stay on the wall and someone photographs them. Someone creates a Miro board, which eventually becomes a PowerPoint. The PowerPoint gets presented and everyone agrees there were some really interesting ideas.
And then…nothing happens.
Or worse, the team spends the next several months debating which idea deserves to move forward, without a data-driven prioritization matrix. The problem isn’t design thinking itself.
The problem is treating the completion of the design process as the completion of the innovation process.
Organizations can get trapped in research paralysis, decision fatigue, endless ideation, stakeholder alignment cycles, theoretical debates, and pressure to perfect an idea before anyone actually interacts with it.
At that point, human-centered design has ironically moved away from the humans. Because the best way to find out whether someone wants, understands, needs, or can use something isn’t another internal meeting about it.
It’s putting something in their hands.
The technology caught up.
This is where I think the conversation about design thinking needs to evolve.
Twenty years ago, moving from an idea to a functional digital prototype could be expensive and slow. Building something, even something relatively simple, could require designers, developers, infrastructure, significant budgets, and weeks or months of work.
That made extensive upfront deliberation understandable. But today, the economics of experimentation are fundamentally different.
Modern design and prototyping platforms can create interactive experiences in hours. Low-code and no-code tools can turn concepts into functioning workflows. Tools like Claude allow non-developers to produce something functional. Cloud infrastructure has dramatically reduced the effort required to deploy and scale experiments. Product analytics and research platforms make it easier to observe what users actually do rather than relying exclusively on what they say. New customer experience tools like Agilitas allow you to gather customer input from across all customers, assigning value and looking for patterns in the feedback.
The result is an enormous opportunity: We don’t have to spend nearly as long debating whether an idea will work when we can build enough of it to find out.
That’s the evolution I think innovation desperately needs. We should not abandon design thinking.
We need to connect design thinking directly to doing.
From design thinking to rapid problem solving
At Low Hanging Cloud, we deeply respect the human-centered foundation of design thinking. We don’t want to eliminate it. But we want to remove the gap that so often exists between understanding, designing, building, and learning.
That means preserving the most valuable parts of traditional design thinking (user research, empathy, problem definition, divergent thinking, collaboration, prototyping, and testing) while connecting them to a technical delivery system designed for speed.
The goal isn’t: Research → Workshop → Recommendation → Wait
It’s: Understand → Decide → Build → Test → Learn → Improve
And then do it again.
This also changes what we mean when we say prototype.
A prototype doesn’t need to be a beautifully polished version of the final product. In fact, it probably shouldn’t be. If your prototype is perfect, you should likely be a little embarrassed because it took you too long to get to the testing phase.
The prototype simply needs to be good enough to answer the most important question you have right now.
Build only enough to learn what you need to learn next.
That’s where tools like Figma, Claude, and other interactive prototyping environments remain incredibly useful. Depending on the problem, low-code and no-code platforms can take you further into functional testing. AI-assisted coding tools can help teams create working proofs of concept dramatically faster. Analytics, session-replay, experimentation, survey, and user-research tools can then turn those prototypes into sources of evidence.
But the specific tool matters less than the system connecting them.
Technology doesn’t replace the need for thoughtful research, just as AI can’t replace strong strategy or the critical thinking that comes with it. And rapid prototyping isn’t a replacement for design thinking; instead, these tools give us the opportunity to build on its human-centered foundation and move from understanding a problem to testing a potential solution faster than ever before.
They shorten the distance between a hypothesis and evidence.
And that distance matters.
Build sooner. Learn sooner.
There is another important distinction here: moving quickly does not mean rushing to production. In fact, it’s quite the opposite.
Rapid prototyping creates an opportunity to make mistakes while they’re still inexpensive. You should build the smallest thing that is capable of testing your biggest assumption.
What we need to do is put it in front of our users and customers to watch, learn, change, and test again!
We need to be strong enough to kill the ideas that aren’t working before investing significant money building them. And, we need to double down on the ones that demonstrate evidence of value. The goal isn’t to get to a perfect prototype faster.
The goal is to get to the truth faster.
That’s the piece of design thinking I think organizations sometimes lose. Prototyping and testing aren’t boxes at the end of the process.
They’re the beginning of a continuous learning loop.
The next evolution of design thinking is less thinking about solutions — and more learning from them.
Design thinking changed innovation because it taught organizations to stop assuming they understood their users.
The next evolution requires us to apply that same humility to our solutions.
Here’s a list of don’ts I think you should print out and keep in front of you as a reminder:
- Don’t assume the idea that won the workshop is right.
- Don’t assume the prototype needs to be perfect before someone outside of the experts in the organization sees it.
- Don’t assume the loudest stakeholder knows what users will do.
- Don’t spend six months debating something you could learn by Tuesday (!!)
And, here’s the do’s:
- Do understand the problem.
- Do build enough of the solution to test your largest assumption.
- Do put a functional prototype in front of real users.
- Do measure what happens.
- Do learn from patterns in the input.
- Do make the changes that will matter to users most.
- Do repeat the process. Never stop learning!
At Low Hanging Cloud, we call this Problem Solving as a Service: combining human-centered innovation strategy with the technical ability to rapidly turn ideas into something tangible, testable, and ultimately scalable.
Because design thinking gave businesses an incredibly powerful way to find the right problems.
Now we need to get much faster at finding out whether we’ve actually solved them.
You don’t need another month of meetings. You need 24 hours to find the right path forward.