UX problem solving
Start with the question
How I frame a problem before I design, and test the riskiest assumptions early.
Topic
UX problem solving
Reading time
3 minutes
Covers
Framing, mapping, testing
Visuals
Original illustrations
Problem framing
One page, before any design
1
The request
"Add a dashboard to the home screen."
2
Who is struggling
Team leads who check three tools every morning.
3
What they are trying to do
Know what needs attention before the day starts.
4
What success looks like
Faster mornings and fewer missed items.
5
Constraints
Existing data, a two-week window, shared components.
6
Assumptions to test
People want one list. Priority is clear from the label.
Reframed
How might we help team leads see what needs attention first?
One page that turns a request into a question.
Ask what is really going wrong
Most design problems arrive as a solution: add a dashboard, redesign this page, build a new flow. I start by turning that request back into a question. Who is struggling? What are they trying to do? What does success look like for them, and for the business? Writing the answers on one page keeps the whole team aligned before anyone opens a design file.
Map the experience, find the friction
Next I map the experience as it works today, end to end. I look for the moments where people lose time, confidence, or trust, and I mark them so everyone can see where the problem actually lives. It is often not where the original request pointed, and seeing it together changes the conversation.
Where people lose time or confidence
Journey map
Doing
Friction
Opportunity
1
Discover
Hears about the service from a colleague.
Low
Make the first step obvious.
2
Choose
Compares options in three tabs.
Medium
Show options side by side.
3
Book
Fills a long form with unclear fields.
High
Group and shorten the form.
4
Confirm
Waits for an email that may not arrive.
High
Confirm on screen right away.
5
Use
Checks status and gets updates.
Low
Keep status in one place.
Friction shows up where people hesitate, not where we expect it.
Explore a few directions, out loud
I explore two or three directions instead of polishing the first idea. Each one gets a quick sketch and an honest list of trade-offs, so the discussion is about what we are optimizing for rather than about taste. Showing options early also makes it easier for product and engineering to shape the choice.
Three directions, side by side
Sketch before polish
A. One combined list
Pros: Everything in one place
Trade-off: Can feel long
B. Needs-attention first
Chosen
Pros: Clear starting point
Trade-off: Needs good rules
C. Tabs by source
Pros: Familiar and simple
Trade-off: Still three places
Three directions, each with its trade-offs.
Test the riskiest assumption first
Every direction rests on assumptions. I rank them by risk and test the scariest ones first, with a clickable prototype, a short usability session, or a conversation with a customer. A few small tests early cost far less than a rebuild after launch.
Assumptions, ranked by risk
Sample plan
Assumption
Risk
How we tested it
Result
People want one combined list
High
5 usability sessions
Validated
Priority is clear from the label alone
High
Clickable prototype
Revised
A daily summary email is enough
Medium
Survey, 40 responses
Needs follow-up
This task matters on mobile
Low
Usage data review
Validated
A simple plan: what we believe, how we test it, and what we learned.
Make the decision easy to explain
The goal is a decision I can explain, not just a screen that looks good. I write down what we learned, which option we chose, and why, then show the result next to where we started. Every design should be able to answer two things: what problem does this solve, and how would we know?
Before
Book a service
Name
Full name
Email address
Invalid input
Phone
Phone number
Date
Pick a date
Time
Pick a time
Address
Street address
Notes
Anything else
Promo code
Optional
Submit
Cancel
After
Book a service
Takes about two minutes.
Your details
Name
Full name
Email address
Enter an email like name@example.com
Phone
Phone number
When and where
Date
Pick a date
Time
Pick a time
Address
Street address
Extras
Notes
Anything else
Promo code
Optional
Book now
Cancel
1
2
3
4
1
One clear next step.
2
A clear hierarchy.
3
An error that explains the fix.
4
Fields grouped into three sections.
The same form before and after, with the reason for each change.
Good design starts with a good question
Next article
Beyond shipped →
Product design leader. Design functions,
systems, and products for complex SaaS.
Case Studies
Web design system
Native design system
Unified Inbox
AI capability
About
About
How I Work
Résumé
Contact
aln.dohotaru@gmail.com
© 2026 Alina Dohotaru
Visuals are original illustrations and do not depict proprietary product screens.
UX problem solving
Start with the question
How I frame a problem before I design, and test the riskiest assumptions early.
Topic
UX problem solving
Reading time
3 minutes
Covers
Framing, mapping, testing
Visuals
Original illustrations
Problem framing
One page, before any design
1
The request
"Add a dashboard to the home screen."
2
Who is struggling
Team leads who check three tools every morning.
3
What they are trying to do
Know what needs attention before the day starts.
4
What success looks like
Faster mornings and fewer missed items.
5
Constraints
Existing data, a two-week window, shared components.
6
Assumptions to test
People want one list. Priority is clear from the label.
Reframed
How might we help team leads see what needs attention first?
One page that turns a request into a question.
Ask what is really going wrong
Most design problems arrive as a solution: add a dashboard, redesign this page, build a new flow. I start by turning that request back into a question. Who is struggling? What are they trying to do? What does success look like for them, and for the business? Writing the answers on one page keeps the whole team aligned before anyone opens a design file.
Map the experience, find the friction
Next I map the experience as it works today, end to end. I look for the moments where people lose time, confidence, or trust, and I mark them so everyone can see where the problem actually lives. It is often not where the original request pointed, and seeing it together changes the conversation.
Where people lose time or confidence
Journey map
Doing
Friction
Opportunity
1
Discover
Hears about the service from a colleague.
Low
Make the first step obvious.
2
Choose
Compares options in three tabs.
Medium
Show options side by side.
3
Book
Fills a long form with unclear fields.
High
Group and shorten the form.
4
Confirm
Waits for an email that may not arrive.
High
Confirm on screen right away.
5
Use
Checks status and gets updates.
Low
Keep status in one place.
Friction shows up where people hesitate, not where we expect it.
Explore a few directions, out loud
I explore two or three directions instead of polishing the first idea. Each one gets a quick sketch and an honest list of trade-offs, so the discussion is about what we are optimizing for rather than about taste. Showing options early also makes it easier for product and engineering to shape the choice.
Three directions, side by side
Sketch before polish
A. One combined list
Pros: Everything in one place
Trade-off: Can feel long
B. Needs-attention first
Chosen
Pros: Clear starting point
Trade-off: Needs good rules
C. Tabs by source
Pros: Familiar and simple
Trade-off: Still three places
Three directions, each with its trade-offs.
Test the riskiest assumption first
Every direction rests on assumptions. I rank them by risk and test the scariest ones first, with a clickable prototype, a short usability session, or a conversation with a customer. A few small tests early cost far less than a rebuild after launch.
Assumptions, ranked by risk
Sample plan
Assumption
Risk
How we tested it
Result
People want one combined list
High
5 usability sessions
Validated
Priority is clear from the label alone
High
Clickable prototype
Revised
A daily summary email is enough
Medium
Survey, 40 responses
Needs follow-up
This task matters on mobile
Low
Usage data review
Validated
A simple plan: what we believe, how we test it, and what we learned.
Make the decision easy to explain
The goal is a decision I can explain, not just a screen that looks good. I write down what we learned, which option we chose, and why, then show the result next to where we started. Every design should be able to answer two things: what problem does this solve, and how would we know?
Before
Book a service
Name
Full name
Email address
Invalid input
Phone
Phone number
Date
Pick a date
Time
Pick a time
Address
Street address
Notes
Anything else
Promo code
Optional
Submit
Cancel
After
Book a service
Takes about two minutes.
Your details
Name
Full name
Email address
Enter an email like name@example.com
Phone
Phone number
When and where
Date
Pick a date
Time
Pick a time
Address
Street address
Extras
Notes
Anything else
Promo code
Optional
Book now
Cancel
1
2
3
4
1
One clear next step.
2
A clear hierarchy.
3
An error that explains the fix.
4
Fields grouped into three sections.
The same form before and after, with the reason for each change.
Good design starts with a good question
Next article
Beyond shipped →
Product design leader. Design functions,
systems, and products for complex SaaS.
Case Studies
Web design system
Native design system
Unified Inbox
AI capability
About
About
How I Work
Résumé
Contact
aln.dohotaru@gmail.com
© 2026 Alina Dohotaru
Visuals are original illustrations and do not depict proprietary product screens.
UX problem solving
Start with the question
How I frame a problem before I design, and test the riskiest assumptions early.
Topic
UX problem solving
Reading time
3 minutes
Covers
Framing, mapping, testing
Visuals
Original illustrations
Problem framing
One page, before any design
1
The request
"Add a dashboard to the home screen."
2
Who is struggling
Team leads who check three tools every morning.
3
What they are trying to do
Know what needs attention before the day starts.
4
What success looks like
Faster mornings and fewer missed items.
5
Constraints
Existing data, a two-week window, shared components.
6
Assumptions to test
People want one list. Priority is clear from the label.
Reframed
How might we help team leads see what needs attention first?
One page that turns a request into a question.
Ask what is really going wrong
Most design problems arrive as a solution: add a dashboard, redesign this page, build a new flow. I start by turning that request back into a question. Who is struggling? What are they trying to do? What does success look like for them, and for the business? Writing the answers on one page keeps the whole team aligned before anyone opens a design file.
Map the experience, find the friction
Next I map the experience as it works today, end to end. I look for the moments where people lose time, confidence, or trust, and I mark them so everyone can see where the problem actually lives. It is often not where the original request pointed, and seeing it together changes the conversation.
Where people lose time or confidence
Journey map
Doing
Friction
Opportunity
1
Discover
Hears about the service from a colleague.
Low
Make the first step obvious.
2
Choose
Compares options in three tabs.
Medium
Show options side by side.
3
Book
Fills a long form with unclear fields.
High
Group and shorten the form.
4
Confirm
Waits for an email that may not arrive.
High
Confirm on screen right away.
5
Use
Checks status and gets updates.
Low
Keep status in one place.
Friction shows up where people hesitate, not where we expect it.
Explore a few directions, out loud
I explore two or three directions instead of polishing the first idea. Each one gets a quick sketch and an honest list of trade-offs, so the discussion is about what we are optimizing for rather than about taste. Showing options early also makes it easier for product and engineering to shape the choice.
Three directions, side by side
Sketch before polish
A. One combined list
Pros: Everything in one place
Trade-off: Can feel long
B. Needs-attention first
Chosen
Pros: Clear starting point
Trade-off: Needs good rules
C. Tabs by source
Pros: Familiar and simple
Trade-off: Still three places
Three directions, each with its trade-offs.
Test the riskiest assumption first
Every direction rests on assumptions. I rank them by risk and test the scariest ones first, with a clickable prototype, a short usability session, or a conversation with a customer. A few small tests early cost far less than a rebuild after launch.
Assumptions, ranked by risk
Sample plan
Assumption
Risk
How we tested it
Result
People want one combined list
High
5 usability sessions
Validated
Priority is clear from the label alone
High
Clickable prototype
Revised
A daily summary email is enough
Medium
Survey, 40 responses
Needs follow-up
This task matters on mobile
Low
Usage data review
Validated
A simple plan: what we believe, how we test it, and what we learned.
Make the decision easy to explain
The goal is a decision I can explain, not just a screen that looks good. I write down what we learned, which option we chose, and why, then show the result next to where we started. Every design should be able to answer two things: what problem does this solve, and how would we know?
Before
Book a service
Name
Full name
Email address
Invalid input
Phone
Phone number
Date
Pick a date
Time
Pick a time
Address
Street address
Notes
Anything else
Promo code
Optional
Submit
Cancel
After
Book a service
Takes about two minutes.
Your details
Name
Full name
Email address
Enter an email like name@example.com
Phone
Phone number
When and where
Date
Pick a date
Time
Pick a time
Address
Street address
Extras
Notes
Anything else
Promo code
Optional
Book now
Cancel
1
2
3
4
1
One clear next step.
2
A clear hierarchy.
3
An error that explains the fix.
4
Fields grouped into three sections.
The same form before and after, with the reason for each change.
Good design starts with a good question
Next article
Beyond shipped →
Product design leader. Design functions,
systems, and products for complex SaaS.
Case Studies
Web design system
Native design system
Unified Inbox
AI capability
About
About
How I Work
Résumé
Contact
aln.dohotaru@gmail.com
© 2026 Alina Dohotaru
Visuals are original illustrations and do not depict proprietary product screens.