The Expanding Designer

Parts 1 and 2 looked at the product. This one is about our work as designers. More of the questions I encounter now involve data, agent behaviour and language. I am still learning how to work in those areas, and thinking about what I need to carry forward from product design.

Professional change can be uncomfortable when it takes you away from work you know well. Leading a team does not make the unfamiliar parts easier.

I fell in love with design because of the influence it gave me. You do the research, you talk to users, you understand the problem deeply enough to walk into a room of engineers and product managers with a clear point of view, and the conversation shifts. I spent years building that kind of credibility in companies that did not hand it to designers. Learning how to connect what users actually need with what the business is trying to do, and making that connection feel obvious in the product.

Understanding customers and making complex products usable remain central to design, while more of the work now involves actions that happen beyond a visible interface. We need to consider how software makes decisions on someone’s behalf and how that person understands the result.

I think a lot of design leaders are feeling this and not naming it. We talk about "upskilling" and "adapting," which are fine words. But underneath them there is often something quieter: the experience of watching your role grow faster than your confidence in the new parts of it.

I see four areas where designers can contribute, and where we need to work more closely with other disciplines.

More of my time now goes into questions about product behaviour and responsibility, including:

"What should the agent be allowed to do without asking?"

"When this process goes wrong at 2am, what does the user see at 8am?"

"How do we structure this data so an agent can actually use it?"

"What does this product’s personality sound like when it is explaining a mistake?"

These questions shape the experience of using a product while drawing on product strategy, content design and systems architecture. For designers, that overlap creates a need to develop new skills and work more closely with the people who understand those areas.

Design leaders need to make room for this learning while holding the team to a clear standard for what ships.

Here is how I have been thinking about it. The designer’s role is stretching in four directions simultaneously. You do not need to go deep in all four. But you need to be aware of all of them, and you probably need to develop real capability in at least one or two.

Direction 1: Down into the data layer

This is the one that feels most unfamiliar to product designers, and also the one I think matters most right now.

When an agent interacts with your product through an API, it is using your data rather than your visible interface. The labels on your fields, the structure of your content model, the consistency of your API responses. If those things are messy, the agent experience is terrible, and by extension, the human experience is terrible too, because the agent is going to make bad decisions on bad data and the human is going to be the one dealing with the consequences.

Designers need enough understanding of data to recognise when a content model has ambiguous labels, inconsistent meanings or relationships that could confuse an agent. Engineering expertise remains essential, and design can contribute a useful perspective on whether the information is understandable.

A practical starting point is to ask an engineer to walk through the fields, relationships and labels behind a feature during a design review. Examining that model together helps the team identify where the information is clear and where it may support conflicting interpretations.

Direction 2: Into behavior design

This one is less about what the product looks like and more about how it acts. When an agent makes a decision, that decision was shaped by rules someone defined. "If the price drops below X, pause the order." "If the confidence level is below Y, ask the user." "If two data sources conflict, flag it instead of guessing."

Those rules shape the experience as directly as the screen that shows the result. Designers need to work with product managers and engineers on them, including how to test whether a rule behaves as intended.

I have started writing behaviour specifications alongside visual designs to describe when an agent should proceed, act cautiously or stop for a decision. These documents give the team concrete scenarios to discuss and test, making expectations about the experience explicit before implementation.

Direction 3: Into language and conversation

When someone interacts with an agent through language, the wording affects what they understand and how they respond.

Language shapes how an agent explains its actions, admits uncertainty, asks for help and communicates a failure. Those exchanges require the same attention as the other interactions through which a person understands the product.

Writing has become a more central part of my design practice because the way a system communicates can provide continuity even when its interface changes. A consistent, understandable voice helps people interpret what it is doing across different situations.

Direction 4: Into trust and ethics

This is the direction that sounds the most abstract but might be the most consequential for our careers long-term.

Teams need practical decisions about when agents may act independently, how they explain their reasoning and how they handle sensitive information. These choices affect whether the behaviour matches what customers expect and are willing to permit.

Design can help a team examine those choices from the customer’s perspective while working with engineering, product, security and legal specialists on the requirements involved.

Research and experience design give us useful ways to test these decisions. We can ask what someone expects, what they understand and where they lose control, then bring those findings into the team’s choices.

The work is changing, but I still rely on research, judgment and care in execution.

Empathy remains central to the work. Understanding what might confuse, reassure or frustrate someone helps us assess an agent’s behaviour just as it helps us evaluate a visible interface.

Judgment still develops through close attention to people using products. The experience of watching customers struggle with something that seemed clear helps a designer notice when a system’s behaviour may feel confusing or inappropriate, then turn that concern into something the team can investigate.

Craft applies to the decisions behind the interface as well. Whether we are refining a visual system, specifying agent behaviour or writing an explanation of a failure, the work needs care, precision and a clear understanding of the person affected.

The standard I want to carry forward is care for the person affected by a product decision, whether they see a screen or only its result.

These are a few practices I have found useful.

Start building things, even if they are small. AI tools have made it possible for designers to prototype functional products without being full-stack engineers. I use tools like Cursor and Lovable to make an idea concrete enough to discuss with the team. A working prototype exposes questions about data and behaviour that a static mockup can leave open.

Define agent behaviour alongside customer needs. Describe when an agent should be cautious, which actions require approval and how it should communicate uncertainty, so the team can discuss and test those expectations.

Join engineering discussions that shape the experience. Conversations about data models, API design and agent behaviour help build the context a designer needs to contribute to decisions that may never appear in a screen design.

Practise writing the agent’s side of a conversation. Work through routine tasks, uncertainty and failures to understand what the person needs to know and what choice they should have at each point. This can reveal situations that a wireframe alone leaves unexplored.

Allow time to develop unfamiliar skills. Early attempts at data models, behaviour specifications or agent communication will need revision, and a team benefits from being able to examine those drafts openly and improve them through feedback.

I do not know exactly what the designer’s role will look like in five years. For now, I want to understand enough about data, behaviour and language to make useful decisions with the team, while staying close to the people affected by those decisions.

Writing this series has helped me make those questions more concrete. I would like to hear how other designers are approaching them in their own teams.