UX and AI Design: Context as the Key to Relevant Design

UX Design and AI: Context as the Key to Relevant Design

Contextual UX Design: Using UX Knowledge to Inform AI-Generated Design

As more and more interface work is generated by AI, the production of research and design is shifting from documents written for humans to a carefully crafted context that guides the AI.

Context is the New UX Deliverable

AI models produce results based on context. Context encompasses everything the model can see when it performs its work: your request, along with all the instructions, standards, examples, and background information that accompany it.

Context allows you to avoid mediocre results. For example, an AI model has been trained on a large number of search screens, so when you request one, it produces an average search screen. It knows what software generally looks like, but it doesn't know your users, your domain, your design standards, or everything your team has learned through research. Unless that knowledge is included in the context, the model designs without it.

Context steers a model's output in a particular direction.

Imagine a skilled builder designing your house without ever meeting your family. They design an average house. Two stories, because most houses have two. And if you use a wheelchair, or if you have a baby who needs to sleep near you, or if you have no children and both you and your partner work from home, the design will be unsuitable in ways that affect your daily quality of life. It’s not the builder's fault; the problem is that they lacked context.

Similarly, the difference between generic AI output and AI output that aligns with your users and adheres to your organization's standards primarily lies in the context. So, what should we include?

Everyone Designs

Before answering, it's helpful to consider who uses these tools.

In many organizations, designers are no longer the only ones producing designs. A product manager asks an AI tool for a quick mockup to flesh out an idea before a meeting. An engineer asks a coding assistant to add an export feature, and the assistant decides the button's location, label, and error states. These are all design decisions made by AI.

The instinct might be to restrict who does design work, but that is counterproductive. These tools are too accessible, too fast, and too useful for transforming ideas into concrete forms. The more practical goal is to ensure that everything the AI generates, regardless of who requests it, is informed by the organization's knowledge of its users and design standards.

This goal changes the production of research and design work. Historically, UX work produced deliverables for humans: personas, journey maps, research reports, annotated wireframes. A human would read them, interpret them, and make decisions. If AI does more building, then AI becomes the consumer of research and design deliverables.

And what an AI consumes is context.

Thus, the production of research and design is primarily a context that anyone in the organization can include when using AI to generate anything from slides to prototypes to functional software. We call this creation of deliverables contextual UX design.

Contextual UX design is the practice of discovering and gathering what the organization knows and wants in the context that guides everything its AI tools generate: who its users are and the world they live in, what a product should look like, and how it should behave.

Contextual UX design also involves testing the effectiveness of this context with the models your team uses and refining the context to improve the quality of production for all.

AI-Ready Deliverables

An initial attempt at UX context might include what we already have: personas, journey maps, outcome reports. Some of these elements will be useful. But these artifacts were designed for human attention. A persona has a stock photo and a first name to help a human empathize and remember. However, a model doesn’t need to be convinced; it needs the underlying reasoning.

This reasoning can be distilled with the help of AI. It may be useful, for example, to simply provide raw research transcripts to a model and let it extract insights. Without human guidance, however, it’s possible that important elements get lost in the noise, or that the AI focuses too much on the wrong element.

To serve as maximally effective context, the production of research and design must be made "AI-ready" (or "machine-readable"), carefully selected by a qualified human, and easily accessible to anyone designing, regardless of their role.

Let’s take a concrete example. In April 2026, Google Labs open-sourced DESIGN.md, a file format for describing a product's visual identity to AI coding tools. The format comes from Stitch, Google’s AI design tool, and is now a preliminary specification that anyone can use.

A DESIGN.md file lives alongside a product's code and contains two types of content. One part consists of exact "machine-readable" values: colors, font sizes, spacing, and corner radii of the design system, written in a way that tools can read precisely. The other part is plain text, human-readable, explaining what these values are for and how to apply them, including recommendations and prohibitions, providing guidelines for both humans and AI. Google’s announcement states that instead of guessing intent, AI tools can "know exactly what a color is for" and can check their color choices against accessibility contrast standards.

This serves as a successful example of a format for UX context and provides some lessons. It’s a text file, kept alongside the code, that AI tools read every time they generate something. Unlike traditional deliverables, there is no handoff: UX context directly feeds into product creation.

But visual identity is just one part of user experience and product design. What about all the other research and design that informs product building?

A Hypothesis: UX.md

Let’s imagine another text file, with a broader intent than DESIGN.md. We’ll call it UX.md. It would reference DESIGN.md for visual standards and indicate where the actual components of the product are located in the code. However, it could also include elements such as:

• Research Synthesis. Key findings, stated as clear insights on which the AI can reason. "Users abandon setup when asked for information they don’t have on hand" is a conclusion that becomes a constraint on what is generated, not just an insight in a report.

• Interaction Standards. How the product behaves. When to confirm or allow cancellation. How errors are phrased. Whether the user interface is optimized for expert users or novices.

• Glossary. The words that the product and its domain experts use, with definitions. If your users say "case" and are confused by "ticket," the AI needs to know.

• User Models. User modeling indicates what research has established about the users themselves: their expertise, concerns, what they are trying to accomplish, what doesn’t work for them.

• World Models. World modeling includes the conditions in which the user finds themselves when using the software. (The term is borrowed from AI research, where a world model is the understanding of a system of real physical environments.) For UX purposes, we model the circumstances of the world in which users live (i.e., "the context of use") and how they may change: users are interrupted during tasks (a nurse in a hospital), are under pressure (filing a claim after a car accident), or operate under compliance rules (every action must leave an audit trail).

DESIGN.md shows how visual design standards can be made available to AI tools. UX.md is a broader hypothetical version of the same idea: a structured source of UX research, interaction standards, terminology, and knowledge about the context of use that AI tools can use when generating product work.

Suppose your research synthesis indicates that users work in the product for hours, making complex decisions with many variables. This conclusion should steer generation toward denser screens that keep more information on display, the type that expert users prefer. A conclusion that the product is used for a few minutes a month should prompt the AI to suggest fewer choices per screen. An AI without this context will settle for what is most common in its training data.

Of course, for large projects, a single file may not be sufficient. Instead, UX.md could serve as an index to a folder of context files, each used for a specific purpose. Or you might make the context available via MCP servers and agent skills, or through another method.

Since context steers AI generation, this approach has an interesting side effect: research insights and design standards find their way into unexpected places. For example, user glossary terms may appear in the code behind the scenes, rather than terms that engineers might have chosen themselves. The production of research and design becomes integrated wherever AI is used.

Curation, Not Handoff

By taking a cue from what we’ve learned from DESIGN.md, we see two important properties of an artifact like UX.md that differentiate it from traditional research and design artifacts.

First, it is not written for humans. People can read it, but its success is measured by the improvement of AI production, not by stakeholder buy-in. This could become a measurable standard, a metric you can track over time.

Second, it is not separate from the product. It lives with the product code, changes when the product changes, and is read by every AI tool in the organization every time something is generated. Research and standards are present whenever anyone generates anything, whether that person is a designer, a product manager, or an engineer.

This is not an artifact that is set aside over time, or handed off to other humans, but a continuously updated source of truth. UX.md (or its equivalent) is never finished. New research updates it, just as observing where the AI goes wrong does. It is ongoing research and ongoing design, accumulating in one place for the entire organization.