A few months ago, my product manager dropped something in the team channel. "We are adding an AI agent to the platform next quarter. It will handle follow-ups automatically." Just like that. One message. No design brief. No flow. No spec.
My first thought was: great, I will design the screens for it.
My second thought, about three days later: wait. What screens? The whole point is that the system acts on its own. The user is not clicking anything. So what exactly am I designing?
That question changed how I approach product design. And I have not gone back since.
"Your job used to be: make the path clear. Now your job is: make the behaviour trustworthy. Those are not the same job."
The World Changed. Most Design Processes Did Not.
Let me describe what most of us were trained to do.
User wants something. We map the journey. Design the screens. User clicks. System responds. Done. The software was always passive it sat there and waited for a human to tell it what to do.
That was a clean model. We got good at it.
But now software has started acting without being asked. It sends emails on your behalf. It books meetings. It files reports. It summarises conversations. It flags issues. It reorganised data. And it does all of this while you are doing something else entirely.
💡
"We spent decades designing what happens when someone clicks a button. Now we have to design what happens when nobody clicks anything at all."
This is not a small update to the design process. It is a completely different problem. And here is the uncomfortable truth: most design teams have not caught up yet.
They are still running the same process. Map the flow. Design the screens. Hand off to engineering. But the flow is no longer a straight line from A to B. The system is making decisions in the middle. And if those decisions are not designed well, users will not know what happened, will not know how to fix it, and will quietly stop trusting the product.
💡
THE REAL PROBLEM: When software acts on its own, the interface is no longer just the product. It becomes the relationship between a person and a system that is making decisions for them. Designing that relationship is completely different from designing a screen.
What Actually Goes Wrong
Let me give you a real example. Not a hypothetical. Something that has happened in one form or another across dozens of products.
The 47 Emails
A recruitment platform adds an AI agent. Its job: follow up with candidates who have not responded in three days.
A recruiter sets it up on Monday morning. By Wednesday, the agent has sent 47 follow-up emails. The recruiter is happy — that is 47 manual tasks done.
Then the complaints start coming in.
Six of those candidates had already responded. Just on WhatsApp, not through the platform. The agent did not know. It sent a follow-up anyway. The message read: "We noticed you have not responded to our previous message."
Candidates who had already said yes were now being told they had not responded. One withdrew their application because of it.
The recruiter could not see which emails were sent. Could not undo any of them. Could not even tell the agent to stop without turning the whole feature off.
The AI worked exactly as built. The design failed completely.
Notice what went wrong here. It was not the model. The model did its job. What failed was everything around it, the visibility, the control, the ability to recover. Those are design problems. Not engineering problems.
And this is what I see happening everywhere right now. Teams are so focused on making the AI capable that they forget to make it trustworthy. They design the impressive demo and ship it. But real users are not in the demo. They are in the messy, unpredictable, multitasking reality of their actual workday. And when the AI does something unexpected there, they have no way to understand it, no way to stop it, and no way to fix it.
"People are surprisingly forgiving when software makes a mistake. They are not forgiving when software makes a mistake and then hides it."
Trust does not break because an AI is wrong sometimes. Trust breaks because the user does not know what happened, why it happened, or how to make sure it does not happen again.
That is a design failure. Every time.
The Behaviour Design Stack
After working through several autonomous features, I started building a checklist for myself. Something to run through before touching Figma. Over time, that checklist became a framework.
I call it the Behaviour Design Stack. Five layers. You work through them in order. Skip one and your autonomous feature will eventually break down not technically, but experientially.
Here is each layer, what it means, what goes wrong when you skip it, and how to actually solve it.
Layer 1 — Define the Boundary
Before designing anything, answer three questions in plain language:
What can the system do without asking?
What must it always ask before doing?
What should it never do, regardless of confidence?
Write these down. One page. Share it with the team before any design work starts. This is a design decision, not an engineering one. If this document does not exist, you should be the one asking for it.
Real example: a task management app built an AI that archives completed tasks older than 30 days. The team wrote it out clearly archive is fine, delete is never automatic, anything user-flagged is excluded. Three rules. That document prevented two production disasters before they happened.
WHAT GOOD LOOKS LIKE
✓ Auto-send low-priority internal notifications — no confirmation needed
✓ Draft external emails for review — show, do not send
✗ Delete any data automatically — never, even with high confidence
✗ Send messages to external parties — always requires human approval
Layer 2 — Make the Decision Visible
Traditional interfaces explain results. Autonomous systems need to explain decisions. Those are not the same thing.
Compare these two messages from the same AI agent:
VERSION A — RESULT ONLY
"Follow-up emails have been sent."
The user has no idea who received them, why, or whether the timing was right.
VERSION B — DECISION VISIBLE
"Follow-up sent to 12 candidates with no activity in 72 hours. 3 were skipped, they had open conversations on another channel."
Now the recruiter can check the logic, spot anything off, and course correct.
The second is not more complicated. It is more respectful. It treats the user as someone who delegated a task not handed over permanent control.
My test before shipping: if a user wants to know why the system did something, can they find out in under 10 seconds? If no, this layer needs more work. And remember strategic silence is also design. Narrate the ambiguous moments. Stay quiet when things are running smoothly.
Layer 3 — Design Recovery Before Autonomy
Most teams skip this layer. They design the capability, test the happy path, ship it. Recovery gets planned for "later." It almost never arrives.
My rule: design the recovery experience before the capability itself. Here is why.
"The undo button does not just help users recover from mistakes. It is the reason they were willing to delegate in the first place."
Think about how freely you edit documents today. You restructure, delete, try things all without hesitation because Ctrl+Z exists. That safety net makes you bolder before anything goes wrong. Autonomous products work the same way. Before any autonomous feature launches, these four must have answers:
How does the user see what the system did? A clear activity log. Surfaced in the feature itself, not buried in settings.
How do they undo one action? A single undo, tied to the specific action, available right after it happens.
How do they pause or stop it? A visible pause control. Next to where the agent is working, not hidden in account settings.
How do they restore a previous state? A recovery window for anything involving data.
Cannot answer all four? The feature is not ready to ship.
Layer 4 — Match Friction to Risk
Two ways most teams get this wrong. Too many confirmations: users click through without reading and the guardrail becomes noise. Too few: the system acts on high-stakes decisions with no human checkpoint, and when it is wrong, the damage is already done.
The answer is a deliberate friction model:
Low risk + reversible | Act silently. Report afterwards. Archiving files, tagging emails, generating summaries. No approval needed. |
Medium risk + reversible | Recommend, require one tap. Draft the email, show it, wait for approval. One action. No long modal. |
High risk + irreversible | Always ask. Always explain. External emails, payments, deleted data. These gates never get removed — regardless of AI confidence. |
System is unsure | "I was not confident about this one — do you want to handle it?" Honesty here builds more trust than a system that pretends to be certain. |
That last row is the one teams almost always miss. A system that admits uncertainty is not a failure. It is a trust signal.
Layer 5 — Let Trust Grow Gradually
Teams build a powerful AI feature and set it to maximum autonomy on day one. New user signs up. The agent immediately starts acting on their behalf — before they have had a single chance to see whether it can be trusted.
That is backwards. Trust is not given. It is earned. Here is the model I design towards:
Suggest | AI recommends. User decides. Every action explicit. Start every new user here. |
Confirm | AI proposes, acts after one tap. Earned after consistent, reliable suggestions. |
Delegate | AI acts within defined rules. User monitors and can intervene. Earned over time. |
Autonomous | AI runs continuously. User only steps in at boundary moments. Never granted on day one earned slowly. |
And when trust breaks design the ramp down. Let users dial back to a lower level instead of abandoning the feature entirely. One mistake should be recoverable. Without this, it becomes a permanent exit.
Questions I Ask Before Opening Figma
Before I was thinking about autonomous products, my pre-design questions were mostly visual. Where does this live in the nav? What does the empty state look like? How does this work on mobile?
Those still matter. But they are not the first questions anymore. These eight are:
What decision is the system making? Not what action, what decision. Decisions carry judgement and risk.
How confident is the system and does the interface reflect that confidence honestly?
What happens if it is wrong? Can the user understand it? Can they recover?
Does the user know why the system did it, not just what it did?
Can they pause it mid task, not just after?
Can they undo what the system did? What is the recovery path?
What should always require explicit human permission?
What should stay invisible because it is not worth interrupting the user over?
These eight questions have stopped me from shipping three features that would have damaged user trust not because the features were bad, but because they had not been thought through from the human side.
What This Actually Means for You
This is not about AI replacing designers. It is not about learning to code or understanding language models. It is about one thing: expanding what you consider your responsibility.
Designing an autonomous feature and only thinking about the UI is like designing a car and only thinking about the dashboard. The dashboard matters. But if the steering does not respond correctly, the dashboard is irrelevant.
The steering in autonomous products is the behaviour. How the system decides. When it acts. When it pauses. How it explains itself. How the user recovers when it is wrong.
"The designers who will matter most in the next five years are not the ones who make the interface look better. They are the ones who make the system feel trustworthy."
I still spend most of my day designing interfaces. I still care about typography, spacing, hierarchy, and all the small details that make a product feel considered. None of that has become less important.
But it is no longer the whole job.
The Screen Is Still There. But Something Behind It Is Moving.
If software is going to make decisions on behalf of people, then someone has to decide how those decisions feel. Someone has to decide when confidence becomes overconfidence. Someone has to make sure the person on the other side always feels in control even when they are not the one doing the work.
That is our job.
Because in products where software can act on its own, designing the interface is only half the work. The other half is designing behaviour.
And that work starts long before you open Figma.
I do not have all of this figured out. Nobody does this is genuinely new territory. But I know one thing: the designers who ask "how does this feel when it fails?" before "how does this look when it works?" are the ones building products people will actually trust.🎯
