How to Actually Solve UX Challenges (Not Just Document Them)
- Leor Wolins
- 11 minutes ago
- 14 min read
Two Teams, One Problem
Two design teams at two roughly equal-sized companies face the same problem: their signup conversion has been falling for six months and nobody knows why.
Team A spends ten weeks running user research, building personas, mapping journey maps, hosting workshops, and producing a 47-slide insights deck. The deck is genuinely impressive. Three executives praise it. Then it sits in a Google Drive folder, untouched, for the next year. Conversion keeps falling.
Team B spends three days reading existing analytics, talking to six real users on the phone, and watching ten session recordings. By the end of week one they have a hypothesis. By the end of week three they have shipped two A/B tests. By the end of week six conversion is up 14%. They wrote zero slides.
Same problem.
Same company size.
Different outcomes by orders of magnitude.
The difference is not talent, budget, or seniority.
The difference is how the two teams think about UX problem-solving.
Most UX problem-solving in our industry is theater.
Beautiful artifacts, careful frameworks, slow ceremonies, very little real change.
The teams that actually move metrics work differently.
They state problems sharply.
They validate the cheapest assumption first.
They generate three solutions instead of one.
They ship tests instead of conclusions.
And they measure.
This guide is the field manual for that kind of work. By the end you will know why most UX problem-solving fails, the three types of problems and how each one wants to be attacked, the seven-step process that actually ships answers, the five mental models that do most of the heavy lifting, when to use which research method, the seven failure modes that haunt good teams, how to run a one-week problem-solving sprint, and real examples of teams that did this well.
Let's get into it.
Part 1: Why Most UX Problem-Solving Is Theater
Before the playbook, the diagnosis. Most teams do not have a problem-solving deficit. They have a problem-finishing deficit. They start strong, run out of energy, and stall in the middle of the process.
4 patterns show up over and over.
The discovery treadmill
Research turns into a self-perpetuating activity. Every insight raises three new questions, every workshop spawns two new workshops, every persona needs more interviews. The team is moving but never arriving. Six months pass. The problem is still unsolved. The deck is gorgeous.
The over-research trap
Some problems do not need more research. They need a decision. When a team keeps researching past the point of diminishing returns, they are not being rigorous. They are being avoidant. Research is sometimes the safest place to hide from action.
The framework fetish
Double Diamond. Design Thinking. Jobs To Be Done. Service Blueprints. The frameworks are useful. The fetish is when teams use the framework as the work, ticking each phase off like a checklist, generating the right artifacts at the right times, and never shipping anything that changes a metric.
The wireframe-as-deliverable mistake
Wireframes are scaffolding. They are not the building. Teams that finish with a stack of polished wireframes and call it done have confused the artifact for the outcome. The outcome is a working product change that moves a number. Everything else is decoration.
The good news. None of these patterns are about talent. They are about process and discipline. Fix the process and the talent already on your team will start finishing things.
Part 2: The Three Types of UX Problems
Not every UX problem is the same. Treating them all with the same process is one of the most common mistakes mid-career designers make. The right move is to diagnose the type of problem first, then pick the attack.
1. Mystery problems
You know something is wrong but you do not know what. Conversion is down. Retention is down. The team blames the redesign, the marketing team blames the funnel, leadership blames the algorithm. Nobody is sure. Mystery problems want diagnostic work first. Analytics, session recordings, user interviews, root cause analysis. Skip diagnosis on a mystery and you will solve the wrong problem brilliantly.
2. Translation problems
You know exactly what is wrong but you cannot figure out how to fix it cheaply. The signup flow is too long. The mobile experience lags behind web. The error states are confusing. Translation problems want generative work. Brainstorming, sketching, prototyping, prioritization. Skip the generative work and you will ship the first idea that comes to mind, which is rarely the best one.
3. Politics problems
Everyone on the team already knows what the right answer is. The problem is that nobody is empowered to ship it. The PM wants one thing, the engineering lead wants another, the executive sponsor has an opinion, the brand team has a veto. Politics problems want alignment work. Crisp problem statements, shared metrics, executive air cover, decision frameworks. Skip the alignment and the best design in the world will get killed in review.
Most projects are a blend, but one type usually dominates. Spend an hour at the start asking which type you are actually facing. The rest of the work changes based on the answer.
Problem type | What it wants | Common mistake |
Mystery | Diagnostic research first | Jumping to solutions before understanding the cause |
Translation | Generative ideation and prototyping | Picking the first idea, not the best of three |
Politics | Alignment, framing, sponsorship | Designing in a vacuum and surprising stakeholders |
Part 3: The Seven-Step Honest Process
Frameworks abound.
Most are over-engineered.
This is the seven-step process that real teams actually follow when they want to move a metric, written without the corporate gloss.
A problem well-stated is a problem half-solved. - Charles Kettering
1. State the problem clearly
No jargon.
No project name.
No solutioning.
"Mobile signup is converting at 4% while desktop is at 11%, and we believe the gap is widening." Not "Project Rocket needs a mobile UX refresh." If you cannot state the problem in one sentence a stranger would understand, you have not yet understood the problem.
2. Validate the assumption before the solution
Underneath every brief is an assumption you have not checked. "Users want X." "This page is slow." "The funnel breaks at step three." Test the loudest assumption first, fast and cheaply. A 30-minute session-recording audit beats a six-week generative study when the assumption is wrong.
3. Map the inputs and outputs
What signals come in?
What change is supposed to come out?
Draw it.
A whiteboard photograph is fine.
The act of drawing inputs and outputs forces you to spot the gap between what you measure and what you want to change.
Most teams find at least one disconnect in this step.
4. Generate at least three solutions, never one
If you are only considering one solution, you are not solving, you are advocating. Force three. The first will be obvious, the second will be derivative, the third will be the one nobody else has thought of. Pick from those, not from your first instinct.
5. Pick by trade-offs, not by "best."
Every solution has cost, time, risk, and upside. Score them. The right choice is rarely the most beautiful or the most clever. It is the one with the best trade-off profile for the moment your team is in. Be explicit about why you are picking. Write it down.
6. Ship the smallest test, not the full solution
Cut the work to the smallest version that will tell you whether the bet is correct. An A/B test on one screen beats a full redesign. A clickable prototype with five users beats a quarterly research plan. The cheapest test that proves or disproves the bet is the right test.
7. Measure what you said you would measure
Before you ship, write down the number you expect to move and by how much. After you ship, check that number. Honest teams do this within two weeks. Dishonest teams forget the metric, declare victory based on vibes, and move on. The single biggest predictor of a team that consistently improves is whether they actually go back and check.
Apply these seven steps in order and most UX problems become tractable inside a month. Skip any of them and you join the long parade of teams that produce beautiful artifacts and unchanged metrics.
The honest process | The theater process |
State the problem in one sentence | Open with a 47-slide "context" deck |
Validate the loudest assumption first | Research everything before deciding anything |
Generate three solutions | Fall in love with the first idea |
Pick by trade-offs | Pick by aesthetics or seniority |
Ship the smallest test | Ship the full redesign |
Measure two weeks later | Forget the metric, declare victory |
Part 4: Five Mental Models That Do Most of the Heavy Lifting
You can solve most UX problems with five mental models. Pull one off the shelf, apply it, and ninety percent of the time the path forward becomes obvious.
1. The Five Whys
Ask why something is happening.
Ask why again about the answer.
Five times.
By the fifth why, you are usually at the root cause.
Users abandon checkout.
Why?
They get confused.
Why?
The shipping options are hidden.
Why?
Engineering moved them to reduce page weight.
Why?
The page was too slow.
Why?
An old hero image was 4MB.
Five whys later, you have a 30-minute fix instead of a four-week project.
2. Inversion
Stop asking how to make it better. Ask how to make it worse. If you wanted to actively destroy this experience, what would you do? The answers reveal the failure modes you have been quietly designing into the product. Charlie Munger calls this inversion. It is the cheapest, most underused thinking tool in design.
3. First Principles
Strip the problem down to what is actually true. Not what convention says. Not what the brand guidelines say. Not what last year's roadmap committed to. What does the user actually need? What does the business actually need? What does the technology actually do? Build back up from there. Most products carry decades of assumptions that no longer apply. First principles thinking burns them away.
4. Theory of Constraints
Every system has a single bottleneck that determines its throughput. Improving anything that is not the bottleneck does not improve the system. In UX, this means most of the optimization work teams do is wasted. Find the actual bottleneck. Fix that. Then find the new one. Repeat. Eliyahu Goldratt wrote a whole book about this for manufacturing. The same logic moves UX metrics.
5. The Pareto Principle
80% of the impact comes from 20% of the work. In any UX problem, three to five decisions matter and the rest are noise. The hard part is figuring out which three to five. Once you know them, the rest of the project gets easier. The teams that ship are the teams that can identify the 20% quickly and ignore the other 80% without guilt.
None of these are new. None of them are uniquely "design." That is the point. The best UX problem-solvers are not pure designers. They are generalist thinkers who know which mental model to reach for and when.
Part 5: When to Use Which Research Method
Half the wasted time in UX problem-solving is wasted on the wrong research method.
The interview that should have been a survey.
The usability test that should have been an analytics deep-dive.
The persona exercise that should have been a quick five-user check.
Pick the right tool and the work compresses by half.
You need to know... | Reach for... | Time to result |
What is actually happening on the live product | Analytics + session recordings | One to two days |
Why users are doing what they are doing | 6 to 8 user interviews | One week |
What users would prefer (multiple options) | Quantitative survey | One to two weeks |
Whether a specific solution works | Usability testing with prototype, 5 users | Three days |
What the unmet need is | Generative diary studies or contextual inquiry | Two to four weeks |
Whether a change moved the metric | A/B test on real traffic | Two to four weeks after ship |
What the competition does | Competitive teardown | One day |
Three rules for picking. First, match the method to the question, not the other way around. Second, use the cheapest method that will actually answer your question. Third, when in doubt, just go talk to five users on the phone. That is the highest ROI move in our discipline and most teams underuse it.
Part 6: Seven Failure Modes That Trap Good Teams
Even teams that know the playbook fall into these traps.
Pattern-match against them ruthlessly.
Failure 1: Solving the wrong problem brilliantly.
Beautiful execution on a problem that does not matter. Common when teams skip the problem-validation step and jump straight to designing. The fix: spend more time on the problem definition than the solution. If you cannot defend why this problem is worth solving right now, redesign the scope before you redesign the screens.
Failure 2: Over-researching the obvious.
Some problems do not need a study. They need a fix. When the issue is staring you in the face, do not commission a research project to confirm what you already know. Save the research budget for the times you genuinely cannot see the answer.
Failure 3: Designing around stakeholders, not users.
The CEO has opinions. The CMO has opinions. The PM has opinions. The user is rarely in the room. Teams that design around stakeholders ship products that please nobody outside the building. Make the user concrete. Bring them into the room as data, as quotes, as faces, as moments. Otherwise the loudest stakeholder wins by default.
Failure 4: Falling in love with your first solution.
The first idea is rarely the best one. It is just the most familiar. Force yourself to brainstorm at least three distinct directions before picking. The third one is usually the most interesting. If you cannot bear to consider alternatives, your judgment is compromised.
Failure 5: Confusing aesthetics with effectiveness.
A beautiful flow that converts at 4% is worse than an ugly flow that converts at 12%. The goal is the metric, not the screenshot. Design awards mostly reward the screenshot. Design careers reward the metric. Choose which game you are playing.
Failure 6: Optimizing the wrong metric.
Engagement went up but revenue went down. Sessions went up but retention went down. Every team has a story like this. The fix is to be explicit about which metrics you are trying to move and which ones you will accept as collateral damage. Without that clarity, you optimize whatever is convenient and call it a win.
Failure 7: Shipping without a measurement plan.
If you do not measure, you cannot learn. If you cannot learn, you do not improve. If you do not improve, you are running on instinct forever. Write the measurement plan before you ship the work, not after.
Sounds like a win | Probably is not |
"Stakeholders loved the deck" | Did the metric move? |
"We followed the framework" | Did anything actually change for users? |
"Beautiful execution" | On the right problem? |
"We shipped on time" | Did you measure two weeks later? |
Part 7: How to Run a One-Week Problem-Solving Sprint
When a problem is well-scoped, a focused team can move from "we have a problem" to "we have a tested direction" in one week. Not every project fits this. The ones that do, run like this.
Day | Goal | Who is in the room |
Monday | Define & diverge. Sharp problem statement. Three distinct solution directions sketched by lunch. | Designer, PM, engineer lead, researcher |
Tuesday | Decide. Pick one direction by trade-off scoring. Write the year-one (or quarter-one) scorecard for the bet. | Same team plus executive sponsor |
Wednesday | Prototype. Build a clickable version of the chosen direction. Low fidelity is fine. | Designer, plus engineer for technical risk-check |
Thursday | Test. Five user sessions with the prototype. Plus engineering feasibility deep-dive in parallel. | Researcher leads. Whole team observes at least one session. |
Friday | Synthesize. Write the one-page decision memo. What we tested, what we learned, what we are doing next. | Designer + PM write. Everyone reviews. |
Two things make or break the sprint.
One: the executive sponsor must be available on Monday and Friday at minimum.
Without that, the decisions get re-litigated.
Two: the team must commit to actually shipping the next step within two weeks of Friday.
Otherwise the sprint becomes another deck.
Variants exist. The Google Ventures design sprint is the most famous. Adjust the days to your team's rhythm but keep the shape: define, decide, prototype, test, synthesize. One week from confusion to direction. Repeat as needed.
Part 8: Real Examples of UX Problems Solved Well
Theory is cheap.
Examples teach.
Four cases of teams that did not just identify a problem but actually shipped a fix that moved the needle.
1. Slack's onboarding rebuild
Early Slack realized that the first hour of a new team's experience predicted whether they would still be using the product a month later. They redesigned onboarding around the specific behaviors of teams that stuck (post at least 2,000 messages in the first three weeks). Everything in the onboarding flow was rebuilt to push toward that behavior. Retention climbed dramatically. The lesson: tie the design to the specific user behavior that predicts the outcome you care about.
2. Airbnb's Superhost program
The problem was trust at scale. As Airbnb grew, guests could not tell which hosts were reliable. They tried badges, ratings, and verifications. The breakthrough was Superhost: a clearly defined status with concrete requirements and visible benefits for both hosts and guests. Trust became a product feature instead of a hope. Bookings to Superhosts grew. The lesson: when the abstract problem is "trust," the concrete solution is a system, not a sticker.
3. Spotify's Discover Weekly
The problem was discovery. Users had access to 30 million songs and listened to roughly 50. Spotify could have built a better search. They built a personalized weekly playlist instead. A single feature, refreshed every Monday, designed to feel like a friend made it for you. It became one of the most loved features in any music product ever. The lesson: sometimes the answer to a discovery problem is not better discovery tools but a curated artifact that does the discovery for you.
4. The iPhone X notch
Apple faced a hardware constraint that became a UX problem. The TrueDepth camera array required space at the top of the screen. The team had two choices: hide it (technically impossible) or design with it. They chose to design with it, building a distinctive notch silhouette that became a signature of the entire generation. The lesson: when constraints cannot be removed, treat them as design features. The best UX problem-solvers do not fight reality. They build with it.
Quick Answers to the Questions Every Team Asks
When is more research actually worth it?
When the cost of being wrong is higher than the cost of the research. Redesigning the checkout flow? Worth a week of research. Picking between two button colors? Just A/B test. The bigger the bet, the more research pays for itself. The smaller the bet, the faster you should just ship and learn.
How long should a UX problem-solving phase last?
Most problems should move from "defined" to "first tested" in 2 to 6 weeks. Past 6 weeks without a single hypothesis tested, the project is stuck. Either the problem is much bigger than scoped (split it) or the team is avoiding action (force a deadline).
What if stakeholders will not let me change the scope?
State your case once in writing, with the trade-offs spelled out. If they still say no, you have two options: deliver the scope they asked for while quietly tracking the metric that suggests they are wrong (the data will do the arguing for you later), or escalate. Choose the battle worth fighting. Some hills are not worth dying on.
How do I know I have solved the right problem?
The metric you said you would move actually moves. If you cannot define which metric, you do not yet have a problem, you have an itch. Define the metric first, then check it after.
What if the data says one thing and my intuition says another?
First, check the data. Most data conflicts come from instrumentation bugs, sample bias, or the wrong segmentation. If the data holds up under scrutiny, trust it. Intuition is real and useful, but it is also where bias hides. Strong opinions, weakly held.
When should I just ship and learn?
When the bet is small, reversible, and the upside of learning is higher than the cost of being wrong. Most UX changes fit this description. Most UX teams underuse this option. The shipping is the learning.
Putting It All Together
Solving UX problems well is not about being smarter than other designers. It is about being more disciplined.
Diagnose the problem type before you pick the attack.
State the problem in one sentence.
Validate the loudest assumption first.
Generate three solutions.
Pick by trade-offs.
Ship the smallest test.
Measure what you said you would measure.
Pull the right mental model off the shelf.
Use the cheapest research method.
Avoid the seven failure modes.
Run a one-week sprint when you can.
Steal from the teams that have done it well.
Do all of this and you join the small group of designers whose work actually moves numbers. Skip any of it and you produce beautiful artifacts that change nothing.
The hardest part of UX problem-solving is not the thinking. It is the finishing. Most teams are smart enough. Fewer are disciplined enough.
Solve the right problem cheaply. Not the wrong problem expensively.
Go finish something.
Comments