Design Critique¶
Review ritual — instantiates Implicit Assumption Surfacing
A critique session that surfaces assumptions embedded in a design choice or user model.
Design Critique is a structured review aimed at a concrete design artifact — an interface, a product, a flow, a service — whose job is to drag the premises baked into that design into the open. Every design encodes a silent model of its user: who they are, what they carry, what they can read, reach, and afford. Those premises are invisible precisely because the design "works" for the people who built it. The critique makes each design decision answer one question — what does this assume about the person using it? — and then presses the follow-up that turns a review into this archetype: who does that assumption leave out, and how does it steer them? It is collaborative rather than adversarial, and it is anchored to a specific object rather than to a plan or a person, which is what separates it from its siblings.
Example¶
A city presents a redesigned parking-payment kiosk for critique before the fabrication order. The renders look clean: tap your contactless card, confirm on the touchscreen, done. The critique walks each decision and names its embedded premise. "Tap card only" assumes the user is banked and carries a contactless card. "Confirm on screen" assumes reading standard-size English and standing at chest height. "Download the app for a receipt" assumes a smartphone. Stated as premises, the exclusions become obvious: cash-only and unbanked drivers, non-English speakers, wheelchair users who cannot reach the reader, older drivers with low vision. The critique then traces the influence path of the deepest premise — "drivers can always pay cashlessly" — forward to its consequence: the unbanked can no longer pay to park legally, so parking fines land hardest on the people with the least. That single trace reframes the missing cash slot from a nice-to-have into a defect, and the design goes back with a cash option, a multilingual screen, and a lowered reader.
How it works¶
- Put the artifact in the middle. The critique reviews a specific design object, at whatever fidelity exists — sketch, wireframe, or working prototype.
- Interrogate each decision for its user model. For every design choice, ask what it assumes about the person and state that premise as a proposition.
- Find who the premise excludes. For each embedded assumption, name the users the design's model leaves out — treated as defects, not edge cases.
- Trace the steer. Show how a design premise shapes real behavior and outcomes, so the exclusion is concrete rather than abstract.
The distinguishing move is that it reads assumptions out of an artifact and foregrounds who is left out — it is object-centric and inclusion-oriented, not an evidence attack and not a governance record.
Tuning parameters¶
- Critic diversity — how unlike the assumed user the reviewers are. Diverse critics catch exclusions insiders share; a homogeneous panel reproduces the very blind spots being hunted.
- Artifact fidelity — sketch vs. polished prototype. Low fidelity keeps premises cheap to change but hides interaction detail; high fidelity anchors on the concrete premise a rough sketch does not yet contain.
- Critique framing — generative ("what else could this assume?") vs. judgmental ("what's wrong here"). Generative framing surfaces more premises but can drift; judgmental framing is sharper but invites defensiveness.
- Scope — a single screen vs. the whole journey. Narrow scope goes deep on one decision; wide scope catches the load-bearing premise beneath the whole concept (e.g. that self-service kiosks fit everyone).
When it helps, and when it misleads¶
Its strength is catching baked-in premises and excluded users while the design is still cheap to change, and doing it on the concrete object where the assumption actually lives rather than in the abstract. Surfacing the excluded case reliably improves the design for everyone, not only the margin — the classic curb-cut effect.[n1]
Its failure mode is dominant-frame capture: the highest-status designer in the room quietly decides which critiques "count," and the deep premise survives while cosmetic ones get logged. It also tends to critique the design's stated choices while missing the unspoken meta-premise (that a self-service kiosk is the right form at all). The classic misuse is critique theater — feedback is collected, applause is given, and the user model never actually changes. The guarding discipline is to seat people unlike the assumed user and to treat every surfaced exclusion as a defect that must be dispositioned, not a note to be admired.
How it implements the components¶
implicit_assumption— it states, as propositions, the premises each design decision silently encodes about its user.excluded_case— its signature move: enumerating the users and situations the design's model leaves out.influence_path— it traces how an embedded design premise steers real user behavior and who bears the cost.
It does not attack premises with disconfirming evidence or re-grade their confidence (evidence_test, confidence_marker) — that adversarial work is red_team_assumption_review; and it does not attribute premises to accountable owners across parties (assumption_owner) — that is stakeholder_assumption_elicitation.
Related¶
- Instantiates: Implicit Assumption Surfacing — the critique surfaces and maps the premises a design encodes so they can be examined before build.
- Sibling mechanisms: counterfactual_assumption_test · model_assumptions_log · premortem_assumption_probe · red_team_assumption_review · reflective_interview · stakeholder_assumption_elicitation · assumption_audit
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Design Critique operates as a bounded evaluation of existing evidence or work that produces a finding or disposition because it a critique session that surfaces assumptions embedded in a design choice or user model.
Independent corroboration: The frozen evidence defines Design Critique as 'A critique session that surfaces assumptions embedded in a design choice or user model', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Architecture & Urban Planning
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Architecture is primary because the mechanism retains the studio-critique ritual: a concrete developing artifact is placed before a group for disciplined review of its design choices. Art education supplies a parallel critique lineage, while user-centered and inclusive design supplies this version's focus on assumed users, exclusion, and downstream consequences.
Related originating lineages:
- Art & Aesthetics — Art-school critique independently institutionalized collective examination of formal choices and their consequences.
- Human-Computer Interaction — User-centered and inclusive design materially redirected critique toward embedded user models, bias, and excluded cases.
Review resolution: Architecture is primary because the mechanism retains the studio-critique ritual: a concrete developing artifact is placed before a group for disciplined review of its design choices. Art education supplies a parallel critique lineage, while user-centered and inclusive design supplies this version's focus on assumed users, exclusion, and downstream consequences.
Attribution caveat: The review ritual is architectural and artistic; its explicit inclusion-oriented interrogation is a later HCI specialization.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- ERIC: The Architectural Review—A Study of Ritual, Acculturation and Reproduction
- Microsoft Inclusive Design: Recognize Exclusion
Notes¶
[n1] The curb-cut effect — a curb ramp cut for wheelchair users ends up serving cyclists, delivery carts, and parents with strollers — is the standard evidence that surfacing an excluded case improves a design for everyone, not just the margin it was drawn for. It is why a design critique treats exclusions as defects rather than acceptable edge cases. ↩