Assess user requests by task and impact

A frequently voiced request deserves attention. Its frequency alone does not explain which change would most improve a working situation. The team needs to understand the task affected and what happens today.

Two concerns in a fictional warehouse application

The following example is entirely hypothetical. It describes no completed study and contains no measured distribution of user requests. Suppose a warehouse application receives a request for a darker display and a report of unclear quantity units.

If, in this assumed case, the correct quantity is uncertain and no usable temporary route exists, we would investigate the units first. That sequence is justified by these assumptions; it is no universal ranking of product features.

Trace the proposed solution back to the need

“Darker” already describes a possible solution. Glare, contrast problems or habit might lie behind it. Those differences affect which change helps. Dismissing the request as a matter of taste would end the investigation too early.

An unclear unit does not automatically receive the highest priority just because a serious consequence is conceivable, either. The team still needs to establish when it occurs, who is affected and whether the existing way of working offers a reliable alternative. A rare observation is a reason to investigate, rather than evidence of prevalence.

Record the decision and its basis

Keep the observed action, your interpretation and the planned next step separate. For both concerns, record the task, the conditions affected and the unresolved question. That makes it possible to see which new information would justify a different order.

Counts from a small qualitative study do not reliably establish how widespread a problem is across the target population. A priority decision can still be possible if its basis and uncertainty remain visible. In this example, a clearer unit would count as an improvement only if it helped people enter and check the quantity more reliably in the relevant workflow.

Sources

• GOV.UK — Analyse a research session

• GOV.UK — How the discovery phase works

• Nielsen Norman Group — The Definition of User Experience

• W3C WAI — Involving Users in Evaluating Web Accessibility