When a Requested Feature Hides a Process Problem

The requested feature is a starting point

A request to add a dashboard can sound ready for delivery. It names something visible, so a team can estimate it and begin designing. Yet the request may leave the underlying difficulty unexplained. My view is that the first conversation should examine the work surrounding the proposed feature. The question is what the user needs to achieve and what currently prevents that outcome.

Follow the work through one example

In a fictional training team, an administrator requests a dashboard of missing attendance records. Looking at one recent session reveals that attendance arrives in several spreadsheets with inconsistent identifiers. A dashboard could display the gaps without resolving the identification problem. The team now has two questions: how to make the records dependable and how to help the administrator identify outstanding actions.

Separate evidence from a proposed answer

Record what was observed, what the user reported and what the team assumes. A statement such as records arrived after the reporting deadline is different from a belief that another reminder will fix the issue. Ask where the delay occurs, who handles the record and what happens when information is missing. A useful investigation remains open to several explanations rather than treating the first request as proof of the cause.

Keep the outcome in view

GOV.UK guidance describes user needs in terms of what people must achieve through a service. That principle helps a team question a proposed feature without dismissing the person who requested it. A practical response is to acknowledge the request, investigate the difficulty and agree what evidence would show an improvement. A feature may still be the right answer, but the team can explain why.

Make the next conversation concrete

Take one fictional request and draw the steps immediately before and after it. Mark the points where information changes hands. Write one observation, one assumption and one question for the user. Then describe the outcome without naming a tool. This small exercise can reveal whether the feature supports the work or merely makes an unresolved process more visible.

Source and editorial note

Author: Jefferson Otonbara Imgbi. Reviewed 8 October 2026. The recommendations and fictional examples are original RDE editorial learning material. The source below provides background, not endorsement of RDE.

GOV.UK Service Manual: learning about user needs

Cover image: AI-generated illustrative scene created specifically for this resource.