Skip to content

Affordance Visibility Audit

Diagnostic audit — instantiates Latent Affordance Surfacing

Systematically inspects the surfaces users actually sample and catalogs every available capability that leaves no perceivable trace there — turning "nobody finds this" into a ranked visibility-gap list.

Before you can surface a hidden affordance you have to know which affordances are hidden, and where. Affordance Visibility Audit is the upstream diagnostic that inventories what a system can actually do, maps the surfaces and moments its users genuinely inspect, and then walks the second against the first to find every capability that exists but announces itself nowhere the user looks. Its defining move is comparison by inspection: it does not ask users and it does not wait for logs — it holds the real capability list in one hand and the sampled-surface list in the other and marks the cells where a true option leaves no perceivable trace. The output is not a fix but a map of where the environment fails to tell the truth about what is possible, ranked so the surfacing work that follows has a worklist.

Example

A team ships a project-management SaaS whose admin console can do far more than customers use: bulk-automate status changes, clone permission templates, schedule recurring reports. Support tickets keep asking how to do things the product already does. They run an Affordance Visibility Audit. First they build the capability inventory from the engineering feature registry — every admin action that genuinely exists. Then they map the sampling paths: the handful of surfaces a real admin visits in a week (the dashboard, the settings gear, a couple of right-click menus), not the full sitemap. Walking each capability against those surfaces, they mark reachability and labeling: bulk-automation turns out to live three menus deep behind an unlabeled icon that appears on no sampled surface.

The deliverable is a ranked gap list: high-value capabilities that are effectively invisible at the places admins actually inspect, scored by value × invisibility. That single artifact reframes the conversation from "our users aren't power users" to "here are eight real capabilities that never touch a surface anyone looks at" — and it hands each downstream surfacing mechanism a concrete target.

How it works

  • Inventory the real option-set. Enumerate capabilities from ground truth (feature registry, permissions matrix, API surface) — the affordances that genuinely exist, independent of whether anyone can find them.
  • Map the sampled surfaces, not the full map. Trace where and when the intended user actually looks — the few screens, menus, and moments they inspect — because an affordance on an unsampled surface is invisible however well-labeled.
  • Cross-walk and score. For each capability, mark whether a perceivable, interpretable cue appears on any sampled surface; the misses are the effective-option-set gaps, ranked by value × invisibility.

The audit is inspection-based and comprehensive — its distinguishing trait is that it can flag a capability nobody has ever tried, precisely because no user has been given a reason to try it.

Tuning parameters

  • Coverage breadth — audit every capability or only the high-value ones. Full coverage catches surprises but costs inspector time; a value-first pass is faster but can miss a sleeper.
  • Inspector persona — walk the surfaces as a novice, a returning user, or an expert. The lens sets what counts as "perceivable"; a novice lens surfaces far more gaps and is the honest default.
  • Surface scope — which surfaces and moments count as "actually sampled." Draw the boundary too wide and everything looks discoverable; too narrow and you invent gaps.
  • Severity weighting — how you trade a capability's value against its invisibility to rank the list. Weighting toward value focuses the fix on impact; toward invisibility, on the most-buried.
  • Evidence standard — a heuristic walkthrough versus a strict checklist against every sampled surface. More rigor narrows disputes but slows the audit.

When it helps, and when it misleads

Its strength is coverage: it produces the one map no behavioral method can, because it catches capabilities users never even attempt — the affordances so unsignalled that they generate no failed search and no ticket. It is the cheapest way to convert a diffuse "our features don't get used" into a specific, prioritized target list.

Its central failure mode is that an inspector's judgment of what a user perceives is a prediction, not a measurement — the audit can confidently mark an affordance "visible" that real users still walk past, because discoverability is a property of perception, not of layout.[1] It can also only inventory the capabilities the team remembers it has, so a genuinely forgotten feature stays off both lists. And it is easily run backwards — walked leniently to certify that "everything is discoverable" and bless a design already shipped. The discipline that guards against this is to treat the gap list as hypotheses to confirm behaviorally (a discovery test, failed-search evidence) rather than proof, and to audit with a novice's lens rather than the builder's.

How it implements the components

Affordance Visibility Audit realizes the diagnostic side of the archetype — the components that locate the gap, not the ones that close it:

  • latent_capability_inventory — its first output: the ground-truth list of capabilities that genuinely exist, independent of their visibility.
  • user_sampling_path_map — the model of which surfaces and moments the intended user actually inspects, against which visibility is judged.
  • effective_option_set_gap — the headline deliverable: the ranked difference between what is available and what is perceivable where users look.

The cue- and delivery-side components — affordance_signifier_design, surface_placement_and_timing_rule, discovery_measurement_loop — are populated by the surfacing mechanisms this audit feeds, such as Contextual Hint or Tooltip and Call-to-Action Placement Test; a diagnostic audit locates gaps but does not fill them.

Notes

The audit is forward and inspection-based: it predicts where users will fail to perceive an affordance. Its verdicts are therefore hypotheses, strongest when paired with a behavioral method that watches what users actually do — Failed-Search and Helpdesk Query Analysis confirms the gaps where users tried and failed; a First-Attempt Discovery Test confirms them with fresh users. Keeping the audit upstream and separate is what lets the team re-run it cheaply as the product grows without re-litigating each fix.

References

[1] Discoverability — the degree to which a user can figure out what actions are possible and how to perform them — is Don Norman's term, and his distinction between a real affordance and a perceived one is exactly why an inspector's "it's visible" can diverge from a user's experience. It is why the audit's output is treated as a hypothesis to test, not a settled fact. ↩