In the 1950s, US Air Force statistician Gilbert Daniels measured 4,063 active pilots across ten anthropometric dimensions: neck, chest, sleeve, leg, you name it. None of them fell within the average range on all ten. And when he narrowed the test to three dimensions, fewer than 3.5% of pilots met the average. Daniels “landed” with the following conclusion:
...the “average [hu]man” is a misleading and illusory concept as a basis for design criteria, and is particularly so when more than one dimension is being considered.
The Air Force had been designing cockpits around the average pilot for the better part of two decades. Daniels’ finding explained why so many pilots were dying in them. The military’s response was adjustable cockpits sized to the 5th–95th percentile range of each dimension. The shape of the cockpit became whatever shape any one pilot needed it to be. Accident rates plummeted.
It’s taken software a while to inherit Daniels’ lesson…
For most of its history, software has remained the inflexible cockpit: one interface, designed against a notional median user, shipped to everyone. It has no physical reason to be inflexible, but for the longest time the working assumption was that one shape per platform was both possible and good.
Designing for nobody
Platform documentation started the work of homogenising the end user. Apple’s original Human Interface Guidelines codified a vocabulary (menu bar, window controls, modal dialog) and laid out its rationale. Microsoft soon followed. Their existence produced more usable software than the chaotic alternative of every application inventing its own conventions. But what these guidelines also reified was a single monolithic shape, applied to every user.
Alan Cooper named the consequence in 1999. Without a specific person in mind, every stakeholder projects their own assumptions onto “the user”, and every feature becomes defensible because some user might want it. He called this fictional person the elastic user: the one who bends and stretches to fit whatever decision needs justifying. The elastic user is the median user’s quieter twin – the one who survives because nobody is being specific about who you’re designing for.
The near-solutions
Cooper’s solution was the persona: a named archetype that had concrete goals. Over time Cooper and others formalised the persona hierarchy into a primary persona (the design target, one per interface) surrounded by secondary, supplemental, customer, served, and negative personas. The axiom was that the primary persona’s needs and goals should be “completely and happily satisfied by a single interface without disenfranchising any of the other personas” (source).
Single interface is the clincher here. Personas force specificity about who you’re designing for, but the interface is still one shape, and the shape still has to accommodate everyone else. Cooper’s own framing that secondary personas receive “small additions that should not negatively affect the experience of the primary persona” names the compromise without quite admitting it. It’s the cockpit sized for one, and a sprinkling of affordances for the rest of us.
Jobs to the rescue?
Where Personas reframed who we were designing for, a parallel methodology reframed the what. Jobs to Be Done (Ulwick and Christensen) argued that people don’t buy products so much as hire them to do a job. And that the job, being more durable than any demographic, is the better unit to design around. JTBD fixed the weakness in Cooper’s framework but it left the architecture untouched. A product built around a primary job still ships one interface, optimised for that job, compromising on the rest. The decomposition improved, but the constraint stuck around.
Neither Cooper nor the jobs school was wrong. Each named something real, and each gave us tools that improved what came before. What neither could do was build a system where the interface itself adjusts.
A framework for the fringe dwellers
On most projects of any complexity, a lot of design time gets spent attending to edge cases: the fields, paths, and decisions that your average user is unlikely to make or take. The thing is, these aren’t actually edges, they’re just not the average. For some other person using the same software, those edge cases are the whole experience. The interface holds them; but the design discipline may not.
Jutta Treviranus, the field’s leading voice in inclusive design, built a design philosophy on that exact observation. Designing from the edges tends to produce better outcomes for everyone, because the edges are where the real constraints surface. Instead of sizing the cockpit to the 5th-to-95th percentile and accept the tails as casualties, design for the fringe dwellers and let the middle look after itself. She nailed the principle. But the thing nobody had was a different interface for each person. To get past it, you had to make the interface itself adapt.
The failed escape
The HCI field tried just this. Ernest Edmonds opened the door in 1981 with an essay called “Adaptive Man-Computer Interfaces,” and by 1990 the field had its first major synthesis in Browne, Totterdell and Norman’s Adaptive User Interfaces. The argument was straightforward: if the system can observe what the user is doing, it can also adapt the interface to match.
The argument became a public debate at CHI 1997, when Ben Shneiderman and Pattie Maes debated the competing paradigms of direct manipulation versus interface agents. Maes argued that as software environments grew more complex, users would need intelligent delegation; the system would need to do some of the work of inferring what they wanted. Shneiderman posited that users need control, predictability, and comprehensibility; and that adaptive systems are inherently unpredictable, because they change underneath you for reasons you can’t see.
Maes’ thesis crash-landed in the form of Lumière, Microsoft’s research project that incarnated as Clippy, Office 97’s desktop assistant. The research was technically sound, and Clippy’s underlying Bayesian model was capable of inferring what users were likely doing. But the user experience was widely loathed. Because the inference happened invisibly, Clippy’s behaviour felt unpredictable.
Shneiderman’s argument largely prevailed for the next twenty-five years. Adaptive systems couldn’t reliably model intent, so users couldn’t predict what would happen. The cure was worse than the disease.
Three things converged
Since Clippy’s demise in 1997 three independent developments have occurred that together make it worth revisiting the median-user problem.
1. The atoms became reliable
Design systems started out as documentation: rules for designing the one shape, well. Twitter’s Bootstrap took consistency to industrial scale. Then along came Brad Frost’s Atomic Design which gave the practice a mental model of atoms, molecules, and organisms. Jina Anne followed up with design tokens to encode the subatomic particles of UI.
But the shift that mattered most for what comes next was when components stopped imposing their own visual style. Tools like Headless UI, Radix UI, and React Aria ushered in an era where atoms were standardised, accessibility-correct, and behaviour-complete in a way they had never been before. The atoms became reliable enough to compose across brands at configuration time. The interface stopped being a single thing the design team locks in. It became a space of possible shapes, bounded by the design system, that configuring users move within.
We’ve watched this play out in our own client work. Earth, the design system we built with AnywhereWorks, has a token architecture designed to let small business owners reshape the booking page (palette, logos, button shapes) to match their brand. This flexible configuration approach carries through our work with Rugby Australia and AusCycling: where themability unlocked scale for content managers.
2. The data became reachable
Headless content APIs are the second integral pillar. The design principle behind headless is to enable rendering flexibility from a single source of truth, so many frontends could consume the same content and present it in myriad ways. We open-sourced Keystone in 2013 as the first Node-based headless CMS of its kind. Contentful, Sanity, and others soon followed with their own unique spin on headless. A decade on, these platforms expose their data through schema-driven, self-documenting APIs and power many of the world’s interfaces. While they weren’t built with LLMs in mind, they happen to be exactly the kind of structured, front-end-agnostic context that LLMs thrive on.
3. The platforms met a new consumer
The third thread is the newest. The Model Context Protocol makes any platform agent-native so it is readable and operable by a language model, not just developer-written code. The MCP Apps Extension (late 2025) extends the pattern further, standardising how servers ship interactive UI back to clients.
The assumption that humans are the only consumers of the platform, implicit in seventy years of HCI, drops.
None of these three developments were aimed at where they’ve collectively arrived. Design systems matured so teams could ship faster without losing quality. Platforms went headless for channel flexibility. Agent-native exposure landed because the agents arrived. Nobody was coordinating any of it. Looking back, the through-line for adaptive UI is clear.
A new architectural response to the old debate
Bounded generation
The convergence of these three pieces asks new questions about what might be possible with composition. When:
- The user states what they want to see, in plain language.
- A language model reads a typed schema and a typed component catalogue, and emits a typed spec.
- A deterministic renderer turns the spec into UI.
The LLM never writes the UI code in an unbound manner. It selects from the catalogue, binds to the schema, and describes the result.
Several independent versions of this bounded-generation pattern (Portal UX Agent, A2UI, json-render, MCP Apps) all landed within a four-month window in late 2025. It’s the same underlying principle each time: the model composes, the schema constrains, and the renderer executes.
Anchored intent
If we pair the productivity of bounded on-system UI generation with the tried-and-tested pinning metaphor where users save the composed view as a stable artefact they can return to, share, or evolve — the 1997 Shneiderman–Maes debate reframes in an interesting light.
Shneiderman’s primary concern was invisible inference: the system changing under you for reasons you can’t see. Today, when the user states intent (prompts for the view they want) that hidden and confusing inference moves into the open. His comprehensibility and predictability concerns find their footing in a composed interface where stating intent is visible and the result is pinnable. Maes’s case for adaptive delegation finds a new friend in the LLM who’s capable of doing the (bounded) composition at prompt time. Neither side won. But the terms certainly changed.
It’s worth notiing thay while architectural availability is one thing, the shape of such a paradigm in production is another. End-user just-in-time composition at this scale hasn’t yet shipped in any SaaS products I’m tracking. But what’s adjacent is real:
- companies like Figma, Canva, and Box are shipping official components that render inside chat clients like Claude
- vibe-coding sessions are producing hyperfunctional design artefacts that access platform data and solve for UX in ways that are truly centred around unique, non-average use cases
Some of the architectural responses to the median-user problem are now possible in a way they weren’t five years ago, even if whether they ship widely turns on things that aren’t architectural: economics, governance, accountability, or the cold-start problem of not knowing what to ask for.
What might change going forward
This shift changes the work of designing. The unit has been the interface for seventy years — what we’ve shipped, argued over, recruited for, charged for.
When composition at the moment of intent is possible, the unit moves toward the schema, the primitives, and the boundaries of what can be composed. The default interface a platform ships still matters because it bootstraps everyone, but it stops being the only shape your users will ever meet. Persona work aimed the whole effort at one representative user; our discipline can now hold the full spread of them, edge cases and all.
That’s a different design surface, and arguably a bigger one.
If you ship software, three questions start to matter:
- What does your schema look like to a language model that’s never read your documentation?
- Which of your "edge cases" stop being edges once users can compose what they need?
- What’s the shape of the space your users should be able to move within?
The cockpit never had to be one shape. For the first time, it doesn’t have to be.
