Design Thinking Is a Mindset, Not a Meeting
So often we see design thinking presented as a nice neat diagram with arrows, sticky notes, and a clear beginning and end. But in the real world, it's often none of those things.
Design thinking isn't linear and it's not a one-time thing. It's a mindset that shows up in the decisions you make when things are unclear, constrained, or messy. Which is most of the time.
Where Do We Begin?
The focus has to be on one question: what problem are we solving?
Every project starts with a user complaint, a gap in the market, a personal pain point, or often just a desire for growth. These may be written up in a PRD, a Jira ticket, or sometimes just a loosely defined idea.
From these artifacts, we need to understand our constraints, set aside preconceived ideas, and orient ourselves around the customer experience while keeping business requirements in view.
Empathize
As a designer, empathy is the job. We have to understand our users, their pain points, and their goals. To truly understand these things, we have to go where our users are, where the work is actually happening. We need to listen and observe how they use our product. Ask open-ended questions: "How would you approach solving this problem?" "Why do you think that happened?"
After that, take time to reflect on what you learned. Are there unanswered gaps? Was there anyone you didn't talk to that you should have? Then iterate on what you found.
Define
This is the point where we have to resist the urge to start thinking about design solutions. When we jump into designs too early, we often get attached to them. They can direct our thinking and lead us to the wrong answer. This also plays into confirmation bias, where we think we have the right solution and seek out information that confirms it.
Start with your notes from the previous step and define who your users are. The advantage here is that you're not working with generic personas. You're building profiles from real people who use your product. You can describe who they are, where they use the product, and map out the scenarios where they run into problems.
From there, quantify it. How much time does a task take? How many users hit this issue? Whatever the relevant metric is for your specific problem, put a number to it.
Once that's done, review your problem definition with your users. Is this the right problem? It can feel like a redundant step, but confirming early that you're solving the right problem saves time and money.
A stakeholder might come to you with: "Users are dropping off because the dashboard is too complex. We need to simplify it." The obvious solution might seem like removing features, reducing density, and cleaning up the UI. But after researching, you might find the problem isn't complexity at all. It's a lack of clarity and guidance. Users actually needed all that data. They just couldn't use it effectively:
- They didn't know where to start
- They couldn't tell what was most important or what to act on
- Key actions were buried and disconnected from the data they cared about
- New users felt overwhelmed with no guidance on how to begin
Then reframe the problem in user-centered terms, grounded in what you actually found. Review it with users and iterate if needed.
Ideate
This is the fun part: divergent thinking. Get your team together, the more diverse the better, and start collecting ideas. Anything goes here. Don't judge ideas as they come out. Keep asking "what if?"
Once you've got a good pile, switch to convergent thinking. Start grouping similar ideas and narrowing down to the ones worth exploring further.
Prototype
Take the ideas worth exploring and start building low-fidelity prototypes. These could be rough sketches on paper, loose storyboards, or basic clickable wireframes.
As you and your team start to visualize these ideas, evolve the ones you like into high-fidelity interactive prototypes. Let your team click through and see how it holds up. Does it match how you'd expect it to work? Present it to some of your users and see how they respond.
Once you're happy with the direction, this is when you define your MVP. It should be enough to solve the core problem and satisfy early adopters. From there you can iterate and build as time allows.
Test
By now you may have noticed that we've been testing and iterating at the end of every step. That constant loop of going back to users is what keeps you solving the right problem.
In this final step, present your original findings and artifacts to the same group of users you started with, and if possible, bring in new users too.
Walk them through what you found, then present your solution. What did you do? Why? Keep it high level. You don't want to bore them with details that aren't relevant to their situation.
The most important part is letting users try it on their own. Sit back and watch. That's where the best feedback comes from. You don't want your voice influencing what they do or how they feel about it.
Then, just like we started, we come back to empathy. How are they responding? What's working, what isn't?
Design process is a constant circular flow: observing, asking questions, prototyping, iterating, testing, then starting again. The steps don't always happen in order, and that's fine. What matters is staying curious, staying close to your users, and being willing to revisit your assumptions when the evidence points somewhere new. We can't build good products without the people they're designed for involved throughout. Good design is a conversation with everyone, not just a couple of stakeholders.