Design Thinking Basics

Design thinking pain points

There are several pain points when it comes to design thinking. Let's go through them!

No-progress workshops

No-progress workshops happen when you do design thinking activities, but nothing actually gets decided, and nobody owns the next steps. So the question is, how do you spot it? Here are some red flags that can help you spot a no-progress workshop.

• Clarity problems: The problem statement keeps changing, activities feel like random games, and there are no clear success criteria.

• No prioritization: There are 50 ideas; all are interesting, but none are selected or discarded.

• Output ≈ input: You leave the workshop with the same assumptions and options you walked in with, just better documented.

These are just some of the red flags that you might spot during no-progress workshops. They usually don’t happen because people are lazy or don’t care. No-progress workshops happen because of how the workshop is set up in the first place. You can think of them as a symptom, not the root problem.

You might be wondering how to fix them. There are a few things you can do to ensure they don't become a no-progress workshop. You can:

• Define a concrete goal: Replace vague goals with specific outcomes.

• Check if the "right" people attended.

• Use checkpoints halfway through. You can ask simple, quick questions, such as "What have we actually decided so far?"

If, on the other hand, you are already a few hours in and you can see that it’s going nowhere, try suggesting a pause to summarize what you've come up with. And remember, you don’t have to be the facilitator to help.

If you want concrete tips on structuring better sessions, read our guide on how to run a UX workshop.

Solution bias

Solution bias is when you jump to a favorite feature before understanding the real problem. You can spot it in the way problems are framed, in team behavior and conversations, and even in deliverables. Solution bias can also happen when you're feeling under pressure. So, how do you fix it?

It's important you reframe how problems are defined, separate problem-space and solution-space, and explore more than one solution on purpose. Solution bias thrives when there’s only one idea on the table. To get more ideas you can run a crazy 8s or rapid ideation exercise. Doing that won’t slow you down much, but it will massively increase the chance you pick something worthwhile.

So, next time you’re in a project review, ask yourself:

• Can we state the problem clearly without naming the solution?

• Do we have evidence that this is a real problem (user quotes, data, observations)?

• Have we considered at least 2–3 different solutions?

• Have we listed our riskiest assumptions and decided how to test them?

• Are our success metrics about user/business outcomes, not just feature usage?

If you’re saying “no” to several of these, you’ve probably got solution bias.

Faux empathy

Faux empathy in design thinking is when personas and insights are made from opinions and assumptions instead of real user input. It may appear as rushing into solutions without a deep understanding, using tools like personas in a thoughtless way, or mistaking empathy for a guaranteed path to good design.

So, why does it happen? It mostly happens because of constraints and human psychology, not bad intentions. And to fix it you don’t need a giant UX research function. You need small, consistent changes that tie empathy to evidence.

To fix faux empathy, try:

• Marking what’s real versus what’s assumed

• Making user contact small and frequent

• Building personas from evidence, not imagination

• Including “proof of empathy” in your templates

Over-polished prototypes

Over-polished prototypes are another pain point that can occur in the design thinking process. It happens when you spend the time perfecting visuals or solutions instead of learning fast.

You can spot them in the work itself; for example, when prototypes look like finished products, there are tons of screens and edge cases, or when people resist altering flows.

Why do over-polished prototypes happen? Sometimes it’s about feeling proud, and “ugly but smart” work feels risky to show. Other times it can be because of a misunderstanding of what prototypes are for. There's also the fear of looking sloppy or unprofessional in front of users or leadership.

So, how do you fix this pain point?

• Start with learning goals, not aesthetics: fidelity should be just high enough so that users can respond to the idea.

• Create prototype constraints on purpose: they should force focus on structure, flow, and concept.

• Align expectations with stakeholders and devs: it reduces the pressure to make it perfect and reminds everyone of the goals.

Testing opinions, not behaviors

Have you ever found yourself asking questions instead of watching people try tasks? Don't worry, it happens way more than you would think. Testing opinions instead of behaviors is the next design thinking pain point on our list. It happens when you're relying on what people say they’ll do (“Would you use this?”) instead of watching what they actually do when you give them a real task.

So, why does it happen? First, because it’s quite easy to ask questions, and oftentimes stakeholders prefer big, simple numbers, such as "80% of people said yes". But, by doing that we sometimes forget about human psychology, and how more often than not, testers might want to be polite, helpful, and not look foolish, or they say “Yes, I’d use this” because it costs them nothing.

To fix this, you have to shift your mindset. Use opinions to explain behavior, not to replace it. Behavior should be your source of truth.

You can try these:

• Start with behavior‑based learning goals: If the question is about doing, your research should involve watching doing.

• Design tasks, not talk tracks: You can still ask follow‑ups, but after you’ve seen the behavior.

• Change how you ask questions: This reduces fantasy answers and anchors people in real life.

Wrong participants

Testing with convenient people who aren’t your target users is the next pain point we're going to cover. This means testing with whoever’s easy to get (colleagues, friends, random users) instead of the people who actually have the problem you’re designing for. You’re doing research — but with people whose feedback can quietly steer you in the wrong direction.

You can spot it in how you recruit. If you ask “What makes someone a good fit for this study?” and the answer is “eh, basically anyone,” you’re in convenience sampling land.

Another issue shows up in who actually attends the sessions. If you have to do a lot of explaining so the person can “play the role” of your user, they're probably not your user.

Testing with the wrong participants happens because of many factors. Recruitment can be hard, there is time and delivery pressure, or sometimes even social and political constraints.

To fix it, remember that it's better to have a few right participants than a lot of convenient ones. Wrong participants can give you confidently wrong directions.

• Define who the “right” participants are: Who they are, what they do, any context or tools needed.

• Use colleagues as pilots, not as true participants: Think of internal tests as pre‑flight checks, not the actual flight. Just remember to treat it honestly.

Stalling on iteration

Stalling on iteration means you talk to users, collect insights, maybe make a beautiful research deck… and the product basically stays the same.

There are some signs that could help you spot it. Sometimes it's that design v1 and v2 look almost identical, and sometimes it's the same issues that keep showing up across rounds.

There are also a few reasons stalling on iteration happens.

Sometimes it’s the process itself. Research happened too late, roadmaps are locked to features and dates without iteration step between. Other times it’s sunk cost, unclear ownership, or fear of rework.

To fix this pain point, try:

• Planning for iteration on purpose

• Turning insights into decisions and actions

• Keeping fidelity low until you’ve iterated

• Aligning expectations

• Be honest when you can’t change things, because sometimes you truly have no room to iterate