A UX report for clients from an agency or freelancer has one job: to get a decision on what changes on the website next month. Heatmaps and session recordings supply the material, but the material is not the report. A client who receives a gallery of screenshots and a vague "the form could be improved" does not know what to believe or what to approve. The structure below takes you from an observation to a task with evidence.
We assume the analysis is already done: you know which visits to watch, how to read a heatmap and how to rank fixes. The examples use a fictional physiotherapy practice with an appointment enquiry form and are not results from a real project.
A UX report for clients in six parts
A monthly report reads best from decisions down to detail. On the first page the client sees what matters most and what you need from them. Put the method and raw numbers in an appendix: the decision-maker rarely reads them, and a technical contact will ask for the detail anyway.
Scroll the table sideways to see all columns.
| Part | Client question | What to include |
|---|---|---|
| Summary | What matters most this month? | 3–5 problems and the decisions needed |
| Scope and limits | What are the conclusions based on? | Period, pages, devices, number of visits, gaps |
| Problem cards | How do you know it is a problem? | Observation, hypothesis, recommendation, check |
| Evidence | Can I see it? | Links to recordings and the heatmap view |
| Tasks | What happens after approval? | Task, owner, date of the check |
| Effect of earlier changes | Did last month's fixes work? | What was checked and with what result |
The last part closes the loop from the previous month. If a change approved earlier has not been checked yet, say so plainly instead of leaving the item out. This report is not the same as a routine progress update: that is covered in the guide to client project status updates, while here the subject is what user behaviour tells you.
Summary: three to five problems
The summary fits on one page. Describe each problem in one sentence about behaviour, one about the possible cause and one about what you need from the client. Five items is the ceiling, because with ten the client cannot tell the important from the minor. Move other observations to a "Watching" section without recommendations. Set the order beforehand, for example with the method from the guide on how to prioritise website fixes with ICE scores.
On phones, some people open the enquiry form but never reach the send button (9 of the 14 visits we watched that include this step). Possible cause: the date picker covers the button. We ask for approval to replace the date picker with a list of available slots; we will check the effect in the next report.
Do not add an expected rise in conversion or revenue to the summary. Without a measurement, that number is a promise the client will hold you to next month. Name the behaviour that should disappear and how you will check it instead.
Data scope and limits before conclusions
The client should know what the conclusions rest on before reading the recommendations.
- Analysis period and the dates of significant site changes within it.
- Pages and journey steps included in the review.
- Devices, split into phone and desktop.
- Number of recordings watched and how they were selected.
- Heatmap status: ready or still collecting data.
- What the report does not cover, and why.
In Meetlead, a heatmap is marked as ready from 50 views of a given page on a given device; before that, present it as collecting data, not as evidence. Whether that sample supports a specific conclusion is discussed in the article on how much traffic a heatmap needs. For recordings, state that they are a selected sample, not every visit. "9 of 14 watched" is more honest than "most users".
Problem card: observation, hypothesis, recommendation, check
Each problem from the summary gets its own card in the report, with four fields in a fixed order. The observation describes what you can see, without interpretation. The hypothesis names a possible cause and is clearly marked as an assumption. The recommendation is one concrete change for approval. The check states which behaviour you will compare after release, and under what conditions.
- Observation
9 of the 14 mobile visits watched with the form open end before the send button
- Hypothesis
The date picker hides the button on smaller screens
- Recommendation
Replace the date picker with a list of the next available slots
- Check
Same pages and devices over a comparable period after release
Separating observation from hypothesis matters in the conversation. The client may disagree with the cause, but it is hard to dispute behaviour visible in a recording. The discussion then turns to how to test the hypothesis rather than who is right. The guide to analysing session recordings explains how to watch them so the observation holds up, and the article on how to read heatmaps covers the maps.
The GOV.UK Service Manual advises writing down exactly what was seen or heard and forming conclusions in a separate step; among the outputs of analysis it lists new user stories for the product backlog. The guidance concerns user research in government teams, not agency reports built on heatmaps: GOV.UK: analyse a research session.
A link to a specific recording instead of a screenshot
A screenshot shows a single moment and is easy to read in different ways. A recording shows the sequence: what the person did before the problem and after it. On each card, add one to three recording links and note the minute to start watching from.
In Meetlead, you can share a recording through a public link valid for 24 hours, 7 days or 30 days. The link never outlives the recording itself, whose retention depends on the plan, and the chat widget content is removed from playback. In the player you can add a comment pinned to a moment in the recording, so the team can return to the right point. Copy the observation into the report as well, because the link stops working once it expires.
The recordings come from the client's website, so agree with the client who should receive the links, and do not pass them on. Choose the shortest validity that covers the approval of the report. Numbers from Analytics can be attached from a CSV or XLSX export, and a saved report can be emailed monthly as an XLSX file to the addresses you choose. Those figures do not replace the problem cards.
The GOV.UK Service Manual suggests sharing research findings through short video clips of one or two minutes and participant quotes, among other methods. It is advice for delivery teams, not proof that a recording will convince every client: GOV.UK: sharing user research findings.
An approved recommendation becomes a task with evidence
- Collect the client's decisions.For each card, record approved, rejected or needs clarification, with the date and the person who decided.
- Create one task per recommendation.The title describes the change; the description carries the observation, hypothesis and check copied from the card.
- Link the task to the evidence.Add a link to the recording that shows the problem, and to the ticket if the client asked about it in chat.
- Schedule the check.Note the release date, then compare behaviour under the same conditions in the next report.
In Meetlead Projects, a task can be linked to a recording, a ticket and other tasks, and it has a priority, an owner and comments with a change history. Projects is a separate app, available depending on your plan. Meetlead does not write the report for you or turn recommendations into tasks automatically: you create the tasks after the client decides. The guide to task acceptance criteria helps you define when a task is done.
Keep rejected recommendations in the report too, with a short reason. Turn items that need clarification into a task to gather more evidence, not into a fix.
Questions about UX reports for clients
How often should you send a UX report to a client? For ongoing website care, once a month is usually enough, because a shorter period often does not provide enough visits to compare after changes. With low traffic, consider every two months and say so in the data scope.
What if there are no significant problems this month? Say so in the summary and show the results of checking earlier changes. Do not pad the list with weak observations just to reach five items.
