Problem Prioritisation and Delivery Triage: Identifying What Matters in Product Design

Design as Problem Resolution

"Design is not just what it looks like and feels like. Design is how it works." -- Steve Jobs

Design is a discipline with a purpose: to find solutions to problems people face. It is not a visual exercise -- it is a systematic approach to making things work. Products that excel at identifying real problems earn user trust and adoption. Users accept a product that demonstrates it understands their challenges.

The fundamental delivery challenge is the ratio of problems to available design resources. Problems proliferate at every stage of development, but the capacity to address them is finite. How does a team prioritise? How does it determine whether a selected problem addresses the genuine pain point? How does it validate that the chosen problems justify the time and resource investment?

The Aesthetics Question

Some practitioners avoid discussing visual quality, believing it dilutes the functional purpose of design. Even when they create outstanding work, the mention of aesthetics creates discomfort. The reasoning: emphasising visual appeal distances the team from core design challenges.

There are valid perspectives on both sides. A purely functional approach -- clean structure, efficient interaction, minimal visual investment -- can deliver satisfactory products. But the aesthetic-usability effect demonstrates that users perceive visually coherent products as more usable. The resolution is not choosing between function and form, but recognising that when everything works correctly and makes sense, the result is inherently attractive.

Understanding Problem Taxonomy

Problems in product design are the gaps between the current state and the desired state, where the desired state represents the design that functions optimally. These are local problems -- distinct from the global, strategic challenges communicated to the client.

Local problems are well-defined: a manufacturing cost driven up by a particular component shape, information overload on a single screen, insufficient contrast preventing brand element visibility. For well-defined problems, analysis and synthesis produce definitive solutions. The engineering approach works: state the problem, search for a solution, validate against true/false criteria.

Design problems, however, are rarely so clean.

Engineering Methodology vs. Design Methodology

Engineering approach:

• ▶State the problem precisely
• ▶Search for a suitable solution
• ▶Treat the problem as well-defined
• ▶Decompose into manageable parts
• ▶Apply analytical and mathematical reasoning
• ▶Solutions are true or false

Design approach:

• ▶Accept ambiguous, complex problems
• ▶Interpret the case from multiple angles
• ▶Explore the possibility space
• ▶Iterate through candidate solutions
• ▶Use sketching and prototyping as reasoning tools
• ▶Solutions are good or bad, better or worse -- never definitively true or false

These approaches are complementary. Engineering handles the well-defined; design handles the ambiguous. Most product problems contain elements of both.

The Triage Framework

Signal One: Frustration Intensity

Ask users to enumerate their problems and they will produce an extensive list. But are these real problems? Real problems generate emotional responses. Frustration is the diagnostic signal.

Frustration manifests in recognisable patterns:

• ▶Persistent complaints about the same issue
• ▶Reluctant acceptance after excessive effort
• ▶Perpetual deferral on the to-do list
• ▶Seeking external opinions and recommendations

If users are not genuinely frustrated by an issue, it likely does not represent a real problem -- or they have not yet recognised it as one. Do not manufacture problems; identify existing sources of friction.

Sometimes users are frustrated but cannot articulate the root cause. If they could identify the precise problem, they would likely have found a solution themselves. This is where structured research methods -- the Five Whys, contextual inquiry, journey mapping -- extract the underlying issue.

Signal Two: Action Orientation

Frustration indicates severity, but not all frustrating problems prompt action. Some issues are accepted as permanent inconveniences. The critical question is whether users are actively attempting to resolve the problem.

Diagnostic indicators:

• ▶Are they improvising solutions from existing tools?
• ▶Have they initiated a project to address the issue?
• ▶Are they actively collecting information about potential solutions?
• ▶Have they begun evaluating software that targets this problem area?

Users readily enumerate problems but rarely allocate time to solve them. When they do take action, the problem has crossed the threshold from inconvenience to priority.

Signal Three: Financial Commitment

Action demonstrates seriousness, but financial commitment confirms it. When users spend money to address a problem, they have validated its severity through the most reliable signal available: resource allocation.

Software investment: If users purchase existing software to address the problem, the problem is validated. If they are dissatisfied with that software, the opportunity is confirmed.

Consultant engagement: When users hire external expertise, they acknowledge that the problem exceeds their internal capability. This represents both validated severity and a clearly defined market need.

Custom development investment: When users build internal tools to address the problem, existing solutions are insufficient but the problem justifies investment. This signals both opportunity and competitive advantage for a superior solution.

Requirements as Problem Models

It is standard practice to define requirements before beginning design work. But requirements are models of the problem, not the problem itself. Product design frequently encounters problems that are not clearly stated, not fully understood, or not expressible in concrete terms.

A product that generates frustration during use signals a problem. But the frustration may not specify what is wrong. The wanted state may not be articulable. The gap between current and desired state may involve incommensurable dimensions.

Design solutions along the way are not definitive. They are good or bad, better or worse, but never true or false. The endpoint is a state of appropriate equilibrium -- a satisficing resolution rather than an optimal one.

Prioritisation Discipline

The ability to prioritise is the defining capability of effective product teams. Prioritisation applies to the people being designed for, the features being incorporated, the elements on a page, and the problems being addressed.

Prioritisation criteria, in order of diagnostic reliability:

1. Are users frustrated? Emotional intensity validates problem severity
2. Are users taking action? Behavioural commitment validates problem priority
3. Are users spending money? Financial commitment validates market opportunity

Focus design effort on problems that satisfy all three criteria. These are the problems whose solutions will be valued, adopted, and paid for.

The Design Discipline

Design is a problem-resolution activity in which the greater portion of work is identifying the right problems and a smaller portion is solving them. Designers must decompose problems systematically, recognising that structuring the problem space is continuous work -- not a one-time activity at project inception.

Problem and solution emerge together through iteration. Design is used for problem-solving, but it cannot be reduced to problem-solving alone. By constraining design exclusively to known problems, teams miss the opportunities that emerge from the design process itself. The discipline is finding the equilibrium between resolving identified challenges and capitalising on emergent opportunities.