What Microsoft’s HAX framework gets right about enterprise AI

Key idea 1 of 9

The hard part is what a person needs before the answer is useful

The hardest part of putting AI into enterprise software is not getting the system to produce an answer. It is deciding what a person needs to understand before that answer becomes useful.

If a system recommends a truck, names the likely cause of a failed transaction, summarizes an exception or proposes the next step in a workflow, the interface has to do more than display the output. It has to help someone decide what to do with it.

Microsoft’s Human-AI eXperience Toolkit collects eighteen guidelines for designing that interaction, drawn from a body of research rather than from one team’s taste. What I find useful about it is that it does not treat AI as a visual effect, or as a chat window added to an existing product.

It treats AI as a participant in the interaction. That participant has capabilities. It has limits. It makes mistakes. It learns. And the person using the product has to build a reasonably accurate picture of all four.

For the kind of enterprise software I have spent most of my career on, that is a far more useful starting point than asking where the sparkle icon goes.

1. Beforewhat the system is for
2. Duringshow enough of the work
3. When it is wrongmake disagreement cheap
4. Over timelet people learn where it fails

Key idea 2 of 9

The goal is not trust

“Building trust” is the phrase that turns up in almost every conversation about AI products, and I think it is the wrong target. I do not want someone to trust an AI system more. I want them to trust it accurately.

Take a dispatcher assigning a load. The system recommends T-118. If the interface says only that, the dispatcher has a problem: accept it because the computer said so, or repeat the whole investigation they would have done without it. The first is overreliance. The second saves nobody any time.

Now show that T-118 is thirty-eight miles from pickup, has 8.4 hours of service left, is the dry van the load needs, and has been on time with this customer eleven times out of twelve. The dispatcher is no longer being asked to trust a score. They are being handed evidence, and evidence is a different relationship.

38 mi

from pickup

8.4 h

of service left

11 of 12

on time with this customer

1

dry van, which is what the load needs

That is what the guidelines keep circling: make clear what the system can do, show context relevant to the task, explain why it behaved the way it did, and help people understand where it stops. Not maximum confidence. Calibrated confidence.

Key idea 3 of 9

Before the first interaction: name what the system is for

The first moment that matters happens before the AI does anything at all. The person needs some idea of what it is capable of, and this is easy to skip. We ship a feature and let people discover its boundaries by running into them — which is affordable in a consumer app and expensive in software where the mistakes have consequences.

If a system is working through failed supply-chain transactions, the person needs to know whether it is summarizing existing evidence, predicting a cause, recommending a fix, or actually doing something. Those are four different levels of responsibility.

I have started thinking about AI functionality as a progression: retrieve, summarize, predict, recommend, act. Retrieving five relevant records needs very little explanation. Summarizing them introduces interpretation. Predicting a cause introduces uncertainty. Recommending an action requires judgment. Taking it creates consequences.

The further right you go, the more the interface has to carry: evidence, control, confirmation, recovery. That progression should be a design input, not something discovered after launch.

1. Retrievefive records
2. Summarizeinterpretation
3. Predictuncertainty
4. Recommendjudgment
5. Actconsequences

Key idea 4 of 9

During interaction: show enough of the work

This is where the dispatch cockpit prototype I built connects most directly to the framework. It explores one question: what would have to be true before an experienced dispatcher stopped checking every recommendation?

My answer was not a better confidence percentage. It was legibility. The recommendation should expose the few factors that actually bear on the decision, and the dispatcher should be able to see why one truck beat another without reassembling it from three screens.

Which is why I am wary of composite scores. A recommendation labeled “87% confident” looks scientific and helps surprisingly little. Eighty-seven percent of what? Act at 87 and investigate at 82?

A record of what actually happened tends to be more useful. The top-ranked truck delivered on time on thirty-eight of the last forty loads like this one — and here are the two it did not. If those two misses share a recognizable feature, the person has learned something about the edge of the system. That is worth more than asking them to believe a number, because the system has started to become predictable.

Key idea 5 of 9

When the AI is wrong: make disagreement cheap

This may be the part that matters most in enterprise work. The AI will be wrong. Good AI design assumes that from the start rather than treating a wrong answer as an unusual failure state, which is why the guidelines devote a whole group to correction, dismissal and recovery.

So the prototype makes overriding the recommendation easy. The dispatcher picks another truck. There is no warning banner and no message asking whether they are absolutely sure they want to ignore the system.

That is deliberate. The dispatcher may know something the data does not hold. A customer called. A driver needs to get home. A dock has a restriction that looks normal in the database and is not normal in reality. That knowledge is not an obstacle in the way of automation. It is part of the system.

Disagreement should therefore be inexpensive. The interface can ask why afterwards, and the answer may reveal a factor the ranking never had. But the AI should not become something the expert has to defeat.

The same holds anywhere a system proposes a cause for an operational failure: the person investigating needs to be able to inspect the evidence, reject the suggestion, take another path, or escalate. A human-in-the-loop design is not achieved by putting an Approve button at the end. The human needs enough information to exercise judgment.

Key idea 6 of 9

Over time: let people learn where it fails

The last part of the relationship is the one conventional usability work tends not to reach. People and AI systems develop a relationship over time. A user notices where the system is strong, and notices where it struggles.

Suppose a dispatcher works out that recommendations are reliable for routine regional runs and weaker when driver home-time is in play. That is valuable. The instinct is to hide the weakness until the model improves; the better move is to help them see it, because now they know when to move fast and when to slow down.

This is why I think some AI products should expose their history. Not a technical audit log of model events. A useful history: what did the system recommend, what happened, when did a person choose differently, and where does this kind of recommendation tend to fail?

Key idea 7 of 9

AI adds a layer of questions; it does not replace the old ones

For most of my career, enterprise UX has meant making complicated systems understandable. Where did this status come from? What happens if I change it? Which system owns this record? Who is allowed to act? What happens downstream?

AI does not replace those questions. It adds a layer. How certain is this? What evidence produced it? Is this fact retrieved or inferred? What does the system not know? Can the person correct it? Can the action be reversed? Should the system be making this call at all?

Those are interaction-design questions, and they need product, engineering, data and domain expertise in the room much earlier than a handoff allows. The designer’s job moves away from arranging screens after the system has been defined, and toward helping the team define the relationship between human judgment and machine capability.

Key idea 8 of 9

A shared vocabulary lets a team argue with a design instead of around it

I did not start the prototype by working through eighteen guidelines. I started with an operational question: a recommendation can be technically excellent and still save nobody any time if it gets verified every time. From there the work moved toward most of the same principles on its own — show the capabilities, show the evidence, communicate uncertainty, allow correction, support recovery, learn over time.

Finding the framework afterwards was useful because it put those instincts inside a much larger body of research. That matters. Design judgment should not be entirely personal preference, and a shared vocabulary is what lets a team argue with a design instead of around it.

Instead of “this recommendation doesn’t feel trustworthy,” the question becomes: have we shown what this person needs in order to judge it? Instead of “should we add a warning?”: what happens when this is wrong, and how does someone recover? Instead of “how do we get people to adopt it?”: what does the system have to demonstrate before someone can safely stop checking its work?

Those are better conversations.

Key idea 9 of 9

The interesting work sits between the answer and the action

AI is quickly becoming good at producing answers, which makes the space around the answer more important rather than less. Something still has to decide what evidence belongs beside it, separate what the system knows from what it inferred, carry uncertainty without drowning the reader in it, judge when automation is appropriate, keep a person’s ability to disagree intact, and leave a safe path forward when the thing gets it wrong.

That gap between an AI output and a consequential human action is one of the most interesting problems in product design right now. HAX gives us a serviceable way to examine it. The principle underneath is simpler: do not design AI so that people trust it. Design it so that people can tell when they should.