If I am stuck on a UX problem, I do not open Figma first. I open a blank line in a text file.
Here is the uncomfortable truth. If you cannot explain what you are designing in one sentence, you are probably not designing yet; you are decorating, guessing, or hiding behind process.
This is the one-sentence UX test. It is simple. It is annoying. And it works.
The Test
Write one sentence that answers:
- Who is this for?
- What are they trying to do?
- What is the outcome they want?
- What is the constraint that makes it a design problem?
A practical template
“Help [specific user] accomplish [specific goal] in [specific context] so they can [measurable outcome], without [key friction or constraint].”
Imagine you are redesigning a booking flow for a small clinic.
Start with a vague request.
“Make appointment booking easier.”
Now break it down using the questions:
- Who is this for?
New patients booking for the first time. - What are they trying to do?
Schedule an appointment without calling. - What is the outcome they want?
Confirm a time and know what to do next. - What is the constraint that makes it a design problem?
They are on mobile, they are anxious, and the form asks for too much too soon.
Turn that into one sentence:
“Help first-time patients book an appointment on their phone in under two minutes so they can feel confirmed and prepared, without forcing them to create an account or fill out a long intake form upfront.”
Now you have something you can design around. You can also measure it. Time to complete, drop-off rate, and fewer calls to the front desk.
If you cannot write that sentence, you do not have a design problem yet. You have a vibe.
Why This Works And Why It Hurts
UX gets fuzzy fast. We say things like “make it more intuitive” or “improve the experience.” Those phrases feel productive, but they are not actionable.
A one-sentence definition forces clarity.
- It exposes when you do not actually know the user.
- It reveals when the goal is too broad.
- It highlights when stakeholders are optimizing for different outcomes.
- It makes constraints visible: time, device, policy, anxiety, accessibility, and trust.
Once you have clarity, design decisions get easier. Not easy, just less chaotic.
Examples: Weak Vs Strong Sentences
Here are a few real-world rewrites.
Example 1 – Checkout
Weak: Improve the checkout flow.
Stronger: Help returning customers reorder their last purchase on mobile in under 30 seconds so they can check out with confidence, without re-entering shipping and payment details.
Now you can design. You can measure. You can argue less.
Example 2 – Healthcare Intake
Weak: Make the intake form simpler.
Stronger: Help first-time patients complete pre-visit intake on a phone so they can arrive prepared, without feeling overwhelmed by medical jargon or long multi-step forms.
That sentence tells you what to remove, what to rewrite, and what to prioritize.
Example 3 – Internal Tool
Weak: Redesign the admin dashboard.
Stronger: Help support agents find and resolve a customer’s billing issue during a live call so they can close the ticket in one interaction, without hunting across multiple tabs and systems.
Now you are designing for speed, accuracy, and stress.
The Hidden Benefit Alignment
Most UX conflict is not about layout. It is about mismatched definitions of success.
When you put the one sentence on the table, you can finally have the right argument.
- Are we designing for new users or power users?
- Are we optimizing for speed or trust?
- Is the goal completion, retention, fewer support tickets, or fewer errors?
- What constraint matters most right now?
This is also where you discover when a design request is actually a product decision, a policy issue, or a data problem.
How To Use It In Your Workflow
Here are a few ways I have used this test in real projects.
1. Before You Open The Design File
Write the sentence at the top of the ticket, doc, or FigJam board. If you cannot write it, your first task is discovery, not UI.
2. As A Stakeholder Filter
If someone asks for a feature, ask them to help you finish the sentence.
If they cannot, that is not a bad stakeholder. That is a sign that the problem is not yet defined.
3. As A Critique Tool
In a design review, point to the sentence and ask:
- Which part of this design supports the goal?
- Which part reduces the constraint?
- What is here because it looks nice, not because it helps?
It is a gentler way to critique without making it personal.
4. As A Scope Guardrail
When scope creep shows up, and it will, you can say:
“Does this help the user accomplish the goal in the sentence?”
If not, park it.
Common Failure Modes And How To Fix Them
The Sentence Is Too Broad
If your sentence includes words like “users”, “easily”, “better”, or “improve”, it is probably too vague.
Pick one user type and one job to be done. Then name a measurable outcome.
You Do Not Know The User Yet
That is normal and not a blocker.
Rewrite the sentence as a hypothesis.
“We believe [user] is trying to [goal] in [context] so they can [outcome].”
Then, validate with a quick check, a short interview, support tickets, analytics, or a usability test.
Stakeholders Want Different Things
Also normal. The mess is the signal.
Write one sentence per goal. Put them side by side. Then choose which sentence you are designing for in this iteration.
If you cannot choose, you are not in design yet; you are in prioritization.
A Quick Exercise You Can Do Today
Pick something you are designing right now and write the one sentence.
Then do one more step. Underline the constraint.
That constraint is where the design work lives.
Closing Thought
Design is not the artifact. It is the decision-making.
Decision-making gets a lot easier when you can explain what you are doing, clearly, simply, and in one sentence.
