Designing for Two Species of User

Somewhere in the requirements of every SaaS product ever shipped is an assumption so fundamental that nobody thought to write it down: the user is a human being.

That assumption shaped everything downstream of it. Interfaces are visual because humans have eyes. Workflows are paced for human attention. Onboarding exists because humans need to learn. Error messages are written in encouraging prose because humans get frustrated. Navigation is designed around discovery because humans forget where things are.

None of that is wrong. All of it is now incomplete, because a meaningful and rapidly growing share of the entities operating your software are not human.

Two species, one product

An agent using your product wants almost the opposite of what a person wants.

A person wants a clean visual hierarchy that directs attention. An agent wants structure it can parse deterministically, and finds visual hierarchy irrelevant at best.

A person benefits from progressive disclosure — hiding complexity until it's needed. An agent is actively impeded by it, because the thing it needs might be three interactions deep behind a disclosure pattern designed to protect a human from feeling overwhelmed.

A person tolerates and even appreciates variety — a slightly different layout on a different screen keeps things interesting and signals context. An agent needs consistency, because variety is indistinguishable from a breaking change.

A person reads an error message and infers what to do. An agent needs the error to be machine-identifiable, with a stable code and a documented meaning, or it will either give up or, worse, confidently proceed.

This is a genuine dual-design problem, and the tempting resolutions are both wrong. Building only for humans means agents will operate your product anyway — badly, brittly, through the UI — and you'll absorb the support burden without any of the benefit. Building only for agents produces something no human wants to touch, which matters because humans are still making the purchasing decision.

Accessibility was the rehearsal

The encouraging part is that this isn't as unprecedented as it sounds. We have done a version of it before.

Building for screen readers required exactly this discipline: semantic markup that conveys structure independent of visual presentation, meaningful labels, predictable focus order, state changes that are announced rather than merely displayed. The whole practice was about making an interface comprehensible to something that could not see it.

An agent is, functionally, a very fast user with no eyes and no patience. The overlap with accessibility work is close to total, which means a product that was built properly for accessibility is already substantially agent-ready, and a product that treated accessibility as a compliance checkbox has a considerably larger problem than it realises.

I'd go further: this is the strongest commercial argument for accessibility that has ever existed. The work you did because it was right turns out to have been infrastructure for the next decade of usage.

What this actually requires

Semantic structure that means something. Elements that describe what they are rather than how they look. A div with a click handler is invisible to an agent in the way it's invisible to a screen reader.

Naming that stays put. Stable, consistent identifiers on the things that matter. If your field names change between releases because a designer renamed a label, every agent workflow built against your product breaks silently, and the customer blames you.

Predictable navigation. A stable relationship between an intent and a path. Agents learn routes; unnecessary route churn is expensive in a way it never was when only humans were navigating.

Structured data exposure. The state of the thing being viewed, available in a form that doesn't require inferring it from rendered pixels. This is the single highest-leverage change most products could make.

Explicit state and errors. Machine-readable status, stable error codes, and a clear signal for "this operation is still in progress" — which agents handle badly when it's communicated only through a spinner.

A real API, treated as a first-class surface. Everything above is what you need when an agent operates the interface. The better answer, where you can offer it, is that it doesn't have to.

The commercial argument

This is where it stops being a design question. I've written before about the hostage problem — vendors gatekeeping customer data behind incomplete APIs and expensive access tiers — and about the licensing landmine that opens when a single agent credential does the work of many humans.

Designing for agents sits directly on top of both. A vendor who makes their product genuinely agent-legible is choosing to be part of their customer's automation strategy rather than an obstacle to it. A vendor who doesn't will find that agents operate their product anyway, through the front door, brittly — generating support load, breaking on every UI release, and producing exactly the security and data-integrity problems that vendors cite as reasons to prohibit the practice.

Prohibition isn't a strategy here. The demand is real and the capability exists. The only decision available is whether the agent traffic hitting your product is well-formed and sanctioned, or improvised and hostile to your release cycle.

Where to start

If you build software, the first useful exercise is not a roadmap item. It's an observation. Point an agent at your own product and ask it to complete a task a customer would actually want automated — pull a report, update a batch of records, extract a dataset. Watch where it struggles.

It will struggle in the places where your interface communicates meaning visually rather than structurally. That list is your backlog, and it will be shorter than you fear and more valuable than it looks, because most of it improves the product for humans too.

The products that win the next decade will be the ones that stopped assuming there was only one kind of user — and noticed early enough that the second kind was already knocking.