A Quick Acid Test for Your Product Design Knowledge?

A user problem scenario is a question aimed directly at your audience – “Want to achieve X while addressing Y?” – rather than a statement aimed at your team, like the user needs statements described by the Nielsen Norman Group (“A user needs X to achieve Y”). Same underlying need, different job: needs statements guide internal design decisions, while problem scenarios spark reflection in someone reading your landing page or README. Start with specific, advanced challenges before moving to general, introductory ones – specificity is what lets a reader recognize themselves.

Try it on your own product

Here's what that looked like for Docsify-This:

• Curious about using Markdown files as shareable web pages for open education, publishing, or collaboration – with no website setup?
• Want to quickly leverage Markdown content for education, publishing, or collaboration?
• Are you using a Learning Management System (LMS) and want to leverage constraint-free portable Markdown text for your course content?
• Want to embed the same content across multiple platforms while customizing its visual style for each context?
• Do you want to maintain access and control of your course content while having the ability to embed it into your institutional LMS?
• Want to create open course materials that are accessible both inside and outside your LMS?
• Do you have multiple LMS courses and want one source for content, under your full control?

The same technique works for any product, not just Markdown publishing tools. A few written for Figma, a collaborative prototyping tool:

• Want to collaborate with design team members across different locations in real time, with a shared workspace?
• Want to share design prototypes and mockups instantly without complicated file transfers or version-control issues?
• Do you need to streamline design handoff between designers and developers, ensuring accurate implementation?

What makes a good one

A good user problem scenario prioritizes real challenges over features or unfamiliar jargon, encourages reflection rather than just informing, and balances relatability with a professional tone for both technical and non-technical readers. It sparks interest by presenting a relatable challenge, links that challenge to what the product actually offers, and helps people notice a need they hadn't fully articulated yet.

Originally built for marketing and onboarding, these scenarios double as a quick test of whether a product team shares a real, unified understanding of how and why people actually use what they've built – which is the acid test. Try writing five for whatever you're building; if you can't, that's worth knowing too.