What gets noticed, and what carries the weight
Reviews tend to cover the top layer. It is visible, it is quick to check, and it produces a clean report. The layer underneath is where products fail in use.
These three diagrams set out both layers for user experience, accessibility and design systems. Use them to check what your last review actually covered.
The UX iceberg
The screens are the part of the work that is easiest to review, and the smallest part of what determines the outcome.
6 visible
15 underneath
On the surface
Visible, quick to check, easy to sign off.
- The screensLayout, hierarchy and visual polish.
- The prototypeIt clicks through convincingly.
- PersonasA deck of them exists.
- Journey mapPrinted, on a wall.
- Usability testFive participants, one round, near the end.
- Design system usageThe screens use the components.
In the craft
Design work that never shows up in a screenshot.
- Problem framingWhether this is the problem worth solving, established before anything is drawn.
- Information architectureFindability and mental models, which a tidier menu doesn't fix.
- Content designThe words carry the flow, so they are designed alongside it from the start.
- StatesEmpty, first run, error, offline, slow and partial, each designed before users meet it in production.
- PerformanceLatency and stability treated as part of the experience, not only as an engineering concern.
In the evidence
What separates a decision from a preference.
- Continuous access to usersA standing recruitment channel, so each project starts with participants already in reach.
- Research that moves the roadmapFindings arriving early enough to change a decision that has not been made yet.
- Behavioral dataWhat people do, held against what they say they do.
- InstrumentationA measure defined before release and tied to the decision it is meant to inform.
- Service and back stageThe operations, policy and staff work that the interface only reports on.
In the organization
Where good design work is overruled.
- Decision rightsWhether design can say no, and to whom.
- A seat before the commitmentInvolved when the problem is chosen, not after the date has been promised.
- Debt ownershipNamed owners for the flows nobody wants.
- Research capacityFunded, planned time, so research doesn't have to fit in the gaps between deliveries.
- A shared bar for qualityAn agreed definition of good, so that it is not re-argued on every project.
Test it yourself
Name the last roadmap decision that changed because of a research finding, and the date on which it changed.
Reference
ISO 9241-210 human-centred design for interactive systems · ISO 9241-11 usability definitions
The accessibility iceberg
A page can pass every automated check and still be unusable with a screen reader.
6 visible
18 underneath
On the surface
Visible, quick to check, easy to sign off.
- Color contrastThe contrast checker returns a pass.
- Alt textImages carry an alt attribute.
- Keyboard focusTab moves through the page in order.
- HeadingsThere is an H1 and a heading structure.
- Form labelsEvery field has a visible label.
- Automated scanThe tool reports zero errors.
In the build
Decided in code and in component specifications.
- Semantic structureLandmarks, roles and native elements used for what they are, before any Accessible Rich Internet Applications (ARIA) attributes are added.
- Accessible namesWhat the screen reader announces matches what the voice user says out loud.
- Focus managementFocus moves where the interaction moved it, and never lands on nothing.
- State and changeLive regions announce updates that would otherwise appear silently.
- Dialogs and overlaysFocus trapped, background inert, focus returned on close.
- Error recoveryErrors are announced, described in text and correctable without starting again.
- Composite widgetsTabs, comboboxes, trees and carousels built to the ARIA Authoring Practices.
In the conditions
People's own devices, settings and content.
- User preferencesReduced motion, forced colors, 200 percent text scaling and 400 percent zoom all survive.
- Assistive technology diversityTested on more than one screen reader, and on the browser pairings people actually use.
- Mobile and touchTarget size, orientation, gesture alternatives and mobile screen reader behavior.
- Third-party componentsThe embedded widget, the payment iframe and the chat bubble you did not write.
- DocumentsTagged PDFs, reading order, and exports that leave the product accessible.
- Language and directionLanguage attributes, right-to-left support, and translations that keep their semantics.
In the organization
Where accessibility either holds or quietly lapses.
- Testing with disabled peoplePaid participants and real tasks, rather than a colleague guessing with the screen switched off.
- Accessibility at design stageSettled in wireframes and component specifications, before anything is filed as a quality assurance defect.
- Regression preventionComponent-level ownership and automated checks that block a merge.
- Procurement and legalEN 301 549 evidence, an accessibility statement, and a conformance report that survives scrutiny.
- Funded ownershipA named owner with capacity, rather than the one person who happens to care.
Test it yourself
Ask someone who uses a screen reader every day to complete your primary task, unaided, on their own device and with their own settings. Watch without helping.
Reference
WCAG 2.2 AA · EN 301 549 · Directive (EU) 2019/882 · ARIA Authoring Practices Guide
The design system iceberg
A component library is an artifact. A design system is an agreement about how work gets made.
6 visible
16 underneath
On the surface
Visible, quick to check, easy to sign off.
- Component libraryA Figma file with components in it.
- Color and type tokensThe palette has names.
- Documentation siteThere is a page for each component.
- Icon setOne consistent family.
- Naming conventionThings are named the same way.
- It looks currentThe system matches the latest brand work.
In the components
What each component owes its consumer.
- States and edge casesEmpty, loading, error, overflow, long strings and right-to-left, all specified.
- Accessibility shipped insideRoles, focus order and keyboard behavior arrive with the component.
- Design and code parityThe Figma component and the coded component behave the same way under the same properties.
- Composition rulesWhat may be slotted, nested or overridden, stated in writing.
- Responsive behaviorDefined once at component level, so consuming teams don't decide it again.
In the contract
The part teams plan their work around.
- Token architecturePrimitive, semantic and component layers, rather than one flat list of hex values.
- ThemingLight, dark, density and sub-brands without forking the codebase.
- VersioningSemantic versions, changelogs and a deprecation window people can plan against.
- Breaking-change processHow a change reaches every consumer, and who absorbs the cost of adopting it.
- Migration pathWhat happens to the screens built before the system existed.
In the organization
Where systems are abandoned rather than replaced.
- Contribution modelWho may propose a change, who decides, and how long a decision takes.
- Decision rightsWhat happens when a product team wants an exception, and who is allowed to grant one.
- Adoption measuredThe share of shipped screens actually using the system, tracked over time.
- Support channelA place where questions get answered the same week.
- Funded teamA roadmap and headcount, rather than evenings and goodwill.
- Retirement of the old libraryFunded, dated and completed, with nothing left running in parallel.
Test it yourself
Take the last screen you shipped. Count how many of its components came from the system, and how many were rebuilt locally. Then ask the team why.
Reference
There is no standard here. The nearest references are the W3C Design Tokens Community Group format and whatever your own contribution model actually says.
Did your last review reach below the waterline?
We look below the surface of the user experience, its accessibility and the design system behind it, down to how decisions get made.
Talk about a review