What Do Designers Do When Designing AI Products?

The nature of design work is changing.

As we progress further into the AI era, many of us are observing a shift in what it means to design software products and experiences.

Designers increasingly face problems which extend beyond screens, flows and interactions. They now find themselves tasked with shaping systems which are able to interpret intent, that generate unpredictable or variable responses, and operate by combining vast reservoirs of knowledge with local pools of data. The primarily forms of interaction have moved beyond static interfaces towards natural language and dynamic interfaces.  Some systems take action with a degree of autonomy, use tools and coordinate activity across services.

These characteristics change the scope of design, requiring new activities and new types of design artefacts. Interfaces are still a central concern, but now we now need to consider new challenges, such as the behaviour of a model when faced with uncertainty, the quality and authority of a system’s knowledge, and the division of responsibility between people and AI.

Design questions such as these have surfaced repeatedly in recent projects I have worked on, and in the conversations I have with designers, engineers and product people around me. Together, they suggest to me a broader definition of design that expands the work of designers beyond the interface and towards a concern with the whole system.

This whole-system-thinking approach is not new. It is a foundational tenet in human factors and human-computer interaction disciplines. However, it has been sadly neglected in recent years as design work has, in some organisations, been relegated to little more than arranging Figma components. I believe the new challenges of AI design demand a return to this expanded approach.

To get my head around this expanded new design space, I have found it useful to organise my thinking, and work, into eight connected dimensions that represent the new objects of design: Purpose, Ecosystem, Knowledge, Workflows, Behaviour, Interaction, Boundaries and Evolution.

Purpose

The design journey begins by establishing why an AI system should exist. Much of this work will feel familiar to experienced designers and product teams. User research and contextual research are still critically important, as are core activities such as problem framing, stakeholder alignment and product strategy. AI adds a new pressure, because teams can now use AI coding tools to move between idea and plausible prototype with blistering speed.

A fluent demonstration creates a strong impression of progress. However, technical feasibility provides little evidence of product value. Just because you can build it, doesn’t mean you should. Before development gathers momentum, teams need a clear account of the problem, the people affected and the outcome worth pursuing.

Purpose work examines the value AI is expected to create and the suitability of AI for the work involved. It also considers the degree of autonomy appropriate for different tasks. Purpose work begins by establishing clarity of value, and definitions of success and failure.  It continues iteratively throughout the project as designers build and test prototypes in real-world settings to evaluate and understand the value of their ideas.

A concise purpose statement gives the work direction. Equally useful is a definition of what sits outside the system’s purpose – what it should not do.  Unlike pre-AI software where we define only what software should do, now a key part of our work is to define and boundary what it should not do, and what it should not be.  The negative space becomes an important part of the requirements.

Purpose provides the first test of an AI idea. The result might be a stronger proposition, a narrower scope or a decision to stop. Purpose is especially critical when organisations can spend weeks building AI products before discovering that no one needs or uses them.

Ecosystem

AI systems enter organisations, services and social environments which already have their own structures, systems and routines. They affect the people using them directly, along with having an impact on customers and colleagues. Once introduced, AI changes work and alters relationships between teams. Likewise, the existing technology, policies and operating models shape the systems requirements and will affect the way the system performs once it goes live.

Design work needs to be mindful of these ecosystem impacts.  A productivity gain in one part of a service might create additional workload elsewhere. Introducing automation has impacts on teams, changing how expertise develops, where accountability sits and which teams absorb exceptions.

Designers therefore need to take a wider socio-technical view of the product. Service design, systems thinking and field research become especially valuable here. The aim is to understand how work happens in practice, including informal processes, tacit expertise, workarounds and dependencies which formal documentation often misses.

Current-state service blueprints provide one useful representation of this environment. Future-state versions make proposed changes easier to examine before implementation. Work-impact maps add another perspective by showing how roles, responsibilities and workloads are likely to change.

Designers rarely have to own organisational change, workforce strategy or operating models. However, their contribution is critical because they make consequences visible early enough for the organisation to respond thoughtfully.

Knowledge

AI turns knowledge into a central design material.

Traditional UX has always involved information architecture, content strategy and questions about what people need to know. AI extends this concern because the system itself also depends on knowledge and operates both through access to the knowledge within the model itself, as well as the documents and datasets that are made available to the system.

Massive datasets do not necessarily result in the right outcomes.  Access to a large collection of documents does not produce reliable understanding. Sources may conflict. Policies may expire. LLMs can work across large volumes of data, but they need supporting structure to interpret the hierarchies, provenance and relationships that make the data meaningful.

Designers therefore need to help define what the system needs to know, in order for it to achieve its purpose.  As they design how journeys and experiences unfold over time, they will define what information is critical for each stage to be navigated effectively. They may outline which sources should carry authority and where gaps or uncertainties exist. They may also need to help shape how data is structured, classified and related so the system can use it reliably. This work depends on close collaboration with subject matter experts, data specialists, engineers and risk teams.

The important outcome is a clear account of the knowledge required for real user tasks. Information-needs maps show how different information and datasets relates to different user needs, grounding data engineering in real user needs.  A source inventory shows which documents, systems, databases the AI may need to draw on to solve different use cases.

Knowledge design also defines what happens when evidence is weak. A responsible system should recognise the limits of available information and respond appropriately rather than producing a plausible answer unsupported by evidence.

Workflows

Knowledge becomes useful when the system applies knowledge within work.

AI products increasingly involve sequences of activity distributed across people, models, tools and existing software. A request might need interpretation before retrieval begins. Retrieved information then supports analysis, which might lead to a recommendation, a draft or an escalation.  The AI may use a tool, call an API or search the internet to draw external information. Human approval often sits between preparation and action.

AIs are not simply chatbots left to run free.  They have workflows which must be orchestrated into structured sequences of action. Someone needs to design this sequence.  This is not simply an engineering task.  Designers must design how the experience unfolds over time, providing the necessary requirements for engineers to build the orchestration layer.

Traditional task flows and journey maps still provide useful foundations. AI workflow design extends them by representing what the system does as well as what the person does.  For this, human factors methods such as partitioned operational sequence diagrams are useful in representing the flows of tasks and information between the user, the system and the external environment.

The designer must consider the division of labour, providing a clear view of where AI participates, how much autonomy different tasks require and where human judgement should remain central.

Designers must also consider the internal sequences or orchestration within the system. Retrieval, model calls, tools, state, approval points and handoffs shape the experience even when users never see most of the underlying machinery. An orchestration map helps the team inspect these relationships and connect technical implementation with service intent.

Failure deserves equal attention. Missing information, conflicting sources and unsuccessful tool calls all need recovery paths. Agentic workflows also need clear stopping conditions and points where responsibility moves back to a person. Good workflow design gives structure to intelligent work instead of leaving the sequence to emerge by chance.

Behaviour

AI introduces another design concern which traditional product work has rarely named so explicitly: behaviour.

AI systems explain, ask questions, recommend, refuse and escalate. Some use tools or take action. The quality of the experience depends on how the system conducts itself across different situations. Tone is a part of this, but only one part.

Behaviour includes how the AI responds when evidence is weak, how the system separates facts from recommendations and how much initiative the system takes. It covers different scenarios and use cases, such as clarification, refusal, escalation and recovery after an error. It also includes clear boundary definitions for what the system should not do, or how it should not behave, especially in certain contexts or scenarios.

A behavioural contract provides one useful way to make these expectations explicit. The contract defines the system’s role, authority and core conduct in plain language before those decisions become distributed across prompts, workflow logic and technical controls.  Designers may also create conversation design blueprints.  These artefacts map out how the interaction should unfold, how the AI reasons, responds and interacts with the user at different stages of the interaction, and what happens under different edge cases.

Context matters because appropriate behaviour changes through the course of a task. A system clarifying a request should behave differently from one presenting a recommendation. Escalation requires another pattern again, with enough context preserved for the next person to continue the work responsibly.

Behavioural prototypes make these choices visible early. These can be built quickly using OpenAI’s Custom GPTs or Claude Projects by uploading a system prompt and some basic documents and datasets to work with.  Teams can then test how the system responds across ordinary, ambiguous and high-risk situations before translating the preferred behaviour into specifications and evaluation scenarios.  These form the basis for production-level requirements and system evaluations.

Interaction

Interactions and interfaces are one of the most recognisable areas of design practice.  But AI changes the nature of the interface. Interfaces are now collaboration surfaces as much as they are control surfaces.

Chat has become strongly associated with AI products, partly because conversational interaction supports broad requests and open exploration. However, many forms of work need more structure.  Some moments need to to provide specific feedback to the user or constrain the user into a clear set of choices, while in other moments the user needs to be given more control.

For instance, a person reviewing an important recommendation needs evidence and clear status information. Consequential actions often require explicit approval. Supervising an agent requires visibility of progress and intervention points. Some complex tasks such as information comparison tasks benefit from structured views rather than lengthy conversations.

The interaction models used within the product should therefore be suitable for the task at hand. Some products will use conversation. Others will work better through an inline copilot, a side panel or a structured workspace. More complex systems often combine several modes.

Detailed interaction design then focuses on how users express intent and how outputs are presented. Evidence, uncertainty and system status need clear representation. People also need ways to correct the system, stop an action and challenge a recommendation.

AI also changes prototyping. Static screens reveal only part of an experience built around variable responses and changing state. Designers increasingly need prototypes which represent behaviour over time, including clarification, evidence retrieval, approval and failure. The behavioural prototypes described above are useful for designing and testing conversational behaviour, but they have limitations because they lack the context of the interface that that users will be working with. Using AI coding tools, designing should be building fully functional AI prototypes, or at least they should be working closely with engineers to build these, in order to test and explore ideas in the real world.

Boundaries

AI systems require explicit limits. Some limits arise from law or regulation. Others come from organisational policy, security requirements, ethical commitments or the intended purpose of the product. These constraints need translation into system behaviour.

Information access needs clear rules. Action authority also requires definition, especially where the AI influences consequential decisions or changes records in another system. Human review needs a meaningful role rather than becoming a routine approval step with little opportunity for scrutiny.

Designers contribute by making boundaries understandable at the point of use. Permission models, approval patterns and refusal behaviour all shape how people understand the authority of the AI and their own responsibility.

Technical controls are also important. Prompts alone provide weak protection for important boundaries. Permissions, workflow logic, retrieval rules and audit mechanisms need to reinforce the intended limits.

Good boundary design makes restraint part of the product rather than an external policy applied after the main design work.  While the ultimate responsibility for boundaries may fall to risk, compliance or product owners, designers must understand that boundaries impact almost every aspect of the system design and must weave this work through each decision.  Throughout their discovery and design work, designers should be documenting the boundaries they uncover in a system obligations map.  These should form the basis of the evaluations used to test whether the system stays within its intended limits, handles edge cases appropriately and fails safely when those limits are reached.

Evolution

Launch does not freeze an AI system.  Models change. Knowledge ages. Prompts might be revised. New documents or datasets may be uploaded.  New tools or skills may be added. User behaviour develops in unexpected directions. Organisational policies also shift, sometimes changing the conditions under which an existing behaviour remains acceptable.

Design therefore needs a lifecycle perspective. Teams need a baseline for expected behaviour and a way of monitoring performance after release. Evaluation should continue as the product changes. Feedback and incidents need routes into the design process, with clear ownership for investigation and improvement.

Changes to models, prompts, knowledge sources or tool permissions deserve particular care because each one alters some aspect of system behaviour. Sometimes evolution means extending the product. In other cases, evidence points towards narrower scope or tighter boundaries. Retirement also forms part of lifecycle design when a capability no longer performs safely or serves its purpose.

This turns stewardship into part of AI design rather than a concern reserved for operations after launch.

Putting the dimensions together

The eight dimensions do not form a linear process. They describe different views of the same system and influence one another throughout design and delivery.

Purpose gives direction to the work. Ecosystem establishes the organisational context and reveals who will be affected, and what will impact the system. Knowledge defines the information and expertise the system needs. Workflows organise how intelligence is orchestrated over time to participate in tasks and services.

Behaviour describes how the AI conducts itself within those workflows. Interaction gives people a way to understand, guide and control the system. Boundaries establish its limits, and Evolution provides the discipline needed to keep the system aligned after release.

Taken together, these dimensions suggest a broader scope for AI design.

Designers still shape interfaces, flows and experiences, but for AI products, the interface is no longer the whole product. Their work increasingly reaches into the definition of the system itself: why the AI exists, what the AI understands, how work is divided between people and machines, how the system behaves, where authority ends and how the product changes over time.