UX Recommendations Your Team Can Build
Findings only help if someone can act on them. We turn research and audit results, ours or another team's, into a ranked list of specific changes that designers and developers can pick up without a follow-up meeting.
Short answer
The recommendations service converts findings into a prioritized backlog. Each item states the problem, the evidence, the proposed change, acceptance criteria, an effort estimate and how to check the result. We can work from our own research or from reports your team already has.
On this page
Why research reports stall
A research report can be accurate and still go nowhere. Findings written as observations, such as "participants were confused by the plan names", leave the team to work out what to change, who should change it and how to know it worked. Weeks later, the report is still in a folder.
Our recommendations close that gap. Each finding becomes one or more changes written in the language of the people who will build them.
What each recommendation contains
| Field | Purpose |
|---|---|
| Problem | What visitors struggle with, in one or two sentences |
| Evidence | Where the finding came from: sessions, audit, analytics or support logs |
| Proposed change | The specific change, with a sketch or example where helpful |
| Acceptance criteria | Conditions that tell the team the change is done |
| Effort | A rough size agreed with your team, such as small, medium or large |
| Impact | How much the change should help the task, with reasoning |
| Check | How to confirm the change worked, from a quick retest to a controlled experiment |
The acceptance criteria do the most practical work, because they turn a design idea into something a developer can finish and a tester can verify.
How we rank the list
Ranking uses impact and effort together, the same logic as our free improvement planner. High-impact, low-effort changes go first. High-impact, high-effort changes become projects with their own scope. Low-impact items are grouped so they can be fixed alongside related work.
Evidence strength also matters. A change backed by several sessions ranks above one that rests on a single expert observation. Where a recommendation rests mainly on judgment, we say so and suggest a quick way to check it before building.
Working from someone else's research
You do not need to have used our other services. If you already have a research report, an audit from another vendor, a list of support complaints or survey results, we can review that material and turn it into a ranked backlog. We note where the source material is thin and where a small amount of new research would make a recommendation more reliable.
Working with your team
We hold a working session with design, development and product leads to agree effort estimates and dependencies. Estimates from the people who will do the work are far more reliable than ours. The final backlog can be delivered as a spreadsheet, as a document, or formatted for import into your project tracker.
What this service does not include
We do not produce final visual designs or write production code. Sketches and examples in the recommendations illustrate intent; your designers decide the final form. We also do not predict revenue effects for individual changes, because no honest method allows that before the change is live.
Timeline
We plan for one to two weeks after findings are available, including the working session with your team.
An example of a finished recommendation
Here is a fictional recommendation, written the way it would appear in a backlog. Problem: visitors comparing plans cannot tell what separates the two middle plans. Evidence: in an illustrative study, three of five participants asked aloud what the difference was. Proposed change: add a one-line summary under each plan name stating who it is for, and move the feature comparison table directly below the plan cards. Acceptance criteria: each plan card shows a summary of no more than twelve words, and the comparison table is visible without leaving the page. Effort: small. Check: a five-person retest on the same task.
Recommendation questions
What format will the backlog be in?
A spreadsheet by default, with one row per recommendation. We can also format it for import into common project trackers, or deliver it as a document if your team prefers.
How detailed are the proposed changes?
Detailed enough to act on: specific wording for labels and messages, the order of fields, which element to move and where. Visual design details are left to your designers.
Can you review a backlog we already wrote?
Yes. We can check an existing backlog against the evidence, flag items that rest on assumptions and suggest a ranking.
Want evidence before the next debate?
A short round of research can settle questions that opinions cannot. Tell us the question and we will propose how to answer it.
- No obligation
- Written scope
- Plain-English findings