What does a UX designer actually do on an AI product?

Micah Boswell · Lead Experience Design, AT&T · designing for AI · September 2026

The designer decides what happens at the moment a person is asked to accept what the machine just did. Where the source shows. What a wrong answer costs. Whether there is an undo. The model is somebody else's job. The second question, the one a person asks right after the first wrong answer, is the whole job, and most AI products never design for it.

I keep a case file on this site with no client named in it, because it is a composite of things I have watched happen more than once. An ops copilot. The demo dazzled leadership. Six weeks later, eight percent of the seats were still using it.

The model was fine.

Here is where the people went.

• 40%left at the first wrong answer. No source shown, nothing to check it against.
• 23%left at paragraphs where a number would have done.
• 15%left because the truth of their work lives in a ticket, and the assistant lived in a different tab.
• 8%left because there was no draft state and no undo. Every suggestion was a commitment.

None of those are model problems. All four of them are the second question.

Why do AI features get abandoned?

Everyone plans for the first question. The prompt box, the welcome line, the demo where the machine gets it right on a stage. Nobody plans for the second question, which is the one a person asks the first time the machine is wrong. Where did that come from. Can I see it. What happens if I say no.

The engineers I design for provision network circuits for a living. They have asked that second question of every tool they have ever been handed, and they ask it fast, because a wrong yes in their world is not a typo. It is an outage with a ticket number. An assistant that cannot answer the second question is not an assistant to them. It is one more tab.

That is the part that took me thirty years to say plainly. Trust is not a feeling the product earns over time. It is a decision a person makes in about half a second, every time, with whatever is on the screen in front of them. The designer's job is what is on the screen in that half second.

What did the designer actually change?

At AT&T I designed and prototyped a conversational agent for provisioning complex network topologies. It reduced configuration errors and shortened deployment cycles. I will tell you where the time went, because it did not go into the conversation. It went into the moment before the agent acts: what it shows, and what a person is allowed to refuse without a penalty.

Later I architected the Agentic framework, modular AI agents that manage the network infrastructure lifecycle from provisioning through optimization to decommissioning. The word that mattered in that sentence was not agents. It was lifecycle. An agent that can only start things is a liability. One that can be watched and retired is a tool.

The work that paid for itself most plainly was not an agent at all. I redesigned the DNI Portal's diagnostics and logging so that engineers could see what a piece of hardware was actually doing. That visibility drove more than $300,000 in hardware savings through targeted decommissioning. Same lesson, no model involved: show people the truth about the system and they make better decisions than any assistant makes for them. The VLAN migration and triage tools followed the same rule, and issue resolution went from weeks to minutes.

Show the work. Then let them decide.

What does the job look like, day to day?

It looks like sitting with the people who will say yes or no to the machine, and learning what wrong costs them. In a network it is an outage. In a spreadsheet it is a cell. The design is different because the cost is different, and no amount of model quality changes the cost.

It looks like deciding what the machine shows before it acts. The plan, drawn. The source of every value it filled in, one click away, or better, already visible. A machine that shows its work is not slower. It is faster, because nobody has to open a second tool to check it.

It looks like putting the answer where the work already is. Fifteen percent of that composite team left because the truth lived in the ticket and the assistant lived somewhere else. Nobody wants a smarter tab. They want the tab they already have to be smarter.

It looks like designing the refusal. A draft state. An undo that works after the fact. A way to say "not this one" that does not lecture. The last eight percent left over exactly this, and it is the cheapest thing on the list to build.

And it looks like writing it down. At AT&T I helped lead an enterprise pilot of AI tools for product design, and the part that lasted was not the tools. It was the templates and playbooks, so the second team did not have to relearn what the first team learned the hard way.

What a UX designer does not do on an AI product

I do not tune the model. I do not write the system prompt, though I read it, and I have opinions. In every failure I have watched up close, the model was fine. What failed was everything around it: the missing source, the paragraph where a number belonged, the wrong tab, the commitment with no undo.

So when a team tells me their AI feature is not being used and asks whether they need a better model, I ask a different question first. Has anyone in the room been wrong in front of it yet, and what happened next.

The job, then. Somebody decides what a person sees in the half second before they accept what a machine did. Somebody decides what it costs to say no. If nobody is deciding that, the model is deciding it, and the model has never met the people it is deciding for.

Eight percent of seats. I keep the number where I can see it.

← back to conscious_shell