Why the problem comes first
Makers love solutions. A new tool, a clever mechanism or a circuit that does something unexpected is more fun than a paragraph of description. But a solution built for a poorly understood problem tends to be impressive and unused. Time spent describing the need clearly is usually the cheapest time in the whole project.
A good description does three jobs. It tells you what to work on, it helps you say no to features that do not matter, and it gives you a way to check the finished result. Without it, “done” just means “I ran out of energy.”
Problems versus solutions in disguise
Many project ideas are solutions already. “I need an app that reminds me to water plants” assumes an app, reminders and a certain kind of plant owner. The underlying problem might be “I forget which plants need water and when.” Written that way, the answer could be a sticker chart, a sensor, a better shelf position or a calendar entry.
A useful test is to look for a built-in answer. If your statement contains a product type or a technology, such as an app, a sensor or a motor, ask what the person is actually trying to achieve. Rewrite until the statement could be answered in several different ways.
The ingredients of a good problem statement
A problem statement does not need to be long. A few sentences are usually enough, and they typically answer these questions:
- Who has the problem? Be specific. “Beginners” is vague; “someone learning to solder for the first time at a kitchen table” is better.
- What are they trying to do, and what gets in the way?
- Where and when does it happen? Context matters: a tool used outdoors in the cold has different needs from one used on a desk.
- Why does it matter? What is the cost of the problem, whether it is time, discomfort, money or risk?
A simple template is: “[Person] needs a way to [goal] because [obstacle], which leads to [consequence].” It will not suit every project, but it forces the key pieces onto the page.
An example
Suppose you notice that a family member has trouble with a kitchen drawer. A solution-first note might say, “Design a better drawer handle.” A problem statement is more useful: “My grandfather has stiff fingers and cannot pull the kitchen drawers open without gripping hard, so he asks for help with everyday tasks.”
The second version allows many answers: a larger handle, a loop he can hook a finger through, a soft-close mechanism, or even rearranging what lives in which drawer. It also points toward things to measure, such as grip comfort, which is where human factors thinking comes in.
Finding out what is really going on
Your first description is a guess. Check it against reality before you commit.
- Observe. Watch the problem happen if you can. People often work around difficulties without noticing.
- Ask open questions. Simple user interviews can reveal that the problem you picked is not the one that bothers people most.
- Look at existing options. If something already helps, find out why people are still struggling. Maybe it is too expensive, too fragile or hard to understand.
- Ask “why” a few times. Each answer tends to move from a symptom toward a cause.
Be willing to change the statement after what you learn. A revised statement is a sign that the process is working.
Setting boundaries
Problems have edges. Decide what is in and out of scope, and write down your constraints: budget, available tools, time, skills, the space where the product will live, and any safety concerns. If your project involves electricity or heat, note early that you will keep to low voltage while learning and avoid modifying mains-powered equipment unless you are qualified, since constraints about safety shape every later decision.
It also helps to write a few success criteria. These should be things you can check, such as “can be opened with one hand” or “can be built from materials I already have.” Avoid criteria that depend on a feeling you cannot test. Having criteria is also what makes later usability testing meaningful, since you know what you are looking for.
Common mistakes
- Making the statement too broad. “Make cooking easier” cannot be tested or finished.
- Making it too narrow. If it names the answer, you have stopped exploring.
- Describing only your own experience. You are one user, and often not a typical one.
- Never revisiting it. Pin the statement near your workspace and read it when a feature is tempting.
Using the statement along the way
Return to the statement at each stage. When you are sketching, ask which sketches address it. When you build a rough model, make sure the model answers a question the statement raised. When you finish, compare the result with your success criteria. If the result is not quite right, that is useful information about either the product or the problem.
A problem statement is not a contract. It is a working tool that keeps your attention on a real person with a real need, and it makes the work that follows more focused and easier to explain to others.