Compiling Structured Results for Analysis

After conducting usability testing sessions, the raw material you have collected — spreadsheets of timing data, pages of observation notes, video recordings, think-aloud transcripts, and questionnaire scores — represents potential insight, not yet knowledge. The work of converting that material into knowledge happens during analysis and reporting. This process demands discipline: a systematic approach to organizing data, an honest eye for distinguishing genuine usability problems from statistical noise, and the craft to communicate findings so clearly that stakeholders can act on them with confidence. Each stage of this process builds on the last, and shortcuts at any stage undermine the credibility of everything that follows.

Organizing Raw Data After Testing

The foundation of trustworthy analysis is a clean, complete, and well-organized data archive. Before any interpretation begins, every piece of collected data must be located, labeled, and stored in a structure that supports retrieval and cross-referencing. Disorganized data leads directly to errors in analysis — missed observations, mislabeled participants, and conclusions drawn from incomplete evidence.

All quantitative data — task completion outcomes, time-on-task measurements, error counts, and questionnaire scores — should be entered into a single shared spreadsheet. The spreadsheet should be organized so that each row represents one participant and each column represents one measured variable. This layout, sometimes called a tidy data format, makes it straightforward to calculate averages, sort by task, filter by participant group, and generate charts. An example structure might look like this:

Notice that when a participant did not complete a task, time-on-task is left blank with a dash rather than filled with a zero or an estimate. A zero would falsely inflate the appearance of fast performance; a dash clearly signals that the value is absent because the task was not completed. This kind of precision in data entry prevents subtle distortions during later calculations.

Qualitative data requires an equally deliberate approach. Observation notes taken during sessions should be compiled into a single document and labeled with both the participant ID and the session date before any editing or synthesis begins. If multiple team members took notes simultaneously during the same session, their records should be merged under the same label and distinguished by observer initials rather than overwritten. Transcripts of think-aloud audio or video should follow the same convention. A file named something like P04_2024-03-12_Transcript_JR.docx tells you immediately who was observed, when, and who produced the document.

Video and audio recordings must be backed up to at least two separate locations — typically a team shared drive and a local hard drive — and each file should include a timestamp that corresponds to a session log. This timestamping is particularly valuable during analysis when a team member wants to locate the moment a specific incident occurred without scrubbing through an entire recording. A session log entry like "P06 encountered the checkout error at approximately 14:32 into the recording" saves significant time and ensures that evidence can be independently verified.

Perhaps the single most important data management rule is this: never overwrite original files. All raw data files — unedited notes, original spreadsheet entries, unprocessed recordings — must be preserved exactly as they were created during testing. Any processed version (a cleaned spreadsheet, an annotated transcript, an edited highlight reel) should be saved as a new file in a clearly labeled folder. This discipline protects against accidental corruption of evidence and allows the team to return to primary sources at any point if a question arises about whether an analysis step introduced an error.

Identifying Usability Problems and Patterns

With data organized, the team can begin the analytical work of identifying genuine usability problems. The central challenge here is distinguishing signal from noise — separating issues that reflect real weaknesses in the design from observations that reflect individual differences, momentary confusion, or simple unfamiliarity with the task.

The most reliable indicator of a genuine usability problem is frequency across participants. If seven out of eight participants struggled to locate the filter controls on a search results page, that pattern is compelling evidence of a design problem regardless of what any individual participant said about it. Conversely, if only one participant missed a feature that every other participant found instantly, the observation may reflect something specific to that individual — their prior experience, their testing environment, or even a moment of distraction — rather than a flaw in the interface. This does not mean single-participant observations should be discarded; they should be noted and examined more closely, but they require additional corroborating evidence before being reported as usability problems.

Cross-referencing quantitative metrics with qualitative observations is the analytical technique that transforms numbers and notes into meaningful findings. Suppose the time-on-task data shows that participants spent an average of 3.5 minutes on Task 3, compared to under 90 seconds on the other three tasks. That number alone raises a flag, but it doesn't explain what happened. When you review the observation notes alongside those timing values, you might find that six of the eight participants navigated away from the correct page at least once while attempting Task 3 — a behavioral observation that explains the time spike and points directly to the navigational element that needs redesign. Quantitative data identifies where problems are occurring; qualitative data illuminates why.

Severity ratings provide a structured way to prioritize findings. A usability problem that caused eight out of eight participants to fail a critical task is categorically more urgent than a problem that caused mild confusion for two participants on an optional feature. A commonly used severity framework considers two dimensions: frequency (how many participants encountered the issue) and impact (how severely it affected task completion, including whether it caused task failure, significant delay, or minor frustration). Multiplying or combining these dimensions produces a severity score that helps the team and stakeholders understand which problems should be addressed first. A simple version of such a framework might look like this:

Critically, not every observation made during testing is a usability problem. When a participant comments that they prefer a different color scheme, or that they personally would rather the navigation be organized differently from convention, that is a preference — and preferences vary widely across individuals. A usability problem has a more specific definition: it is a characteristic of the design that prevents or impairs users from accomplishing their goals effectively and efficiently. Conflating personal preferences with usability problems leads to reports that are difficult to act on and that may even push design changes in the wrong direction. Analysts must maintain this distinction consistently throughout the synthesis process.

Structuring the Results Report

A usability test results report is a formal document, and its structure determines whether findings are accessible and actionable or merely comprehensive. A well-structured report does not force readers to dig through dense methodology to find out what they should do; it is organized to serve different audiences — from executives who need a quick summary to developers who need precise behavioral details.

The executive summary is the most strategically important section of the report because it is the section that the most influential readers are most likely to actually read. It should be written last, after all other sections are complete, and it should do three things: state the purpose of the study in one or two sentences, identify the most critical findings in plain language, and summarize the highest-priority recommendations. It should never exceed one page. An executive summary that buries its most important finding in the fourth paragraph has failed its purpose.

The study overview section serves as the methodological record. It documents the research questions the study was designed to answer, the characteristics of the participant sample (age range, relevant experience, how they were recruited), the tasks participants were asked to complete, the prototype or product version tested, the testing environment and any tools used, and the dates sessions were conducted. This section is the audit trail that allows a reader — or a future team member reviewing the report months later — to evaluate the generalizability of the findings and to replicate the study if needed. Precision matters here: rather than writing "participants were experienced users," write "participants had a minimum of two years of experience with e-commerce platforms and made at least four online purchases per month."

The findings sections form the body of the report. A principle that improves the intellectual honesty of any research report is this: present evidence before conclusions. Rather than opening a finding with the conclusion — "The checkout flow is confusing" — open it with the evidence — "Six of eight participants attempted to edit their cart contents after reaching the payment screen, and five of those six did not find their way back to the cart successfully." The conclusion follows from the evidence, and the reader can evaluate for themselves whether the evidence warrants the conclusion. This approach builds trust in the report's credibility because it shows rather than simply asserts.

The recommendations section translates findings into design guidance. Each recommendation should be specific enough that a designer or developer can implement it without further clarification, and it should be explicitly linked to the finding that supports it. A vague recommendation like "improve the navigation" is not actionable. A specific recommendation like "Add a persistent 'Back to Cart' link at the top of the payment screen, directly beneath the progress indicator, to address the six participants who lost their path back to the cart during checkout" gives the design team a precise target and the evidence that motivates it. The link between finding and recommendation must be traceable — ideally with a reference to the finding number or section — so that stakeholders can understand why each change is being proposed.

Presenting Quantitative Findings

Quantitative data gives a usability report its empirical backbone. Numbers communicate precision and allow comparisons across tasks, participant groups, and benchmark standards in ways that prose alone cannot. But numbers without context mislead as easily as they inform, so every quantitative finding requires careful framing.

Task completion rate tables should always report both the raw count and the percentage so that readers can assess the absolute size of the evidence as well as the proportion. Reporting only that "75% of participants completed Task 2" obscures whether that percentage comes from 3 out of 4 participants or 30 out of 40. The table below illustrates a well-formed task completion summary:

Time-on-task data should be reported with both the mean and the range of observed values. The mean alone obscures individual variation that is often diagnostically meaningful. If the mean time-on-task for a given task is 2 minutes but the range is 45 seconds to 8 minutes, that spread reveals that some participants flew through the task while others struggled dramatically — a pattern that suggests the task has two distinct modes of interaction and may warrant further investigation. Standard deviation can be added when the team has a larger sample and wants to communicate variability more precisely, but for typical moderated usability studies with small samples (5–12 participants), mean and range are generally sufficient and more readily interpretable by non-statistician stakeholders.

When reporting scores from standardized questionnaires such as the System Usability Scale (SUS), scores become most meaningful when placed alongside published benchmarks. A SUS score of 68 is the published average across a large corpus of products, and a score above 80.3 is associated with adjective ratings of "excellent." Without these reference points, a stakeholder reading a SUS score of 71 has no way to judge whether that represents a strong or weak result. The report should make these comparisons explicit:

Every chart, graph, and data table in the report must carry a clear title and an explanatory caption. The caption should be written so that a reader who encountered the visual element in isolation — without reading the surrounding paragraphs — could still understand what is being shown and why it matters. A caption like "Table 3. Task completion rates across all four tasks. Task 3 (completing checkout with a promo code) had the lowest completion rate at 38%, substantially below the team's target of 80%." does the work of connecting the visual to the finding. Visuals without captions force the reader to do interpretive work that the author should have done, and in fast-reading contexts like executive briefings, captionless visuals are frequently misread or simply skipped.

Presenting Qualitative Findings and Recommendations

Qualitative findings give the numbers human context. They reveal the reasoning behind participant behavior, surface expectations the design failed to meet, and provide the narrative texture that makes a report persuasive rather than merely informative. The challenge with qualitative data is that it is inherently voluminous and variable — dozens of pages of notes and transcripts must be synthesized into findings that are both accurate and concise.

The most effective organizational approach is to group qualitative findings into themed sections that correspond to major problem areas. Rather than presenting findings chronologically session by session or participant by participant (which reads like a diary rather than an analysis), the report should cluster related observations under a shared label that names the problem area. For example, themes might be labeled: Navigation and Wayfinding, Form Completion Errors, Mental Model Mismatches, Error Recovery, and Positive Interactions Worth Preserving. This thematic structure allows a reader to jump directly to the area most relevant to their work — a navigation designer can go straight to the wayfinding section — and it communicates that the team has synthesized the data rather than merely transcribed it.

Direct participant quotes serve as primary evidence for attitudinal findings and reported expectations. A quote captures the participant's own words and carries a kind of authenticity that paraphrase cannot replicate. When a report states that "participants found the confirmation step confusing," that is an interpretation. When it states that "participants found the confirmation step confusing" and then cites a participant saying "I wasn't sure if I had actually placed the order or just saved a draft — there was no obvious confirmation" (P05), the interpretation is grounded in evidence that the reader can evaluate. Quotes should be selected because they are representative — meaning they express something that multiple participants communicated in some form — not because they are colorful or extreme. Using an outlier quote as if it represents the group is a form of misrepresentation.

Critical incidents — moments when something went significantly wrong during a session — deserve especially careful description. A critical incident should be narrated with enough specificity that a reader who was not present can form a clear mental picture of exactly what happened: what the participant was trying to do, what interface element they interacted with, what the system did in response, and what the consequence was for task completion. Compare these two versions of the same incident:

• Vague version: "One participant had trouble with the promo code field."
• Specific version: "P03 typed the promo code 'SAVE20' into the promo field and clicked Apply. The field cleared and displayed the message 'Code not found' in gray text at 11pt below the field. P03 did not see the error message, waited approximately 15 seconds, and then clicked 'Place Order' without the discount applied. After the order confirmation screen appeared, P03 said, 'Wait, did my discount go through? I don't see it anywhere.' The promo code error message was below the fold on P03's screen resolution and was not visible without scrolling."

The specific version gives designers everything they need to understand and fix the problem: the error message's location, its visual weight, the viewport issue, and the downstream consequence of the failure. Vague descriptions force the development team to conduct their own investigation to reproduce a problem they should have been handed fully documented.

Each design recommendation should be written as a specific, implementable action directly tied to a documented finding. Recommendations that float free of evidence feel like opinions; recommendations anchored to findings feel like conclusions. A useful structural template for writing recommendations is: action verb + specific design element + rationale linked to finding. For example:

• Finding: Six of eight participants failed to notice the promo code error message because it appeared below the fold and in low-contrast gray text (see Finding 3.2).
• Recommendation: Reposition the promo code error message to appear directly above the Apply button in high-contrast red text (minimum 4.5:1 contrast ratio), and scroll the viewport to bring the message into view automatically when an error occurs.

This structure means that every stakeholder reading the recommendation — whether a visual designer, a front-end developer, or a product manager — receives both the what and the why in a single entry. Recommendations written this way can be directly transferred to a design backlog or sprint planning document without further translation, which is the ultimate measure of a well-constructed usability report.

Taken together, these practices — rigorous data organization, disciplined pattern identification, structured reporting, evidence-led quantitative presentation, and specific qualitative synthesis — transform raw session data into a document that serves both as an honest record of what was observed and as a practical guide to what should change. A results report built on these foundations gives design teams and stakeholders alike the confidence to act.

Once a usability test session ends, you are left with a messy pile of evidence: session notes, observer tallies, recordings, think-aloud quotes, task timings, and error counts. Compiling structured results is the work of turning that raw material into something a design team can act on. It involves organizing data by participant and by task, grouping individual observations into recurring usability problems, rating those problems by severity, and then assembling a report that pairs numbers with illustrative evidence and concrete recommendations.

This matters in CEN3722 because a usability test only has value if its findings reach the people who build the interface in a form they can use. A report that lists forty unsorted observations with no prioritization gives a team no idea where to start. A report that states results more confidently than the data warrants can push a team toward the wrong redesign. Your job is to be both useful and honest: clear about what you found, clear about how strong the evidence is, and clear about what should change.

The three videos below come from Nielsen Norman Group, a long-established usability consultancy. As you watch, focus on three things: how severity criteria help you decide what to report first, how to describe findings truthfully when sample sizes are small, and how framing and context affect whether your audience actually engages with your recommendations. Take notes you can apply directly to your team's results document.

NNgroup · 3:04 · 9,970 views · 4y ago · captions — Watch on YouTube

About this video

This short video explains how to assign severity ratings to usability problems found during usability studies or heuristic evaluation, using a small set of criteria rather than gut feeling. Expect discussion of factors such as how often a problem occurs, how badly it blocks users, and how persistent it is across a task. The result is a prioritized list rather than an undifferentiated set of observations.

Why this video

Severity rating is the bridge between raw observations and an actionable report, which makes this directly relevant to identifying usability problems and patterns and to structuring the results document around priority.

NNgroup · 3:16 · 5,789 views · 2y ago · captions — Watch on YouTube

About this video

This video addresses how to present research results to stakeholders truthfully and responsibly, including how to avoid overstating what a small study can support. It is likely to touch on careful use of numbers and percentages, appropriate hedging, and being transparent about method and sample. The emphasis is on communicating findings without distorting them.

Why this video

It speaks directly to presenting quantitative findings honestly, a common failure point when student teams report percentages from five or six participants.

NNgroup · 4:17 · 8,942 views · 3y ago · captions — Watch on YouTube

About this video

This video covers how to set the stage with stakeholders before presenting UX design or research work so that the feedback you receive is useful. It discusses providing context, framing what kind of input you are seeking, and structuring the conversation around the goals of the work. The focus is on the presentation setup rather than the findings themselves.

Why this video

Presenting qualitative findings and recommendations is a conversation, not just a document, and this video shows how framing and context shape whether your recommendations get a serious hearing.

These videos extend the module's data collection work into the reporting stage. Having facilitated sessions (MO1) and gathered both quantitative measures such as task completion, errors, and time-on-task alongside qualitative think-aloud observations (MO2), students need a disciplined way to compile both kinds of evidence into one structured document. The severity rating video supplies criteria for turning scattered observations into prioritized problems; the responsible presentation video reinforces the MO3 concern for data integrity by showing how to report findings without overstating what the data supports; and the feedback video helps students deliver recommendations in a way that stakeholders can engage with productively.

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.