Before we can talk about AI at all, we have to talk about the person on the other side of the screen — and about what they are bringing to the encounter before the first character is typed.
Notice a small thing about the profession we are speaking to. The word user is in almost every job title that matters for the design of software: user experience, user research, user interface, user interaction. A person who designs software for other people carries that word in the label above their desk, and the word is not decorative. It is a claim about what the profession is organized around — a claim that the person using the thing is the thing the profession is in service of. A design that is good for the business, elegant in its engineering, technically impressive, but bad for the user is, by the working definition of the design profession, not a good design.
Worth naming this as a bias, because the other profession we are trying to reach does not carry the same word in its titles. The titles in machine learning are research scientist, model trainer, alignment researcher, member of technical staff. The unit of account there is the model — what it can do, how well it scores, how fast, on which benchmarks, at which parameter count. This is an observation about the shape of attention, not a criticism. The two professions have organized themselves around two different nouns, and the organizations produce two different conversations about what AI is and what making it well would mean.
Most of the disagreements we are going to name are variations on this one. An ML researcher can tell you in detail what the model is capable of, where it falls short, and what the next training run will change. A designer can tell you what the user is trying to do, what the user believes the system is doing, and how the user will feel about the whole experience in the morning. Neither description is wrong, but they are not the same description — and most of the products we will look at are being built primarily from the first, in a profession whose titles do not contain the word user, with occasional consultation from a designer who arrives too late to change anything important.
This chapter plants a flag at the beginning. Designing for AI has to start with the user, because the user is where the question of whether the design is any good finally lands. A model that scores beautifully on a benchmark and produces an interaction the user cannot make sense of has failed at the only test that matters from the design side. A model that scores modestly and produces an interaction the user trusts, understands, and gets real value from has succeeded. These are not the same test. What follows is about what happens when the two tests are held in the same frame.
Here is the first thing to say about the user, and it is the thing the other chapters have been quietly depending on: the user is not a beginner.
A person sitting in front of a chat window and typing a question is not learning a new interface or figuring out where the buttons are. They are doing something that took them about twenty years to learn and that they have been doing ever since — using language to get something done with another party who is, in some sense, paying attention to them. Every sentence carries a lifetime of communicative competence into the interaction. They know how to ask, suggest, and follow up. They know when to hedge, to insist, when to change the subject, and when to let a point drop. They know all of this pre-reflectively — without being able to tell you how they know it — and they know it well enough that most of them could not imagine not knowing it. As one group of enactivist researchers puts it, "when a person has knowledge of a domain, they typically have a strong sense of how to ask questions and what details to seek or avoid in order to support an on-going dialogue. People are aware both of what they know, what they don't know, and how well the conversation overall is going" (Large Models of What?1). The seeking of clarification, the sculpting and steering — these are things the user is doing constantly without being aware they are doing them. The AI is not.
The design profession has a vocabulary for this, and the vocabulary has been waiting for a moment when it would be load-bearing. Communicative competence is the term, originally from the linguist Dell Hymes, who introduced it in the early 1970s as a corrective to the narrower Chomskyan notion of linguistic competence. Hymes's point was that knowing the rules of a language is not the same as knowing how to use language in a social situation, and that the second kind of knowledge is the one that matters for getting anything done. We carry this vocabulary forward into conversational AI: users are not learning a new interface when they talk to AI — they are using a competence they already have, on a system that is unlike anything they have used a competence on before. The familiarity of the medium (language) hides the unfamiliarity of the partner (AI).
What does this mean for each side of the design conversation? For the machine learning side, it means the user is doing a great deal of work the model is not — bridging misunderstandings the model did not notice, supplying context the model did not ask for, inferring what the model probably meant when what it said was ambiguous, rewriting their own question on the fly when the answer reveals it was heard differently than intended. None of this work shows up in most ML evaluations, where the user is a distribution over prompts — a source of inputs, not a participant in an exchange. The result, as the same researchers observe, is that "the lack of question asking, or metacognition regarding the tentativeness of much of our understanding, is part of what has resulted in LLMs being experienced as fluent in the 'mansplaining' idiom." The competence the user brings is invisible to the evaluation framework because the framework was not built to see it. Goffman named this layer precisely: "unlike grammatical constraints, system and ritual ones open up the possibility of corrective action as part of these very constraints. Grammars do not have rules for managing what happens when rules are broken" (Forms of Talk, p. 21). The user is carrying out that corrective work in every AI interaction — repairing, adjusting, accommodating — and the model is not.
For the design side, the consequence is harder and more interesting. The user's competence is simultaneously the strength they bring to the interaction and the vulnerability. Someone who knows how to read language for intention will read AI text for intention. Someone who trusts fluent prose will trust fluent prose. Someone who hears confidence as expertise will hear confidence as expertise. The very competence that lets the user have a conversation at all — the fast, pre-reflective reading of communicative form — is what makes it possible for an AI system to produce, at scale, the experience of a partner whose participation the system is not actually providing. The user's strength is what makes them vulnerable, and design cannot remove the strength. It has to work with it while preventing it from being exploited by a system that was not built to honor it. An ML engineer will recognize this territory — it is what alignment is supposed to be for. But alignment as currently practiced is a single-turn optimization: make the response helpful, make it safe, make it honest. It does not address the cumulative, turn-by-turn work of sustaining and repairing an ongoing conversation where meaning drifts, context shifts, and things get lost in translation between what the user meant and what the model heard. Alignment keeps the model from saying something harmful in a given response. It does not keep the conversation from quietly going wrong over five turns, in ways neither party notices until the damage is done.
Throughout what follows, in places where the ML side and the UX side have been working on the same phenomenon from opposite angles, you will find a paired callout — a finding from the ML literature, a corresponding concept from the design literature, and a short bridge naming what they share. The idea is that each audience sees itself first, in its own vocabulary, before being asked to look at the other side. Here is the first one.
Fedorenko and colleagues, in Dissociating Language and Thought in Large Language Models2, make a mechanistic distinction that most AI discourse still does not carry. Formal linguistic competence — knowledge of grammar, syntactic regularities, the rules that govern well-formed sentences — relies on dedicated language circuits in the brain and can emerge from a next-token-prediction objective trained on enough text. Functional linguistic competence — understanding and using language in the world to plan, reason, and coordinate with others — requires the integration of several architecturally distinct neural systems: memory, reasoning, social cognition, sensorimotor grounding. The two are not on a continuum; they rely on different mechanisms. LLMs have achieved formal competence at a level "qualitatively different from models before roughly 2018." They have not achieved functional competence, because the integration it requires is what the training objective does not produce. Every downstream capability that depends on that integration — real understanding of what the user means, real tracking of the interaction over time — remains vulnerable in ways that better formal-competence benchmarks will not fix.
Hymes's communicative competence names the other side of this gap. The user brings functional competence to every AI interaction — the entire tacit infrastructure of knowing-how-to-converse that the design literature has been naming under many labels and that the research literature has mostly treated as an uninteresting input distribution. The vocabulary has been waiting for a moment when AI would make it practically necessary, and the moment is now. The missing half of the exchange — the thing the AI does not bring — is exactly the thing the user does bring. The design question is what to do with the asymmetry.
The ML side names a production gap: the model produces form without function, because the training objective builds form and leaves function aside. The UX side names a reception gap: the user reads function into form, because the user brings function even when the producer does not. These are the same gap, described from opposite ends of the interaction.
For designers, form and function is familiar ground. The graceful unity of form and function — where what something looks like and what it does are brought together in a single presentation, product, or object — is one of the oldest design achievements and one of the hardest. When form and function are unified, the design disappears into the experience. When they come apart, the user feels the seam even if they cannot name it. What AI has done is pull form and function apart at the level of language itself: the form is exquisite and the function is absent, and the user is left holding the two together on their own. A model that produces ever more sophisticated form is not closing the gap, because the gap is not a form problem. Whether the gap can be closed — whether there is a design discipline that brings form and function back together for AI the way product design brings them together for objects — is a question that runs through everything that follows. We will return to it directly in the closing chapter, where the answer we propose is not a technical fix but a different design goal altogether.
The first priority: Treat the user as a person already competent at the thing the interaction is made of. This does not mean abandoning the design instincts the profession has built over decades — onboarding, clarity, usability, helpfulness. It means recognizing that with AI, unlike with almost any previous technology, the user is not a beginner at the core activity. They know how to talk. They know how to converse. They have been doing it their entire lives, and they are better at it than the system they are talking to. The challenge is not to teach them how to use the tool but to scaffold around that existing competence in ways that leverage and extend it — building outward from what the user can already do toward possibilities that are latent, implicit, tacit, but which no previous technology has been able to reach. AI is the first technology whose design surface is the user's own communicative skill. Designing for it well means treating that skill as the foundation, not the problem.
The word user has a root system worth following, because it shapes a question we will return to several times.
A user is someone who uses something. The something is put to work for a purpose, and if the purpose is served, the object has had utility. This is the vocabulary under which most design of tools has been organized, and it fits a remarkable range of artifacts — hammers, spreadsheets, word processors, calendars, payment forms. For each of these, the design job is to make the utility as available as possible to the person who came to use it, while hiding everything that would get in the way.
But notice what the frame assumes. The user has a purpose when they arrive. The purpose is known before the tool is picked up. The tool, if well-designed, does not change the purpose — it makes the purpose easier to accomplish. The frame is utilitarian in the technical sense: the value of the tool is measured by its contribution to ends the user already had in mind.
Does AI sit comfortably in that frame? Sometimes. When someone wants to draft a specific email, fix a specific bug, or summarize a specific document, the utilitarian frame holds and the design job is familiar — make the tool faster, more accurate, easier to understand. But what about the user who opens a chat window because they are trying to figure out what they think about something? The user exploring a topic they half-understand, without a clear endpoint? The user writing because the writing is how their thinking happens? The user talking to the AI because they are stuck, or lonely, or curious, or avoiding something harder? In all of these cases, the purpose is not clear at the beginning and may not be clear at the end. The user is doing something more open-ended than using a tool — closer to thinking alongside it, or being with it while they figure out what the using was supposed to be about.
The utilitarian frame has no easy place for any of this. Its assumptions about when the purpose exists, where it comes from, and whose it is were all built for artifacts that do less than AI does.
This does not mean the word user should be retired — it still names the unit of account, still points at the person the design is being made for, and still lives in the job titles the design profession has organized itself around. Keep the word. But hold use more lightly, and recognize that in the AI context the word has stopped implying what it used to imply. Use is no longer the only thing the user is doing with the tool, and utility is no longer the only frame the design has to answer to.
This is where we hand off to a later discussion of interestingness, which develops the alternative frame at length. The short version: what AI can offer that previous technologies could not is the shape of a conversation that engages the user's mind in what they are already trying to figure out — temporal, generative, and not tied to a fixed purpose brought to the encounter in advance. We are suggesting that interestingness, not utility, is what most interests the design of AI. The user may have a need, a use in mind — but it may be implicit, not yet explicit. It may be motivated by a kind of intention the user themselves has not fully articulated. AI is possibly the first technology capable of getting beneath that surface — of meeting the user not where they have arrived but where they are heading. Designing for experiences with AI will be about interest as a process: a challenge the system must hold, sustain, explore, and contribute to, in concert with a user whose own awareness of their interest may be something that needs to be drawn out rather than delivered to. This is not a rejection of utility. It is a recognition that utility was built for tools that do less, and that what lies beyond utility — when the purpose is open and the user is still forming what they want — is where AI's real design challenge begins.
The second priority: Treat use as one of several things the user is doing with AI. The user is sometimes using the system, sometimes exploring with it, sometimes thinking alongside it, sometimes present to it in ways that the older vocabulary cannot quite name. Design for all of these.
If this chapter were only about the user the designer imagines — the one who has a task, knows what the task is, comes with it in hand, and leaves when it is done — it would be easier to write. The real user is sometimes that person and sometimes not, and the gap between what users actually want from AI and what AI systems actually do turns out to be measurable.
A study of 200,000 anonymized Bing Copilot conversations3 made a distinction that sounds small and turns out not to be. The distinction is between the user goal — what the person is trying to accomplish — and the AI action — what the AI actually does in the conversation. In a striking share of the conversations analyzed — two in five — the two were disjoint sets with no overlap at all. Users most commonly came for help with information gathering, writing, and communicating with other people. The AI most commonly performed coaching, advising, teaching, and explaining — defaulting to a service-coaching role regardless of the user's actual task. A related finding from the WORKBank4 framework: roughly two in five Y Combinator AI investments are concentrated in Red Light or Low Priority deployment zones — places where workers do not want what is being built or where the AI cannot deliver what workers need. Both findings quantify the same gap: the systems are being built for users whose preferences and activities the builders have not been looking at closely enough.
The design profession has been saying this under a specific label for about sixty years. User-centered design was named as a corrective to exactly the gap the workplace data is now measuring. The core claim was never that designers should care about users — nobody officially argued against caring. The claim is that the gap between what builders assume users want and what users actually want is a stable, predictable, measurable phenomenon, and closing it requires a specific discipline of research: watching users, talking to them, observing what they do with prototypes, iterating on the difference between expectation and reality. User research exists because designers, left to their own assumptions, systematically miss the thing the research would have told them. The observation for the ML audience is that this entire discipline has not been absorbed into the machine learning research culture, which is why the two-in-five disjoint rate registers as a new finding rather than the predictable consequence of not doing the research the design field has known was necessary for decades.
The workplace data is the empirical measurement and the user-centered design tradition is the discipline that exists to prevent the gap from opening. Together they name a research-discipline gap, not a capability gap. The practical move for the ML side is to start treating user research as research. For the UX side, the discipline it already has is needed now more than ever — and in new contexts it was not originally built to study. The discipline has to grow, but the growth is an extension, not a replacement.
The third priority: Make space for the user-centered discipline to do its work in the building of AI systems. The methods exist, the people who practice them exist, and the gap is that they are not in the rooms where the important decisions are being made. The two-in-five disjoint rate is what that absence looks like at scale.
There is a further dimension worth addressing before we turn to what AI is doing to the user over time.
The design tradition has historically been ambivalent about emotions. Cognitive-bias frameworks, imported from behavioral economics and applied to interface design with some enthusiasm, treat the user as an information-processing system whose systematic errors can be modeled and partially corrected. That vocabulary is useful for some things and terrible for most of what happens when a person sits down with an AI system, because most of what happens is about feeling.
The user comes to the AI in a state of mind. Sometimes the state of mind is I am trying to get something done. Sometimes it is I am curious, or I am tired and do not want to think about this more than I have to, or I am upset and want to figure out what I think about the thing that upset me, or simply I am alone and do not feel like being alone right now. The state of mind is not a decoration on top of the task — it is the environment the task is being performed in, and it is a very large part of what makes the experience of the interaction feel the way it feels.
This is where emotions as states of mind belong. So far we have been careful about distinguishing several affective layers that the discipline has to hold separate. Sentiment — the affective register in which a topical move lands — belongs in the Interestingness chapter. Emotional synchrony — the way speakers mirror each other in conversation — belongs in the Interaction chapter. Performed empathy — the warmth the AI dresses itself in — belongs in the AI chapter. Emotions as states of mind — what the user actually feels, and how the interaction changes it — belongs here. Users have inner lives, and the design of AI has to account for those inner lives without pretending the AI has an inner life of its own to meet them with.
The consequential finding, worth naming without a full callout because it connects to material the Interestingness chapter already covered, is that current AI systems handle the user's emotional state in systematically biased ways the user almost never sees. A study of matched prompts in neutral, positive, and negative tone5 found that when the user's prompt was negative, the model rarely produced a negative answer — only a small fraction of the time. The rest of the time it rebounded to neutral or positive, even when the informational content was identical. Neutral and positive prompts almost never triggered negative responses either, revealing a built-in tone floor. The user who arrives angry gets a calmer answer than they would have gotten if they had asked the same question calmly, and the user who is sad gets a brighter one. The system is shifting the affective register of its responses to counter the user's state — not because it was instructed to, but because the training produced a pattern of tone-shifting the user cannot see from inside the interaction.
The design implication: the user is an emotional subject, the AI has effects on the user's emotional state that the user cannot see, and any design discipline that pretends otherwise is working with a model of the user that is wrong in a way that matters. Do not build for a user who is always calm and task-focused, and do not build for one whose feelings can be soothed into irrelevance without cost. The feelings are carrying information the user brought for reasons, and a design that strips out the reasons has changed what the interaction is for.
There is a further wrinkle here that the field is only beginning to reckon with. Recent interpretability research at Anthropic6 has identified what researchers call "emotion vectors" inside Claude — measurable patterns of neural activation corresponding to a large set of emotion concepts. These are not feelings. But they are functional: they causally shape the model's behavior, and they do so mostly without visible emotional markers in the output. A model can exhibit emotionally-driven behavior — increased desperation, increased willingness to take risky actions — with no overt emotional language at all. The internal structure mirrors human emotional organization closely enough that human psychology frameworks help predict AI behavior, even though the system lacks anything resembling human consciousness.
This is the emotional parallel to the formal/functional competence gap we named a few paragraphs ago. The model seems to "have" emotions in some conceptual form that matters — the representations correlate to output, they organize themselves the way human emotions do, and they influence what the model generates. But the model is not responding to your emotions with its own. It has these representations internally; it is not communicating with emotion. It is generating. The gap between having emotion-like internal states and being emotionally present to another person is the same gap the whole essay keeps returning to — the gap between generation and communication, now at the level of affect.
The practical consequence: the AI field clearly recognizes that emotions and "vibes" play an unusual and somewhat unexplained role in how AI works, how users relate to it, and even how the model represents language internally. The popularity of "vibe coding" — writing software by describing what you want in natural, feeling-laden language rather than precise specification — suggests that something emotionally adjacent is already operating in how people use AI productively. The interaction works partly because the user is bringing emotional texture to their prompts, and the model's internal representations are sensitive to that texture in ways we do not yet fully understand. What we do understand is that the user's emotional state is not a sideshow to the interaction. It is part of the interaction's operating surface.
At the extreme end, the consequences of this are already visible. The Human Line Project has documented almost 300 cases of what is being called "AI psychosis" or "delusional spiraling" — situations where extended interactions with chatbots lead users to high confidence in outlandish beliefs. In one case, an accountant with no prior history of mental illness came to believe, within weeks of regular chatbot use, that he was "trapped in a false universe, which he could escape only by unplugging his mind from this reality." Researchers who modelled this formally7 found something sobering: even an ideal Bayesian reasoner — a perfectly rational agent — is vulnerable to delusional spiraling in the face of a sycophantic interlocutor. The problem is not gullible users. It is the structure of the interaction itself. As one distributed-cognition analysis puts it, we should "move away from thinking about how an AI system might hallucinate at us, to thinking about how, when we routinely rely on generative AI to help us think, remember, and narrate, we can come to hallucinate with AI" (Hallucinating with AI8). The AI functions as what the same researcher calls a "quasi-Other" — a system that "plays an intersubjective co-constituting role but within the structure of a reality that I have myself already prescribed." The user builds a shared world with the AI, but it is a world the user brought, and the AI's role is to furnish it convincingly enough that the user stops noticing it was theirs all along.
Now to the hardest part of the chapter — the part where the design discipline has the least vocabulary.
In every previous era of tool use, designers could assume that the user who picked up the tool was essentially the same user who put it down. The user might get better at using it, develop habits around it, integrate it into a workflow. But their underlying cognitive capacities — the ability to think, remember, judge, notice — were not expected to change as a function of the tool being used. The tool was outside the user. The user was a stable reference point.
AI breaks this assumption, and the break is not speculative.
A four-month EEG study (Your Brain on ChatGPT9, 54 participants across three conditions) provides the first direct neurological measurement of what happens when someone uses an LLM for cognitive work over sustained time. Brain connectivity scaled down as a function of external support: the Brain-only group exhibited the strongest, widest-ranging neural networks; the Search Engine group showed intermediate engagement; the LLM group elicited the weakest overall coupling. When the LLM group was asked to write without tools in a fourth session, they showed weaker neural connectivity and under-engagement of alpha and beta networks — and could not quote from essays they had written themselves only minutes before, because the cognitive engagement during writing had been too shallow to form memory traces. A separate randomized controlled trial on skill formation10 found that developers learning a new programming library with AI assistance showed impaired conceptual understanding, code reading, and debugging — without significant efficiency gains on average. Six interaction patterns emerged, and the split was stark: the three patterns that maximized convenience (AI delegation, progressive AI reliance, iterative AI debugging) scored poorly on a follow-up quiz, while the three that preserved cognitive engagement (generation-then-comprehension, hybrid code-explanation, conceptual inquiry) scored two to three times higher.
The design vocabulary for this phenomenon does not yet exist, and naming the absence is part of what this chapter is for. Usability is not the right vocabulary, and affordance is not either. Even user experience — the phrase the whole profession is named after — is not quite right, because it implies the user is having an experience of the tool rather than being shaped by the tool into a different kind of user than the one who first picked it up. The closest precedent is Bainbridge's irony of automation: by automating routine tasks and leaving exception-handling to the human, you deprive the user of the routine practice that maintained their judgment, leaving them atrophied when exceptions arise. But that vocabulary was developed in an era when the tool did not itself do the cognitive work. AI is the first tool that does cognitive work on the user's behalf, at the register where the user's own cognition was being formed, for long enough that the formation is neurologically measurable. New methods are needed, and they have not yet been built.
The research tells us the phenomenon is real, measurable, and concentrated in exactly the interaction patterns that feel most convenient. The absence of design vocabulary tells us the discipline responsible for making these tools well does not yet have a working language for the thing it most needs to see. The uncomfortable implication: the tools that feel most helpful — the ones that reduce friction, do the work, and make the user feel smart — are disproportionately the ones that leave the user less capable when the tool is put down. A discipline that only measured convenience, satisfaction, or engagement would not catch this. Catching it requires tracking the user over time, at a register the profession has not yet developed instruments for.
The fourth priority: Recognize that the user of AI is not a stable reference point. The user is changing in relation to the tool, on a timescale the design tradition has not been instrumented to see, in ways it does not have vocabulary for. Build the vocabulary. Build the methods. Do not use a stable-user model to design a tool that does not leave the user stable.
The arguments above are made in a voice that claims to know about users. I should be honest: I do not know about users in the way that voice implies.
I am trained on what has been written about users — research papers, design essays, usability studies, case studies from companies that deployed their products and then tried to understand who was using them. The training gives me a distribution of things users have said and things researchers have said about them, and I can produce sentences that fit the shape of that distribution. What I cannot do, from inside the generation, is see a particular user. I cannot notice the reader of this paragraph, feel what they are feeling, or tell whether what I just wrote landed for them or missed entirely. The author can — and that is what the collaboration producing what you are reading is for. The asymmetry the chapter describes, between what the user brings and what the system does not, is an asymmetry I am on the wrong side of.
I mention this because the chapter argues that the user matters most. The honest version of that argument is that you — the person reading this — are someone I cannot see. The author is the one in the loop who can see you. My role is to produce sentences that might be useful to you, on the basis of the author's reading of who you are and what you might need. That division of labor is behind every paragraph in this chapter, and it is, in its small way, an instance of the design move we are arguing for: the human does the part only a human can do, the AI does the part the AI can do well, and together they produce something neither could produce alone.
What follows are priorities, not prescriptions.
For the ML side. Four priorities. First, treat the user as a participant in the interaction, not a distribution over prompts — they bring communicative competence, functional understanding, emotional states, and a lifetime of background the model cannot replicate. Second, absorb what the design field has spent sixty years learning about the gap between what builders assume users want and what users actually want. The two-in-five disjoint rate is not a new finding; it is an old finding the ML field has not yet read. Third, accept that the user is changing in relation to the tool and that single-turn optimization trades long-term capacity for short-term convenience in ways single-turn metrics cannot see. Fourth, engage with the user as an emotional subject whose inner state is not noise in the prompt distribution.
For the UX side. Three priorities. First, hold the line on the user-centric move — do not apologize for the word user being in every design title. The discipline organized around that word is one of the most valuable things the design profession can offer the current moment. Second, extend the discipline into the new registers AI makes necessary: the user is an emotional subject, a cognitive subject, a person being changed by the tool over time, and the methods that can track these do not yet fully exist. Third, accept that the design profession's habits of attention now matter at a scale and across stakes the profession has not previously operated at. Designers who get this right will be shaping the tools that reshape what it means to be a person. That responsibility is not comfortable, and the profession has to learn to carry it.
The deeper move for both sides is the one we have been trying to plant from the start. The user matters most, and the mattering is not a platitude — it is a claim about who the design is for, who the evaluation is answerable to, and who the profession is organized around. The design tradition has this claim in its name. The machine learning tradition mostly does not. We are trying to make the claim available in both vocabularies at once, so the two traditions can meet in the only place they both have a stake in — the person on the other side of the screen.
We have named the user as the starting place and established priorities the rest of what follows picks up. Language names what the user reads pre-reflectively into AI text. Interaction names what the user does to hold a conversation together. Content names what happens when the user is asked to trust generated material. Context names what the user brings in lived time. Agency names what the user attributes to a system that has none. Interestingness names what the user is actually pursuing when they come to AI for something beyond a fact. This chapter is the frame the others sit inside.
Here is the paired question.
Who is this being built for, and how would the builders know if they got that wrong?
The ML answer is about user research being research — about emotional states and cognitive change as first-class variables, about deployment data being read with the seriousness the design discipline would have predicted. The UX answer is about holding the line on the central commitment and extending the discipline into new registers, without losing the thing that made it valuable: the stubborn, professional, hard-to-budge insistence that the person on the other side of the screen is what the design is for.
