I came to web development through design (and art). And I came to design through a copy of Design for the Real World that my DT (Design and Technology) teacher recommended to us during GCSEs in the 90s. Papanek’s argument was blunt: design is a political act. You are either designing for people or you are designing for the market, and those are not the same thing. He wrote that in 1971.
Papanek often lives rent free in my head.
What we actually learned
For a few years – roughly 2009 to 2015 – it looked like the industry might actually live up to that. Not everywhere, not all at once, but the direction was right
GDS (Government Digital Services) shipped things that worked. They created a government department that moved away from outsourced suppliers and their specification documents and change requests. The design principles were real principles, not a mood board. “Start with user needs” wasn’t a slogan – it was a method. Show the thing.
Agile, when practised well, was similar. Small teams. Fast feedback. Working software over comprehensive documentation – which meant you had to show the thing to real people and see if it worked. The manifesto’s best line isn’t about sprints. It’s “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Customer. Not client. Not stakeholder. Not the person who signs the invoice.
I worked on projects like this. They were good. It felt right. The software worked. Users liked it. I liked it.
What we then did with it
Somewhere around the mid-2010s something shifted. I’ve written about this before (see: Fordism with a Toyota Badge, dogwonder.co.uk, I nicked my own title for this) but the short version is: scale happened.
The tools got more powerful. Figma could produce something that looked (almost) exactly like a finished product. Jira (shudder) could track every ticket through every stage of a process. Velocity could be measured. Sprints could be planned quarters in advance. Delivery could be commanded.
And so it was.
The designer went back inside the cubicle. The developer went back to receiving files over the wall. The user researcher – if there was one – went back to producing reports that got filed somewhere before the sprint planning meeting. The user went back to being a persona on a slide and never thought about again.
I found myself spending hours explaining why the line breaks were different on a phone than on a 1920px Figma comp. I found myself moving tickets from one column to another and then back again. I found myself, on more than one project, unable to tell you what the person using this thing was actually trying to do. That information lived somewhere else in the process. It wasn’t my column.
This is not a new story. It is, in fact, a very old one.
The 2008 book about systems thinking
John Seddon is a management consultant and systems thinker. His 2008 book Systems Thinking in the Public Sector is about public service systems – housing benefits, council repairs services, and call centres and many other examples of systems that work not for the customer, but to appease the system itself; KPIs, targets, poor IT systems. It has nothing directly to do with web development but it describes web development perfectly.
His argument is this: organisations designed around command and control optimise their internal processes rather than their actual purpose. They measure what’s easy to count – quantify everything. They separate thinking from doing. They build “dumb front ends”, points of contact deliberately stripped of the knowledge and authority to actually resolve anything, because it looks efficient to have specialists handle different parts of the work. The person at the front handles the intake. Someone else handles the assessment. Someone else handles the decision. Someone else handles the communication.
Nobody handles the person.
The result is what Seddon calls failure demand: contact generated not because the person needs something new, but because the system failed to resolve their need the first time. They ring back because nothing happened. They submit again because the form rejected them. Computer says no. They chase because nobody told them what to expect. All of that activity looks like work. It’s logged, categorised, assigned. The CRM fills up. The team is busy. The problem is not solved.
Dashboards are created so executives see a pretty graph.
Sound familiar?
The Figma file that goes over the wall and comes back with forty-seven revision comments. The ticket that bounces between design and dev because nobody established what “done” meant. The QA process that catches the wrong things because it was never in the room when the right things were decided. The client sign-off that approves something users will immediately find confusing, because users weren’t in the sign-off meeting. The product is launched and it falls over on the first day because a user clicked some buttons in a certain order that was never planned, designed or discussed. The bug tickets start building up. Sprint planning starts to assign points and enter into kanban boards.
Failure demand. All of it. Contact – work, revision, rework – generated by the process failing to resolve the actual need at the first point of contact.
The thing Papanek would have said
Papanek’s critique of design wasn’t really about aesthetics. It was about who design serves. His argument was that the professionalisation of design had separated designers from the people they were supposed to be designing for. The client became the customer. The brief became the product. The award became the measure of success. The product becomes obsolete by design.
He would have recognised the Figma-to-Jira pipeline immediately. He’d have recognised the agency that presents three concepts to the marketing director and calls it user research. He’d have recognised the design system that’s beautiful in Notion and unusable in practice because it was never tested on a £80 Android on a 3G connection.
In order to work more intelligently, the whole practice of design has to be turned around. Designers can no longer be the employees of corporations, but rather must work directly for the client group that is, the people who are in need of a product.
He would not have been surprised. He would have recognised a system that does not respond to genuine human need. He would recognise a system that doesn’t embed designers and developers from the start.
The lost decade
Alex Russell has documented what this actually cost – in bytes, load times, and people excluded from public services because the JavaScript shipped to their cheap phones was designed for a MacBook on a fast connection. The stats are not subtle. JavaScript payloads shipped to mobile grew substantially over the decade, per HTTP Archive’s own tracking. The devices that most people actually use barely got faster. The gap between what we built and what the web could support got wider every year, while the industry congratulated itself on developer experience and component libraries.
This is what happens when you optimise the process (in this case developer experience) rather than the purpose. The process got very smooth. The purpose got buried in the sprint backlog. Failure demand is created.
Why it matters now
I’m not writing this as nostalgia. This isn’t nostalgia. There have been moments – GDS, the early Agile years, the accessibility movement – where the user actually started winning. They didn’t last. The point isn’t to return to something – it’s to understand why it went wrong, because the same mechanism is about to repeat at a scale that makes the lost decade look like a dry run.
AI is being dropped into the same broken pipeline. It will generate interfaces trained on the outputs of a decade of design-to-dev handoffs, dark patterns, framework-heavy stacks, and Dribbble shots that were never near a real user. It will do this faster than any team of humans. It will do it with great confidence. And the human who would have caught the failure demand – the designer in the research session, the developer who understood the codebase, the person who knew what users were actually trying to do – will be described as a cost saving.
Papanek in 1971. Seddon in 2008. Russell in 2024. The argument doesn’t change. The stakes do.
What comes next
This is part one of a series. Part two looks at the codebase the lost decade built – and what it means that this is now the training data. Part three is about what it would actually look like to put the human back in the loop.
Not the human as a prompt engineer. The human as someone who goes and talks to the person trying to use the thing, understands the demand, and comes back with knowledge rather than a persona.
Papanek would have called that design. Seddon would have called it understanding demand.