NEUROWIRE

Product & Design

Updated Nov 13, 2026 · 10 entries
UX Collective - Medium · Nov 13, 2026

Decision theatre or decision design?

AI has made information easy, but it has not made decisions simple. As machines produce more than we can read, our job is shifting from building knowledge to owning decisions. Are we ready? In a 2025 survey by BetterUp Labs and the Stanford Social Media Lab, 40% of US desk workers said they had received workslop in the previous month: AI-generated work that looks polished but does not move the task forward. Respondents reported spending nearly two hours, on average, dealing with each incident. Imagine a team of ten, each receiving one piece of workslop a month. That is roughly 20 hours, more than two working days, spent cleaning up someone else’s shortcut. We have never produced so much data, so many documents, decks and summaries. And we have never produced so much digital waste . This is a productivity problem, but it is also a symptom . The question is not how much faster we can produce something. It is how much extra work that production creates for everyone else, and who is left to decide what any of it means. How did we get here? For most of human history, change moved slowly. Roughly ten thousand years separated the birth of farming from industrialisation. Evolution had time to move from one stage to the next, across centuries and generations. Then the interval shrank. Only about two centuries separated the first factories from the rise of service and knowledge economies. And then it shrank again. In 1969, ARPANET connected its first computers: the beginning of the information society. Less than sixty years later, AI agents use the knowledge we put online to make recommendations and, more and more… decisions. Think about what we did in those sixty years. We created the bits. We built digital worlds and a digital culture. We ran digitalisation programmes. We put books online with Project Gutenberg , information online with Wikipedia . We worked hard to make information accessible and ubiquitous, on every channel, for everyone. Without knowing it, we were laying the foundation for an artificial form of intelligence to learn from our human-built infrastructure, and to work on top of it. The information society was basically the training ground for AI. Our knowledge is now the bridge between the old, human-driven world and a new, AI-empowered one. This compression raises a pressing question. How quickly can people, organisations and institutions adapt? Does more information make us wiser ? Not on its own. And we have known that for a long time. In information management, one of the best-known frameworks is the DIKW pyramid : Data, Information, Knowledge, Wisdom. It is usually credited to Russell Ackoff , who formalised it at the end of the 1980s. The logic is simple: Data: the raw elements. Facts and signals with no context. Information: data that has been processed and organised. Knowledge: information that has been interpreted and put to use. Wisdom: knowledge that allows judgement. Each level is built on the one below, but the relationship only works one way. As Steyn puts it, wisdom is always knowledge, but knowledge is not always wisdom . Every level is a subset of the one beneath it. In 1987, Milan Zeleny proposed the same four levels in a language that organisations understand much better: Know- nothing : data Know- what : information Know- how : knowledge Know- why : wisdom Read it from the bottom up: each level is built on the one below, but no amount of data adds up to wisdom on its own. For Zeleny, managing efficiently means knowing how to do things. Managing effectively means knowing what to do . Managing wisely means knowing why . And wisdom goes one step further: it is what lets us compare and judge our know-how and our know-what. I first wrote about this back in 2013, on LegoViews . Back then, the challenge was getting organisations to make time for that reflection. Today it is harder. AI hands us endless know-what and know-how in seconds, and reflection, the step that turns them into a shared know-why , is exactly the one we are tempted to skip. Here is the point that matters most today. Wisdom comes from knowledge, but it is not a sum of knowledge. Adding knowledge to knowledge does not make wisdom. Processing more information does not make us wiser. What does AI know, and what doesn’t it? AI is extraordinary at the bottom of the pyramid. It processes data at a scale no team could match, and it turns that data into know-how : summaries, drafts, analyses, code. What it cannot settle for us is which problem deserves attention, whose interests should count, and whether we should act on its answer. These questions depend on context . They put the output into a broader frame: what we are trying to achieve, under which constraints, and why it matters. That frame is where knowledge gets judged. The worrying part is how many people now trust good-looking information, mistake it for wisdom, and pass it on. Especially in the domains where critical thinking is the whole job. And even the know-how needs checking. Large language models still add unsupported claims when they summarise a document they were given. On Vectara’s hallucination leaderboard, which tests this, rates in 2026 run from 1.8% to 24.2% of summaries, depending on the model. These are task-specific figures, not universal error rates. But they show how hard it is to rely on AI output that nobody reads closely. So we have a base of data and good-looking information, produced at a volume that no human can manage. What are we losing? For most of my career, the journey from data to judgement had its own pace. And it was work, real work . We collected an adequate amount of data. We prioritised. We designed studies around sampling and around the constraints we had: time, resources, our ability to analyse, the tools at hand. The constraints forced us to choose, and choosing forced us to think. Today we are in the middle of a data feast. We access more and more data not because we need it, but because we can. Slowly, we are creating working conditions in which there is less room to think, prioritise, sequence and distil. Less room for intentionality . The philosopher John Searle described intentionality as the mind’s capacity to be about something ( Intentionality , 1983). In organisations, it takes a more practical shape: the deliberate decision to focus attention and action on a clearly defined purpose. What we are trying to achieve, why it matters, and how our choices serve it. It is made of a few simple things: Awareness: knowing where we are and what we are looking at. Context: understanding the situation and its variables. Prioritisation: directing attention to what has the most impact. Distillation: separating value from noise. Without it, we stay in the noise. We consume data because we do not know where we are going, or where we should focus. All the narratives are about speed . We are omitting the craft. We stopped trusting the process because we only look at the output. But an output without a process is a simulacrum: something that looks good and has no substance. What gives value to data and knowledge is not the shape of the output. It is the process that generated it and gave it substance. Who decides? AI can do a lot, and it does some things better than we do. But there is one thing it cannot do: be held accountable. The idea is much older than generative AI. A slide said to come from a 1979 IBM internal training warned that “ a computer can never be held accountable ”, and concluded that a computer should therefore never make a management decision. The original has never been found in IBM’s archives, but the principle has aged remarkably well (more here ). Nearly fifty years later, regulation gives human oversight a concrete organisational form. Article 26(2) of the EU AI Act asks deployers of high-risk AI systems to assign human oversight to people with the necessary competence, training and authority, and to give them the support they need. So let’s be clear. An insurance claim. A loan. A place at a school. Access to benefits. AI can support every one of these decisions. It can sort the files, flag the risks, summarise the evidence. But these decisions must not become a way for organisations to hide responsibility behind a system. These decisions affect people’s fundamental rights. Behind each one there must be a human with a name, a role, the responsibility, the authority and the skills to make the decision, stand by it, defend it, and answer for the consequences. That does not relieve the organisation of responsibility for the system, the workflow or the conditions in which that person is expected to decide. AI can inform. It cannot own. This is where the paradox emerges: we have the illusion that we are outsourcing more and more work. In reality, our job is becoming that of the AI supervisor : the person in charge of making AI-enabled decisions. In one sentence: after we digitalised knowledge and built all the infrastructure, our role is no longer only to build knowledge. It is also to take responsibility for how that knowledge informs decisions. We are moving from the information society to an age of accountability, where we need to embrace our humanity to make decisions about other humans. Decision theatre or decision design? Responsible AI needs humans in the loop. That much is agreed. But a human in the loop is not enough on their own. Put a disengaged, overloaded or alienated person in front of an AI output and you get decision theatre: the illusion that a decision happened when it did not. Someone clicked “approve”. Nobody decided. We have a decision-making crisis, and more AI output will deepen it unless something changes. Most organisations lack a decision-making operational layer to support the people who must make the decisions. A real decision needs three conditions: Skills: the competence and training to read the context, the variables and the pre-digested input, and to tell a valid answer from a well-formatted one. Authority: a name, a role and a position that allow the person to override the AI, and the responsibility to own the result. Process: workflows designed to empower decision makers, with the right information, tools and time, and without drowning them in decision fatigue. Take one away and the decision collapses into theatre. Who holds the judgement? It is tempting to map Zeleny’s forms of knowing onto an organisational chart: leadership decides why , management decides what , operations deliver how . But Zeleny was describing forms of knowing, not ranks of people. The mistake is to confuse the authority to make a decision with the knowledge needed to make it well. A frontline worker may have no say in strategy, yet can be the first to notice when a process is failing or a case does not fit the rules. Research on digitalised frontline work shows that this tacit knowledge and discretion still matter, even where systems automate parts of the process. Automate that work without asking what judgement it holds, and the organisation loses more than a task. Imagine a caseworker reviewing benefit claims flagged by an AI system. In the theatre version, they get hundreds of cases a day. They see a risk score and two buttons. They have no time to open the file, and overriding the system needs their manager’s sign-off. They approve what the machine suggests. On paper, a human was in the loop. In the designed version, they get fewer cases, prioritised by uncertainty. They see the sources behind each score and the points where the system is least confident. They can override it, and they record why. Their overrides go back to the team that runs the system, so recurring problems can be investigated and corrected. Same person. Same AI. A completely different decision. This is where design enters the scene. Somebody has to design these decision-making workflows : to enable, and indeed empower, humans to decide, and to avoid both decision fatigue and decision theatre. What skills will the human in the loop need? If humans are expected to own AI-supported decisions, we need to be clear about what that responsibility requires. We need humans who think as humans, not as machines. What does that mean? It means humans who understand the problem, the context and the domain. It means humans who understand the AI output and the process that produced it. It means humans who can separate the validity of the content from the polish of the form. Three families of skills will matter most. Critical judgement: being sceptical, spotting errors, asking where a claim comes from, and noticing what is missing as well as what is there. Sense-making: taking the knowledge we have built and organising it into structures that increase accuracy, logic, relationships and reliability. Human skills: the so-called soft skills, and the hardest to delegate. Empathy for the person on the other side of the decision. The courage to disagree with the machine. The integrity to sign your name under the result. None of these is new. What is new is that they are no longer a nice-to-have on top of the “real” work. They are the work. How do we teach people to decide? If these skills are the work, we need to teach them differently. People reviewing AI-supported decisions need practice in judging incomplete evidence, recognising exceptions, understanding the context and rules that apply, and explaining what they decided and why. Without that preparation, we risk creating a new assembly line: people processing recommendations and carrying responsibility for decisions they barely have time to examine. This means rethinking curricula, in schools, universities and workplaces, around a few plain questions: How do we analyse data to tell the what from the why? How do we read a situation as a system, with its relationships, feedback loops and unintended consequences? How do we decide under uncertainty, and how do we stand by that decision? How do we notice when we are being asked to perform a decision rather than make one? This is why we need much more teaching in complexity theory and systems thinking . Not as niche electives for a few specialists, but as the foundation for anyone who will sign their name under an AI-enabled decision. In one word: we need to teach judgement . What’s next For years, many of us watched design thinking turn into design doing: more output, faster, with less and less time to think. AI can now do the doing faster than any of us. This is the crossroads. One road leads to more of the same. More outputs, more workslop, more decisions that only look like decisions. The other road brings thinking back to the centre. Framing the problem. Understanding the context. Prioritising. Designing the process that turns AI output into a decision a human can own. This is design thinking applied to the most human act of all: deciding about other humans. References Ackoff, R. L. (1989). From data to wisdom. Journal of Applied Systems Analysis , 16, 3–9. Searle, J. (1983). Intentionality: An Essay in the Philosophy of Mind . Cambridge University Press. Zeleny, M. (1987). Management support systems: towards integrated knowledge management. Human Systems Management , 7(1), 59–70. Decision theatre or decision design? was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

future-of-workartificial-intelligenceaiuxdesign
UX Collective - Medium · Nov 13, 2026

Schrödinger’s Huang: Nvidia could not be everything to everybody

A cautionary tale for Asian capital attempting to operate technology businesses on both sides of the Pacific simultaneously Continue reading on UX Collective »

businessdesignmachine-learningtechnologyux
Figma Blog | Shortcut · Nov 13, 2026

AI’s role in the creative process

NN/g latest articles and announcements · Nov 13, 2026

Research-In-The-Loop: How UXR Adapts to Development at AI Speed

As AI speeds up development, it can be a challenge for research to adapt. Research can define what each release must measure and what it can help teams discover.

Article
NN/g latest articles and announcements · Nov 13, 2026

Journey Mapping 101

A journey map is a visualization of the process that a person goes through in order to accomplish a goal.

Article
Stratechery by Ben Thompson · Nov 13, 2026

2026.46: The End of Jensen

The best Stratechery content from the week of November 9, 2026, including the shocking demise of Jensen Huang; enterprise, consumer and Intel; and professional basketbal.

This Week in Stratechery
UX Planet - Medium · Nov 13, 2026

Claude Fable 5.2 Official Prompting Guide

Anthropic’s 5 new rules for prompting Fable 5.2 Continue reading on UX Planet »

aicodinguxdesign
UX Collective - Medium · Nov 13, 2026

The crooked plate that felt more human than the algorithm

We have spent years teaching machines to be flawless. Now the flawlessness is beginning to feel like a kind of absence. Continue reading on UX Collective »

uxdesign-psychologydesign-thinkingartificial-intelligencedesign-research
Stratechery by Ben Thompson · Nov 13, 2026

Sharp Tech on Video: Nvidia After Jensen Huang, Ominous News for American AI, D.C. Gets Its Revenge

Sharp Tech is, for the first time, available on video. You have three ways to consume it: YouTube, Spotify, and here on Stratechery

Daily UpdateSharp Tech Video
UX Collective - Medium · Nov 13, 2026

AI is the new old design material

A long workbench where hand tools, a stack of paper, and an open laptop share the same surface. Creative makers and builders have always learned their medium by working with it, from grinding pigments to HTML. Models are the next material, and you need to learn them by building. The field keeps arguing about whether designers should code, as if that question were new. It’s not new. Art and design have always been taught through materials, going back centuries. In the 1390s, the painter Cennino Cennini wrote a handbook that’s still translated today on grinding pigments, and that history still runs through my own family as builders and creators. My mother, Jean Neeman , ground her own pigments as a conservator for the Los Angeles Museum of Art, the Getty and Hearst Castle , and I watched her repair Chinese statues that were over 600 years old with original materials to restore history. You can still grind pigments. Many painters do. She lived that craft, as I wrote in Everything I Know About UX I Learned From My Parents . I learned print through paste up, developing film for prints, and running film output. I understand that knowing the material is a timeless need, and most designers I meet don’t understand it, because their tools hide it. We need to respect it as part of the craft. The reality is that visual tools like Figma and Sketch are an abstraction, and real craft happens in the final mile, working with the material. Great designers have always used the materials they had, and I’ve always written code as part of the job to understand mine. On the web, that meant HTML, CSS, Javascript and whatever else that made it work. Artificial intelligence is the new material, teaching the same lesson faster. The designers doing the strongest work with models run them and read the output. That takes sampling code: a loop asking one question over and over until the model’s habits show. Students at long tables working wood, metal, and paper by hand beneath tall factory windows. Study the Bauhaus Workshops In April 1919, Walter Gropius published the founding manifesto of the Bauhaus , and its demand was direct. As art historian Magdalena Droste explains in The Bauhaus Manifesto , Gropius told architects, sculptors, and painters to turn to the crafts. The curriculum ended in a list of workshops. Students learned wood, metal, glass, and weaving by cutting, bending, and threading them. Josef Albers made the point with almost nothing. In his preliminary course, Droste notes, students had to make a flat sheet of paper stand on its own, or bend a straight wire until it held its shape. A drawing can suggest a chair, but only the wood can tell you where it will split. That habit produced the school’s best-known work. Marcel Breuer headed the carpentry workshop and bent tubular steel into chairs, and Herbert Bayer went on to run the printing and advertising workshop. They knew their materials because they had worked them. Every new medium since has sent designers back to a bench of some kind, and the last two benches have been made of code. Hand-Code 1990s Web Pages The web forced the same return, and it started with a blank file. In the mid-1990s, the design tool for the web was a text editor: Notepad on Windows, SimpleText on the Mac. You typed tags, saved the file, and reloaded the browser to see what you’d made. My earliest web credit, the Oliver North home page, came out of that era. Can you imagine editing in this? I did. Dedicated tools followed quickly, and each one moved the designer a step further from the markup: BBEdit (1992), a Mac text editor that added HTML tools in 1994. HoTMetaL (1994), an early HTML editor that showed where each tag began and ended. PageMill (1995), Adobe ’s visual editor for print designers. FrontPage (1995), a visual editor that Microsoft bought in early 1996. HomeSite (1996), a Windows editor built for people who wanted to write the HTML themselves. Dreamweaver (1997), Macromedia ’s visual editor. The designers who got the most out of the visual editors still opened the code underneath. They trusted the canvas only after checking the page in more than one browser. A visual editor showed one browser’s best case, and the markup showed the rest. In 2000, John Allsopp wrote A Dao of Web Design for A List Apart , arguing that the control designers knew in print was a product of the printed page’s limits. Ten years later, ethan marcotte opened Responsive Web Design with a quote from Allsopp. He built a sample page on a fluid grid with flexible images and media queries, then showed the layout changing shape as the window narrowed. Responsive design came out of a designer’s style sheet, and no mockup would have found it. Five years later, Frank Chimero gave the idea a name in The Web’s Grain , writing that “every material has a grain, including the web.” He argued that the field’s best techniques grew out of that grain, and that sites built against it come out fragile and awkward. Test Model Output Variation Models break the mockup in a new way. A static screen shows one answer, chosen by the designer and usually the good one. A model returns a different answer each time, and that spread is the thing you’re designing for. Call the chosen answer the one-sample mockup: a screen built around the output the model gives on its best day. In legal tech, where wedesigned search and summarization, every summary in a mockup was correct, because a designer wrote it. In 2017, Lars Erik Holmquist argued in Intelligence on Tap: Artificial Intelligence as a New Design Material that designers should treat the technology as a material with its own limits. In UX Design Innovation: Challenges for Working with Machine Learning as a Design Material (2017), Graham Dove and colleagues surveyed UX practitioners. They suggested that machine learning had seen little design innovation, possibly because it was a new and difficult material. Qian Yang ’s 2020 dissertation at Carnegie Mellon University , Profiling Artificial Intelligence as a Material for User Experience Design , went further. It traced those difficulties to two roots: uncertainty about what a system can do, and the complexity of what it might output. A mockup is one sample, and the product is the distribution. The Doherty Threshold entry on UX Guidelines, my own reference site, puts the point where software starts to feel conversational under 400 milliseconds. A static frame can’t show a four-second wait. Bret Victor built a whole talk, Inventing on Principle (2012), around the idea that creators need an immediate connection to what they create. You find the spread, the misses, and the delays only by running the model again and again. Code Prototypes Against Models Josh Clark tied the two eras together in his 2018 talk The New Design Material , calling machine learning “a design material in the same way that HTML and CSS is.” In Addressing UX Practitioners’ Challenges in Designing ML Applications (2023), K. J. Kevin Feng and David W. McDonald of the University of Washington ran a study with 27 UX practitioners. Each got a tool to build and test simple models while designing an app. Hands-on experimentation helped them match model behavior to user goals, invent interface features for correcting the model, and spot ethical risks. One participant explained that without testing, you don’t know “how often or in what ways it’s going to error.” The authors located the bottleneck in fabrication, the stage where models get made, because designers are usually kept away from it. Their tool needed no code at all. Today, for language models, a few lines of code are the shortest route to the same hands-on access. Geoffrey Litt saw it coming in Malleable software in the age of LLMs (2023), arguing that language models would let ordinary users build small tools from scratch. Designers have kept themselves at arm’s length from the material, and that distance is the bottleneck they can no longer ignore. That distance is closing. Figma’s 2026 AI report found that the share of designers participating in development doubled in a year, from 21% to 41%. Tools like Claude Code, Cursor, and Figma Make let a designer describe a prototype, wire it to a live model, and watch what breaks in a single sitting. Not every designer agrees that code belongs in the job. Alan Cooper wrote in Should Designers Code? (2017) that “coding is not a skill necessary to be a top notch interaction designer.” Karri Saarinen of Linear warned in Design Is More Than Code (2025) that production-first habits can erode the thinking behind a design. Both warnings are about code that ships. Sampling code gets thrown away the same afternoon, and its only job is to show you the material. Write AI Evaluation Sets Sampling code doesn’t need to ship. It works like a test bench, and its most valuable output is a record of every case where the model broke the design. Wood doesn’t change its grain overnight, but a model can change with a single provider update. Engineers already have a name for this file: an evaluation set. Designers are well placed to write it. They know which failures users notice first, like the answer that runs past the edge of its card or the wrong date stated with total confidence. A design tuned to last month’s model can fail without a single pixel moving. Four habits turn the record into working practice: Call the model directly. Ask Claude Code or Cursor for a script that sends real product inputs to the model and prints the answers, and read them before you draw a screen. Run each prompt 50 times. Sort the answers by length, tone, and accuracy, then design for the longest and the most wrong rather than the typical one. Bring the spread to review. Put the two worst of the 50 answers beside the mockup in design review, and decide together which ones the screen must survive. Save failures as test cases. Keep every output that broke a layout or misled a user in a shared file, so engineering reruns it whenever the model or prompt changes. Run the Model First Gropius moved students out of drawing rooms because drawings hid what materials would do. Designers on the early web learned the same thing in a text editor, and Marcotte proved it with a working page. The debate over whether designers should code has always been a debate about the material and how close designers can get to it. For artificial intelligence products, the material is the model’s behavior across thousands of inputs. You won’t find it in a frame on a canvas. You find it by running the model, reading everything that comes back, and keeping the failures somewhere the team can see them. These days I describe my job as building, and that’s the reason: I can’t design how a model-backed product works until I’ve watched the model work. Next time your team reviews an artificial intelligence feature, skip the one-sample mockup. Run the prompt 50 times, bring the worst answer to the review, and design the screen that survives it. Notice which answers the whole room argues about, because those are the cases a static mockup was hiding. That’s the workshop now, and the door is open to anyone willing to write a few lines of sampling code. AI is the new old design material was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

artuxartificial-intelligenceuser-experienceai