Start with the situation, not the invention
It is easy to begin a design project with a solution: build an app, add a sensor or make a task automatic. Those ideas can be useful, but they also narrow the questions you ask. If a team starts with “How can we add a screen to this appliance?”, it may miss that people cannot reach the existing controls or understand the labels. Framing the problem first means describing the difficulty people experience before deciding what should be built.
Consider a shared apartment building where residents often leave packages in the lobby. “Install smart lockers” is a proposed solution. A more useful starting point is: “Residents need a reliable way to receive deliveries when they are not home, without creating extra work for building staff.” That statement leaves room to compare lockers with simpler changes, such as clearer delivery instructions or a staffed pickup arrangement. It also makes success easier to discuss: fewer missed handoffs may matter more than the novelty of the hardware.
Find out whose problem it is
A problem rarely affects everyone in the same way. Before writing a design brief, identify the people who use a product, those who maintain it and those who may be affected without choosing to use it. For a proposed delivery system, that could include residents, couriers, reception staff and people who need step-free access. Each may face a different obstacle. A feature that saves one person time could shift work or cost onto another.
Observation and conversation can reveal details that a feature list misses. Ask people to walk through a recent instance of the task: what they were trying to do, where they paused and how they worked around the difficulty. Look for repeated patterns, but do not treat one account as a universal rule. It helps to separate what you observe from what you infer. “Several residents waited for staff to locate parcels” describes an observation; “Residents want an app” is an interpretation that still needs testing.
Name the need, the context and the constraints
A useful problem statement identifies a person or group, a task and the condition that makes it difficult. For example: “Residents who arrive after reception closes need a dependable way to collect packages because access to the current storage room is limited to staffed hours.” This is more focused than “Improve deliveries,” but it does not dictate a particular device. It gives a team something to investigate: how often the situation arises, what residents currently do and what a dependable handoff would require.
Constraints belong in the frame, not in a footnote. A building may have limited space, a modest maintenance budget, unreliable connectivity or rules about who can enter a storage area. Accessibility, privacy and the ability to recover when a system fails are also design considerations. Writing these down early prevents a polished concept from looking viable only because its operating conditions were ignored. Some constraints may be negotiable; others may be firm. Mark the difference rather than assuming.
Turn assumptions into questions
Every problem frame contains assumptions. Perhaps the team assumes residents are comfortable using a phone at pickup, that couriers can follow new instructions or that staff can manage a new device. List those assumptions and ask which ones could change the design if they proved false. This keeps early research focused and makes it less tempting to defend the first idea.
Low-effort tests can help before a team commits to a complex solution. A paper sign-in process might show whether a clearer handoff procedure reduces confusion. A sketch of a pickup interface can reveal whether its steps make sense without requiring a working product. These tests do not prove that a full system will succeed, but they can expose misunderstandings. If the building eventually considers a connected locker, it should also examine what happens during a power outage, a network failure or a forgotten access code.
Choose a solution only after comparing options
Once the problem is clear, generate several ways to address it, including a non-digital option. Compare them against the needs and constraints already named: Can people use them? Who maintains them? What happens when something goes wrong? A simple process change may be enough; in another setting, a physical redesign or connected device may offer a better fit. Advanced technology should be evaluated as an option, not treated as evidence that the problem has been understood.
Return to the problem statement as you learn. If testing shows that the main difficulty is not collection after hours but uncertainty about where a parcel was left, revise the frame. That is progress, not failure. A good design problem is specific enough to guide decisions and open enough to allow different answers. It helps a team build something that addresses everyday friction rather than merely demonstrating what technology can do.
