When teams try to prioritize UX fixes, they often start by arguing about which note matters most. After an hour with heatmaps and recordings you have a dozen observations and time for a handful of changes. A simple ICE score — impact, confidence, ease — will not settle the argument, but it makes you write down what each rating rests on. The letter C matters most when you score it by the strength of the evidence, not by how sure the note's author feels.
Gathering hypotheses is covered in our website conversion audit. Here you turn finished observations into a backlog with evidence links, score them from 1 to 5, plan one sprint and check whether the fixes worked.
ICE scoring in three questions
Rate every item with three questions. Impact: how much will the fix help at a step the business cares about, such as sending an enquiry? Confidence: how strong is the evidence that the problem exists and that this change solves it? Ease: how much work do the release and the follow-up check take? The score multiplies the three ratings, so one weak rating pulls the total down.
Scroll the table sideways to see all columns.
| Dimension | Question | 1 point | 5 points |
|---|---|---|---|
| Impact | What will the fix change at a key step of the journey? | An element outside the main path | A blocked form, pricing page or checkout |
| Confidence | How strong is the evidence? | Opinion or taste | A repeatable pattern confirmed by several sources |
| Ease | How much work do the change and its check take? | Rebuilding several pages | A copy or settings change done in an hour |
Itamar Gilad describes ICE as Sean Ellis's method in which impact, confidence and ease are multiplied, and confidence comes from evidence rather than opinion. His article is about product ideas, so the 1 to 5 scale and the evidence levels for recordings in this guide are our own adaptation: Itamar Gilad: ICE and the Confidence Meter.
Every observation becomes a backlog item with evidence
Do not score notes like "the form is weak". Each item needs the page URL, the device, what you saw and a link to a specific recording or heatmap view. Keep the hypothesis about the cause separate; that is what you test after release. If the observation involves repeated clicks, first establish what is behind them using our guide to rage clicks and dead clicks.
Where: /quote/, mobile, form step 2. Observation: in 7 of 10 visits reviewed, the consent banner covers the Send button. Evidence: links to three recordings and the click map. Hypothesis: some visitors cannot see the button and leave. ICE: I5 · C4 · E4 = 80. Check: same conditions after release.
In a month nobody will remember why an item got high confidence. Recordings are kept for a limited time, so copy the observation into the task as well as linking to it. The same observation with its recording link is useful later in a UX report for clients, where the recommendation waits for approval.
Confidence by evidence level: one recording is not a pattern
The most common mistake is high confidence after one vivid recording. A single visit shows that a problem can happen, not how often. Tie confidence to the level of evidence and use the same table for every item; a debate about the score then becomes a question about which evidence is missing.
Scroll the table sideways to see all columns.
| Confidence | Evidence | Example |
|---|---|---|
| 1 | Opinion, taste, a competitor comparison | "This headline is boring" |
| 2 | A single recording or one customer question | One visitor returns to pricing three times |
| 3 | A recurring pattern in recordings from one segment | Several mobile visits end in the same field |
| 4 | The pattern plus a reproduction or customer questions | The bug reproduced on a test phone |
| 5 | Several independent sources and an earlier successful change | Recordings, the heatmap, chat and a past test all agree |
Count a pattern across comparable visits: same page, similar device, same step. Our guide to analysing session recordings explains how to pick a sample, and the piece on how much data a heatmap needs covers when a map is dense enough to draw conclusions. Low confidence with high impact means a "gather evidence" task, not rejection; that task can go into the sprint itself.
Impact and ease without guesswork
Rate impact by position in the journey and by reach. A problem in the contact form affects everyone who wants to get in touch; one in the footer affects few. Consider whether visitors can work around it and whether they hit it every time. Do not write an expected conversion uplift in percent without a measurement behind it.
Jakob Nielsen (1994) suggests rating the severity of a usability problem by its frequency, its impact on users and its persistence. The article is about heuristic evaluation, not heatmaps, and does not offer a way to combine severity with the cost of a fix: NN/g: severity ratings for usability problems.
Ease covers more than developer time: include copy sign-off, outside vendors and the work of checking the result. A button label is often a 5; a form inside a third-party system more like a 2. A confirmed bug that blocks submissions does not wait for scoring; the difference between how serious a bug is and when it gets fixed is explained in our guide to priority versus severity.
A scoring example on a fictional website
A fictional accounting firm has a pricing page and a quote form, and four items remain after review. The ratings illustrate the method; they are not results from a real project.
Scroll the table sideways to see all columns.
| Item | I | C | E | ICE |
|---|---|---|---|---|
| Consent banner covers Send on mobile | 5 | 4 | 4 | 80 |
| Clicks on non-clickable client logos | 2 | 3 | 5 | 30 |
| Chat questions about setup costs, little scrolling to the FAQ | 4 | 2 | 3 | 24 |
| New homepage layout after the owner's comment | 3 | 1 | 1 | 3 |
The first item goes into the sprint without debate. The third has high impact but weak evidence, so it first gets a task: watch visits that land on pricing and collect chat questions. The logos are easy but minor. The homepage rebuild waits for evidence.
Treat the score as a starting point for discussion, not a verdict: the gap between 30 and 24 means nothing, the gap between 80 and 3 does.
One sprint plan and a check after release
- Choose a sprint goal.One step of the journey, such as submitting the quote form, rather than "improve UX".
- Take the highest-scoring items.Two or three fixes for that goal, plus one evidence-gathering task for a low-confidence item.
- Write down the check.For each fix: the page, the device, the behaviour that should disappear and the release date.
- Release and wait a comparable period.Watch visits from the same segment after the change date, not before it.
- Update the score.A confirmed effect raises confidence for similar items; no effect lowers it and the item returns to the backlog.
In Meetlead Projects, a task can be linked to a recording, a ticket and other tasks, and can have a high, medium or low priority, an epic and a place in the backlog or the active sprint. The click map shows how many retained recordings relate to a spot and opens their list. Meetlead does not calculate ICE scores: write the score in the task description and map ranges to priority, for example 60 and above as high.
After release, note in a comment what you checked and what you found. Fewer clicks on a covered button are not enough if the form is still not sent. With enough traffic, use A/B tests; otherwise compare before and after with care. The same way of rating confidence helps with feature requests from customers, as described in our guide to customer requests and the roadmap.
Questions about ICE scoring
Why a 1 to 5 scale instead of 1 to 10? With a dozen items, ten steps create false precision: it is hard to justify a 6 over a 7. Five steps can each be described in one sentence. What matters more is rating the whole backlog with the same table in one session.
Is ICE enough, or do I need RICE? For fixes on one website, ICE is usually enough, because impact already covers reach through the item's place in the journey. Across many pages with very different traffic, a separate reach rating can be clearer. Either way, record the evidence behind each rating; without it the score is just a tidy opinion.
