Design Thinking: Key to Exceptional User Experiences
- Apr 1
- 5 min read
Updated: Apr 23
Most of us have used a product and thought, "who on earth designed this?" A button you can't find, a checkout process that takes seventeen steps, an app that feels like it was built for a very specific type of robot and nobody else. It's maddening. And yet, teams pour months into building these things.
The culprit, more often than not, is designing for features instead of people.
This is where design thinking comes in. Not as some mystical creative discipline reserved for people who wear interesting glasses, but as a genuinely practical way to build things people actually like using. I'll be upfront: I've worked on projects where we skipped steps in this process because of time pressure, and we paid for it later. Every time.
So, What Actually Is Design Thinking?
It's a problem-solving approach that puts users front and centre. Not shareholders. Not your boss's pet feature requests. Users. Real, flawed, beautifully unpredictable human beings.
The process moves through five stages, and looping back is not just normal, it's the point. If you're not revisiting earlier stages as you learn, you're probably not learning much.
Empathise. Get to know your users. Talk to them. Watch them. Understand their frustrations, their habits, their secret workarounds. The workarounds especially. They're a goldmine.
Define. Take all that insight and pin down the actual problem. It's rarely the one you assumed it was. I've sat in kick-off meetings where the agreed problem statement was completely wrong, and the research made that embarrassingly clear within a week.
Ideate. Brainstorm without a filter. All ideas welcome, including the terrible ones, because sometimes the terrible ones unlock something brilliant. Don't edit yourself too early.
Prototype. Build something scrappy and testable. It doesn't have to be pretty. A paper sketch that exposes a broken flow is worth more than a polished Figma file nobody's actually tested.
Test. Put it in front of real users and prepare to be humbled. Then improve. Then test again. There's no "done" in design thinking. Just progressively less wrong.
Why It Makes Such a Difference to User Experience
User experience isn't just about whether something looks nice. It's about how people feel when they use it. Confident or confused, delighted or just quietly defeated because they couldn't find the thing they needed and gave up.
Empathy is where it starts. When you actually spend time with the people using your product, you stop guessing. I worked on a project where we assumed the navigation was fine because everyone in the team could use it without thinking. Of course they could. They built it. Get in front of real users and you very quickly find out what you missed. In that case, quite a lot.
Defining the right problem is unglamorous work and most teams rush it. That's a mistake. Spend months building the wrong thing and you'll wish you'd spent a week properly defining what you were actually trying to solve.
Ideation is where it gets fun. Genuinely commit to "no bad ideas" and the room changes. People stop self-editing. Unexpected combinations emerge. A transport app team once landed on a bike rental integration through a brainstorm that started somewhere completely different. That idea would never have survived a conventional meeting with a fixed agenda and someone's pet solution already on the table.
Prototype early and prototype rough. A sketch on paper that exposes a broken flow in an afternoon is worth infinitely more than six weeks of polished work that nobody tested. And then test. Put it in front of real users and expect to be surprised. That surprise is not a setback. It's the whole reason you're doing this.
Testing grounds everything in reality. No matter how confident you feel about a design decision, and sometimes the confidence is the problem, users will find a way to surprise you. That's not a bug. That's the whole point.
Real-World Stories Worth Knowing
Airbnb was struggling with inconsistency across listings. Guests didn't know what they'd get; hosts weren't sure how to present themselves. The team spent real time with actual hosts and guests, identified that trust was the core problem, and redesigned around that insight. Verified photos, clearer booking flows, better communication tools. The platform became more reliable and far more popular. Obvious in hindsight. Most good solutions are.
IDEO's shopping cart redesign is something of a design thinking legend. Rather than sprucing up an existing cart, the team went out and watched people actually shop. The safety hazards, the awkward manoeuvring, parents trying to keep children from dismantling the cereal aisle. The result was a cart with a proper child seat and much better handling. Nobody in a boardroom would have invented that. It took actually going to a supermarket.
How to Get Started (Without Overthinking It)
You don't need a design degree or a whiteboard buried in Post-it notes.
Talk to actual users. Not your colleagues, not friends who say "yeah, seems fine." Real users. Ask open questions. Actually listen, even when what they say is inconvenient, especially when it's inconvenient.
Write a problem statement around what the user needs, not what you want to build. These are often very different things.
Brainstorm without editing yourself. Build something rough. Test it, learn from it, and go again. That's it, really.
The Honest Challenges
Design thinking isn't a magic wand. Teams used to traditional ways of working will sometimes push back, hard. Stakeholders who want a feature list rather than an empathy interview can be difficult to bring along. The best thing I've found is showing early wins. Small, tangible proof that the process works goes much further than explaining it in theory.
Getting access to real users is also harder than it sounds, especially early on. Online surveys, social media communities, or proxy users can bridge that gap. Imperfectly, but usefully.
And yes, it takes time upfront. But it catches problems before they become expensive. Projects that skipped this phase always, without exception in my experience, end up spending more time fixing things later than they would have spent doing it properly.
One pitfall I'll flag because I've genuinely fallen into it: don't get so absorbed in ideation that you never ship anything. Brainstorming is enjoyable. Shipping is the point.
Nobody Does Their Best Work Alone
Design thinking thrives when you bring together people who think differently. Designers, developers, marketers, and actual users. The friction between different perspectives isn't a problem to manage. It's where the good ideas come from.
When a developer says "that's technically tricky," a marketer says "but users expect it," and a designer says "what if we approached it sideways," that's the conversation worth having. Homogeneous teams produce homogeneous thinking. It's that simple.
Workshops help. Get people in a room, or a video call since we do live in the future, give them a shared space to think in, and watch what happens when everyone feels like they own the problem. The medium matters less than the mindset.
How Do You Know It's Actually Working?
Track user satisfaction scores, task completion rates, how long people spend fumbling through a particular flow, retention, conversion. These are the things that show movement. But don't stop at the data. Qualitative feedback fills in what numbers alone can't explain. The comments, the interviews, the "oh this is so much easier" moments. Numbers tell you what is happening. People tell you why. You need both.
A Few Final Thoughts
Design thinking isn't for every project or every deadline. Some situations call for faster, scrappier decisions and that's fine. But as a way of approaching problems, with curiosity, a bit of humility, and a genuine commitment to understanding people before solving things for them, it's hard to beat.
Start small. Pick one upcoming project. Talk to a couple of users. Write a proper problem statement. Sketch something before you build anything. See what you learn, and whether it changes what you thought you knew going in.
It usually does.


