--- title: 'Problem Statement' source: 'https://academia.sh/en/courses/user-experience/problem-definition' course: 'User Experience and Behavior Design' language: en updated: '2026-08-19T05:19:58+00:00' license: 'CC BY-SA 4.0' --- # Problem Statement Merging five lessons' findings into a single table; ranking by evidence strength and lost time, the parts of a problem statement, and preventing a solution from seeping into the statement. Data accumulated across five lessons: ten codes, three personas, seven tasks, one journey map, and one decision list. This accumulation is not yet a design job; to become something workable, it must be reduced to a single question: **which problem is being solved?** Skipping this question is the most common way research goes to waste. Findings are collected, written into a document, and then work moves straight to drawing screens. The drawn screen cannot say which finding it answers; whether it is good or bad cannot be tested, because what it must solve is never written down. This lesson first ranks the findings, then turns the finding at the top of the ranking into a problem statement. ## Converting Findings into a Common Unit Findings come from different methods and cannot be compared directly: one is "seven participants mentioned it," another is "forty-two failed attempts," a third is "four extra steps." A common unit is needed for comparison. The most defensible unit is the time the user pays. ```js // problem.mjs — ranking findings by evidence strength and lost time // Data from five lessons merged into a single table (data constructed for this lesson). // mentions: how many of the 12 interviews it appeared in. sources: data types // independently showing the finding. failedAttempts: failed-attempt count in the // four-week period. minutesPerFailure: observed average cost of a failed attempt (minutes). const FINDINGS = [ { name: "book not found on shelf", mentions: 7, sources: ["interview", "task", "journey"], failedAttempts: 42, minutesPerFailure: 4.8 }, { name: "search lost on return", mentions: 4, sources: ["interview", "task", "current state"], failedAttempts: 35, minutesPerFailure: 3.1 }, { name: "same-name record causes confusion", mentions: 7, sources: ["interview", "task"], failedAttempts: 16, minutesPerFailure: 1.6 }, { name: "renewal path not found", mentions: 2, sources: ["interview", "task"], failedAttempts: 18, minutesPerFailure: 2.4 }, { name: "refinements not visible", mentions: 3, sources: ["interview"], failedAttempts: 12, minutesPerFailure: 1.9 }, { name: "list unreadable on narrow screen", mentions: 2, sources: ["interview", "task"], failedAttempts: 9, minutesPerFailure: 2.7 }, ]; const PERIODS = 13; // 13 four-week periods per year for (const f of FINDINGS) f.lost = f.failedAttempts * f.minutesPerFailure; const total = FINDINGS.reduce((t, f) => t + f.lost, 0); console.log("finding mentions sources lost min/4 wks share annual hours"); for (const f of [...FINDINGS].sort((a, c) => c.lost - a.lost)) { console.log( `${f.name.padEnd(37)} ${String(f.mentions).padStart(6)} ${String(f.sources.length).padStart(8)} ` + `${f.lost.toFixed(1).padStart(15)} ${((f.lost / total) * 100).toFixed(1).padStart(4)}% ${((f.lost * PERIODS) / 60).toFixed(1).padStart(11)}` ); } console.log(`\ntotal: ${total.toFixed(1)} min / 4 wks = ${((total * PERIODS) / 60).toFixed(1)} hours / year`); // The two rankings do not agree const rankBy = (key) => [...FINDINGS].sort((a, b) => b[key] - a[key]).map((f) => f.name); const mentionRank = rankBy("mentions"), lostRank = rankBy("lost"); console.log("\nrank mentioned in interviews lost time"); for (let i = 0; i < FINDINGS.length; i++) { console.log(`${String(i + 1).padStart(4)} ${mentionRank[i].padEnd(37)} ${lostRank[i]}`); } // Cumulative share: how many findings account for most of the loss console.log("\ncumulative share"); let cumulative = 0; [...FINDINGS].sort((a, b) => b.lost - a.lost).forEach((f, i) => { cumulative += f.lost; console.log(` first ${i + 1} finding${i === 0 ? "" : "s"}: ${((cumulative / total) * 100).toFixed(1)}%`); }); // Evidence strength: a single-source finding is verified before entering the problem statement const weak = FINDINGS.filter((f) => f.sources.length < 2); console.log(`\nsingle-source finding: ${weak.map((f) => f.name).join(", ") || "none"} (verified before entering the problem statement)`); ``` ``` finding mentions sources lost min/4 wks share annual hours book not found on shelf 7 3 201.6 47.3% 43.7 search lost on return 4 3 108.5 25.5% 23.5 renewal path not found 2 2 43.2 10.1% 9.4 same-name record causes confusion 7 2 25.6 6.0% 5.5 list unreadable on narrow screen 2 2 24.3 5.7% 5.3 refinements not visible 3 1 22.8 5.4% 4.9 total: 426.0 min / 4 wks = 92.3 hours / year rank mentioned in interviews lost time 1 book not found on shelf book not found on shelf 2 same-name record causes confusion search lost on return 3 search lost on return renewal path not found 4 refinements not visible same-name record causes confusion 5 renewal path not found list unreadable on narrow screen 6 list unreadable on narrow screen refinements not visible cumulative share first 1 finding: 47.3% first 2 findings: 72.8% first 3 findings: 82.9% first 4 findings: 88.9% first 5 findings: 94.6% first 6 findings: 100.0% single-source finding: refinements not visible (verified before entering the problem statement) ``` Three things can be read from this. **Mentions are not cost.** "Same-name record causes confusion" was mentioned seven times in interviews and ranks second by mentions, fourth by lost time. The reason is that its cost is low: the user who opens the wrong record notices the mistake within a minute and a half and goes back. Phenomena mentioned often in interviews are the most annoying, not the most expensive. Annoyance and cost are separate metrics, and both are written down, but they are not conflated. **Loss is concentrated.** The first two findings account for 72.8% of the total loss, the first three for 82.9%. Trying to fix all six findings means four times the work of fixing the first two, and it adds only a quarter more of the gain. This is what the priority decision rests on. **Evidence strength is a separate column.** The "refinements not visible" finding comes only from interviews; it has no independent counterpart in either the task data or the decision list. A single-source finding need not be wrong, but it is verified with a second method before it enters the problem statement. Writing a low-evidence finding into the statement lends research's authority to an unverified claim. The annual-hours column is an estimate, and its limit must be written down explicitly: it is a four-week observation multiplied by thirteen periods, and it does not account for seasonal variation. It assumes that attempts per period stay the same outside the observed period too. Left unstated, this assumption makes the number read like a measurement rather than a product. ## The Parts of a Problem Statement The finding at the top of the ranking is not a problem — it is an observation. A problem statement carries five parts. - **Who.** Which persona is affected. Not "users" — which of the three personas built in the second lesson. - **Context.** Which task, which stage, and under what condition the problem occurs. - **Fact.** What does not happen. It is written as an observable shortfall, not as a request. - **Evidence.** With which measurement and which method. The number and the source are written together. - **Criterion.** If the problem counts as solved, what will the number become. A statement with no criterion can never close. The first finding's statement is written as follows: > Users in the Known-Record Searcher and Narrow-Screen Viewer personas cannot find the > book once they reach the shelf with the shelf code. Nineteen of the fifty-eight users > who enter the shelf-search stage give up at that stage (32.8%); 201.6 person-minutes > are spent with no result in a four-week period. The finding is seen independently in > three sources: seven of twelve interviews, forty-two failed attempts in the task data, > and the drop-off point in the journey map. The problem counts as solved once the > give-up rate at the shelf-search stage falls below 15%. No interface element appears in this text. How the shelf code will be shown, whether a map is added, whether a floor plan needs to be placed — all of this falls outside the statement; all are candidates that could satisfy it, and a choice will be made among them. ## Ways a Statement Breaks Down Three breakdowns are common, and all three make the statement untestable. **A solution seeping into the statement.** "The record detail is missing a shelf map" is not a problem statement — it is a chosen solution. The sign of the leak is this: if the statement names an interface element, the design decision has already been made, and research is being used to justify it. The distinguishing criterion is the same one set in the third lesson — at least two different solutions must be derivable from the statement. **Blaming the user.** The sentence "users do not read the shelf code correctly" writes the fact as the user's fault and puts the design out of scope. When the same fact is written as "the shelf code is not presented in a form that can be matched while standing at the shelf," the solution space reopens. The rule is this: **a problem statement describes what the interface fails to do, not what the user fails to do.** **A missing criterion.** A statement with no criterion never closes; every new design counts as "better," and none counts as enough. When the criterion is chosen, a reachable target is set; aiming to bring a 32.8% rate down to zero means ignoring the cases where the book really is checked out. ## The Ethical Burden of a Problem Statement The statement is research's public-facing side, and it carries every obligation the data has. **The statement does not show the participant.** The numbers that appear in the text must be aggregated. The sentence "the participant who is a night-shift attendant cannot find it at the shelf" points to one person; this information stays not in the statement but in the deleted raw note. **Those left out of scope are written down.** If the sample has no participant who uses a screen reader, the statement says nothing about that group's problem. Silence is not absence; a line reading "this group was not measured" is written under the statement. The rule set for personas in the second lesson is repeated here at the level of the statement. **A number's source stays traceable.** Every number in the statement must be traceable back to which method and which period it came from. A number whose source cannot be shown is removed from the statement; a number with no source is decoration, not evidence. ## Summary - Findings from different methods cannot be compared until they are converted into a common unit — the time the user pays. - The finding mentioned most in interviews is not the most expensive finding; in the sample data, one finding ranked second by mentions and fourth by cost. - Loss is concentrated: in the sample data, the first two findings accounted for 72.8% of the total, and the priority decision rests on this concentration. - Evidence strength is a separate column; a single-source finding is verified with a second method before it enters the problem statement. - A problem statement carries the parts who, context, fact, evidence, and criterion; a statement with no criterion never closes, and at least two different solutions must be derivable from it. - The statement describes what the interface fails to do, not what the user fails to do; it does not show the participant, and it explicitly writes down groups that were not measured. ## Next Step The problem is defined: the give-up rate at the shelf-search stage will be reduced, and the Subject Browser's comparison path will be shortened. The solution space is still open, and the first question is not the screens themselves but the structure between them. The catalog interface carries thousands of records, dozens of subjects, and a handful of operations; which headings these get grouped under is not a matter of style. The next lesson shows how structure is derived from content: extracting a content inventory, collecting card-sorting data, and building a similarity matrix from the pattern of how participants group items together.