The Window, the Mirror, the Collaborator

The Window, the Mirror, the Collaborator

Mara Okafor had been a senior product designer for eleven years when she opened Figma on a Tuesday morning in March 2022 and felt, for the first time in her career, that she had no idea what to do. The canvas was white. The cursor blinked. Her brief from the product team was three lines long: "Help users onboard faster. Use AI if it helps." The cursor kept blinking.

She was not new to AI. She had shipped three machine-learning features in her career — a recommendation carousel, a churn model that surfaced retention offers, a search re-ranker. She understood confidence thresholds and A/B tests and the politics of model ownership inside large organizations. But those features had been bolted onto a product. They lived behind a button. The rest of the interface, the part she spent ninety percent of her time on, was the same interface she had been designing since her first internship: screens, buttons, flows, error states. Deterministic. Predictable. Hers.

That brief changed something. "Use AI if it helps" was the kind of sentence that sounded casual and was not. It implied that the product itself — not a feature, not a panel, not a model that lived in a corner — could become the medium through which the user accomplished their goal. It implied that the canvas in front of Mara, the white rectangle she had been trained to fill with rectangles, might not be the right surface at all.

Her first attempt, two weeks later, was a chatbot. She designed a chat panel in the lower-right corner of the existing product, gave it a friendly name, wrote a system prompt that would be invisible to the user, and specified twenty-three intents it could recognize. It was a good design by the standards of 2021 — clear typography, a subtle entrance animation, a graceful empty state, a careful escalation path to a human agent. It launched in June, and the data came back six weeks later: fourteen percent adoption, an average session length of forty-three seconds, and a customer satisfaction score three points lower than the legacy help menu it had been meant to replace. The qualitative research was worse. Users described the chatbot as "the thing in the corner that doesn't work." Mara, who had spent four years learning to be skeptical of her own instincts, read the transcripts and understood. She had built a feature. She had not built a product.

Three years later, in a different office, in a different city, Mara is the head of design at a company whose product is, in her words, "a collaborator you can talk to." She does not use Figma the way she used to. She does not draw user flows the way she used to. She does not write design specifications the way she used to. What she does, and what she has spent those three years learning to do, is the subject of this book.

This chapter is about the question her Tuesday morning asked: what fundamentally changes about product design when the software itself becomes capable of reasoning, planning, and acting? It is a question that has no precedent in the history of interface design, because until very recently, software could not do any of those things. It could store data, retrieve data, transform data, and render data. It could not reason. It could not plan in the human sense. It could not act outside the boundaries of what it was told to do.

We are now living through the first decade in which all three of those capabilities are real, and the design profession has not yet caught up. The tools have changed faster than the vocabulary. The products have changed faster than the heuristics. The companies shipping the most ambitious AI-native products are doing so with design practices inherited from a paradigm in which the machine was a calculator, not a colleague. The result is a generation of products that are simultaneously more capable and more confusing than anything that came before — more capable because they can do things no previous software could, more confusing because they violate every expectation that fifty years of graphical interfaces have trained users to hold.

This book is an attempt to build a new vocabulary. We will move from prompt to plan, from autocomplete to autonomy, from feature to paradigm. We will examine what works, what doesn't, and what we still don't know. We will look at the products that are getting it right and the ones that are getting it badly, and we will extract from both a set of principles that can guide the next generation of design work.

We start here, with the question, and with the three lenses through which every interface in history has been understood: as a window onto a system, as a mirror of the user, and, now, as a collaborator with both.

The three paradigms: how the locus of decision-making moves

To understand what an AI-native interface is, it helps to see it in contrast to what came before — not as an evolution, but as one of three distinct paradigms, each defined by where the decision-making power sits, and each requiring a complete re-architecture of the designer's mental model.

Paradigm 1: The tool (1960s–1980s) — decision-making lives in the human

The first paradigm is the command line. In the tool paradigm, the human issues explicit instructions, and the machine executes them exactly as given. The locus of decision-making is entirely on the human side. The machine does not decide anything. It does what it is told, and if what it is told is wrong, it does the wrong thing with mechanical precision.

The interface metaphor here is the window — a clear, narrow aperture through which the human peers into the machine's state. The human must form a complete mental model of what they want, translate it into the machine's language, and inspect the result. The machine offers no help, no inference, no suggestion. It is, in the most literal sense, a tool — an extension of the human's will, no more autonomous than a hammer held in a hand.

This paradigm produced extraordinary software. Operating systems, compilers, databases, every foundational layer of the modern stack was built by people operating in this mode. But it required extraordinary humans. The cost of using a tool-interface was cognitive: you had to know what you were doing, and you had to know it precisely. The population of people who could use such interfaces was small, and the population who could use them well was smaller still. Unix wizards were wizards precisely because the interface made wizardry a prerequisite.

The deeper limitation was not the learning curve but the ceiling. In a tool paradigm, the human is the bottleneck on every action. The machine does not suggest, does not anticipate, does not remember. Every capability the user has is a capability the user brought with them. The machine amplifies skill; it does not extend it.

Paradigm 2: The system (1980s–2020s) — decision-making is shared, but the human retains veto

The second paradigm is the graphical user interface. In the system paradigm, the human expresses intent through manipulation of visual representations, and the machine interprets those manipulations and translates them into operations. The locus of decision-making is shared: the human chooses what to click, drag, or type, but the machine decides what those actions mean, validates them, constrains them, and provides feedback.

The interface metaphor here is the mirror — a surface that reflects the user's intent back at them in a form they can recognize and refine. The user sees their goal represented as a document, a spreadsheet, a drawing, a form, and they manipulate that representation. The machine tracks the manipulation, maintains the underlying state, and shows the result. The user is the author; the system is the stage.

This paradigm also produced extraordinary software. Spreadsheets put financial modeling in the hands of anyone who could point. Desktop publishing put typesetting in the hands of writers. Photo editors put d