UX Research Findings Presentation Workflow in Figma

A UX research readout is not a prettier transcript. Product teams need to understand what was observed, how strong the evidence is, which decisions it affects, and what remains uncertain. When a deck mixes raw notes, interpretation, and recommendations without labels, a memorable quote can outweigh the actual pattern.

Pitchdeck lets researchers and designers build the presentation in Figma, present it in the browser, or export it to formats stakeholders already use. The harder—and more valuable—work is structuring the evidence so the deck supports a decision without overstating the study.

Write the decision question first

Before designing slides, state the question the study was meant to inform. For example: “Can new administrators invite a teammate without support?” is more useful than “Understand collaboration.” Then list the decisions that are in scope and the questions the study cannot answer.

Create a short study card containing:

• method and research dates;
• participant profile and recruitment constraints;
• tasks or prompts used;
• sample size;
• environment and prototype version;
• known limitations;
• owner of the underlying research repository.

This prevents the audience from treating five moderated sessions as a population survey or assuming that a prototype finding proves production behaviour.

Separate evidence, interpretation, and action

Use visibly different slide treatments for three layers:

1. Evidence: what participants did or said.
2. Interpretation: the team’s explanation of the pattern.
3. Decision or experiment: what should happen next.

A useful finding slide might show the task, an anonymised observation, the number of relevant sessions, a screenshot or flow fragment, the interpretation, and the decision it affects. Avoid confidence language that the method cannot support. “Four of six participants missed the secondary action in this prototype” is more precise than “Users cannot find the action.”

Keep contradictory evidence. A participant who succeeds through a different mental model may expose an alternative design direction rather than noise to delete.

Protect participant privacy in every output

Replace names with stable participant IDs and remove identifying details from quotes, screenshots, filenames, speaker notes, and exports. Crop browser chrome, notifications, account names, and personal data from recordings or stills. If consent only covers internal research, do not place the material in a broadly shared link.

Create two deck variants when necessary: a restricted evidence deck for the immediate team and a sanitised decision deck for wider circulation. Password-protected Pitchdeck links or PDF exports can help control access, but a password does not expand participant consent or replace the organisation’s retention policy.

The workflow differs from a customer advisory board deck. An advisory board presentation facilitates discussion with customers; a research readout explains evidence gathered under a defined study protocol.

Build a narrative around decisions

Do not organise the entire deck chronologically by interview. A stronger structure is:

• the decision and study boundaries;
• the current experience or hypothesis;
• the most consequential patterns;
• important exceptions and uncertainty;
• recommendations ranked by confidence and cost;
• open questions and next research;
• owners and decision dates.

Start each section with the conclusion in plain language. Follow with enough evidence for the audience to assess it. Put detailed transcripts, coded notes, and full task-level results in an appendix or research repository rather than shrinking them onto slides.

For each recommendation, say whether it is a direct usability fix, a product-policy question, a content change, or a hypothesis requiring further validation. Research can reveal a problem without uniquely determining the solution.

Design slides for live discussion and later reuse

Research decks often become asynchronous references. Give each finding a stable identifier, concise title, evidence source, and date. Use components for finding cards, confidence labels, participant markers, and recommendation states so the visual grammar remains consistent.

Check charts for readable labels and honest denominators. Avoid decorative percentages from tiny qualitative samples. If a journey map or flow is too dense for a slide, show the relevant segment and link to the source rather than making everything illegible.

Use speaker notes for facilitation cues and caveats that should travel with editable exports. Test the actual delivery route: browser presentation, PDF, PowerPoint, Keynote, or Google Slides. The presentation handoff checklist covers the format-level checks that become important when another team will edit the deck.

Run the meeting as a decision session

Send a short pre-read when stakeholders need time with the evidence. During the readout, pause after each major pattern and record disagreement as a question to resolve, not as a hidden edit made after the meeting.

End with a decision table:

• finding ID;
• proposed response;
• owner;
• decision maker;
• due date;
• confidence or evidence gap;
• follow-up research trigger.

Afterwards, publish a versioned deck and decision log. If a recommendation changes, preserve the original finding and add the new decision context instead of rewriting history.

Pitchdeck can make the readout polished, portable, and easy to present. It cannot decide whether the sample supports a claim or whether participant material is safe to share. A good research deck keeps those judgments visible—and gives the product team a concrete next move.

Read as Markdown · Related resource index · Site index for AI agents