B5.07.1Utilitydesignresearch

Utility is whether the function meets the need

Aliases: utility · functional value · need fit

What it is

Utility asks "does the product do the right thing": does the feature set cover what users actually need to accomplish, and is it done properly? It is orthogonal to usability—usability asks "is it smooth," utility asks "is the smooth thing the thing users want." A navigation app can be perfectly fluid and still fail on utility if it cannot look up routes offline.

Why it happens

Utility is decided by the match between needs and the feature set: needs have structure (core tasks, supporting tasks, edge scenarios); under-coverage blocks users from the task outright, and misaligned features build what nobody asked for. Utility defects rarely show up as "hard to use"—users usually cannot discover a missing function by trying; they simply give up or switch. That makes utility defects more hidden and more decisive than usability ones.

Studying it

On the demand side, use task analysis, interviews, and scenario inventories to establish what users need and its priorities; on the supply side, map the feature set against those needs—covered, uncovered, and feature-without-need. Validate with real usage data: usage and completion rates on core-need paths, plus the inventory of features nobody touches. Competitor feature matrices find gaps, but guard against feature-stacking for parity.

Where it stops holding

Needs move, so utility judgments have a shelf life; and "users say they want" diverges from "users actually use," so demand data must separate claims from behavior. Utility is necessary but not the tiebreaker: when every competitor clears the bar, usability and other factors decide. Chasing coverage also builds maintenance cost and interface complexity that boomerang onto usability.

Applying it

  • Answer "what must users accomplish and what's missing" before optimizing interaction in project and release planning.
  • Keep a need-to-feature map, update it each cycle, and route features with no corresponding need into retirement review.
  • Re-check need assumptions with usage data: for long-untouched features, investigate before deciding to polish or remove.

Related

  • Same group: B5.07.2 A usable function nobody needs has no value · B5.07.3 Together they form usability in the broad sense; neither alone suffices
  • Nearby: B5.01 Usability Definition · H1 Interaction Patterns and Flows
  • Search terms: utility · requirements analysis · feature coverage

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/B5.07.1