Generative AI is quietly rewriting the contract between people and software. For years, our craft was the steps: the screens, filters, and flows a person moved through to reach a goal. That era is ending.
This is an argument about what replaces it. I'll use one product I worked on — Axari, an AI operating system for security leaders — as a running example, but the piece is about the shift, not the product.
Think about how you used to book a trip. You opened one site for flights, another for hotels, a third for a car. You clicked filters, compared dates, copied a confirmation number into a calendar, then did it all again when a meeting moved. The goal was a trip. Everything else was labour — the manual coordination the interface asked of you in exchange for the outcome you actually wanted.
That labour is what most digital products are made of. We call it a flow, but from the user's side it's a set of instructions they have to execute: go here, toggle this, remember that, come back tomorrow. As designers we spent our energy making each of those steps clearer, faster, less painful. We optimised the process because the process was the product.
Every interface built this way carries a hidden assumption: that the person should do the coordinating, and the software should just hold the buttons.
I saw this plainly on Axari, built for people who were drowning not in a shortage of software but in the opposite. They had dashboards and specialist tools for almost everything; what they lacked was a single, reliable view of the work — and the job of interpreting it all was left to them. Another dashboard would only have added more steps. The work didn't need more process. It needed the process taken off the person's plate.
Generative AI changes what a person has to say to get what they want. Instead of describing how — click this, filter that, coordinate across three windows — they can describe the outcome, and let the system orchestrate the process to get there. The field is starting to call this intent-based outcome specification: you state the result; the machine works out the steps.
This is not a cosmetic change. It inverts the contract. The user brings the goal and the judgement; the system brings the coordination. The screens stop being a to-do list handed to the person and start being a place where they express what they want and inspect what the system did about it.
Axari is one small example of the pattern. Instead of another dashboard, it gives the user a team of AI specialists coordinated by an orchestrator. The person doesn't operate the tools; they state what they need — prepare the update, chase the blocked item, tell me what changed overnight — and the system does the assembling and brings back the result.
That is outcome-oriented design in one line: the person owns the intent, the system owns the steps.
Here is the trap I want to warn other designers about. When the system can fetch, compute, and summarise almost anything, the temptation is to show everything — every feed, every signal, every number, now correct and real-time. But volume is rarely the problem. Interpretation is.
The feeds, signals, and numbers have to be right. This is a data and security problem — hard, essential, and not where design earns its keep.
Deciding which data actually helps a person make the decision in front of them. Answerable only by understanding their day, their priorities, and what each decision needs.
Answering the relevance question is not model work; it is design work, and it starts with understanding someone's day well enough to know what a decision actually needs. In Axari that showed up as a simple daily surface that sorted the noise by relevance rather than volume:
To Do
Things that need your decision — each opening to full context, a prepared draft, and approve or dismiss.
To Attend
Moments where your presence matters — the things a person, not an agent, has to show up for.
To Know
Context worth seeing, with the reasoning behind it, without turning it into another task.
The system did the gathering in the background; the surface showed only what mattered at that moment. Outcome-oriented design isn't about showing more because you finally can. It's the discipline of curating for the decision — and that discipline is a designer's, not a model's.
If the system generates the steps, then designing every step by hand stops being the job. You cannot hand-craft a screen for every path a person might take, because the paths are now generated on demand for that individual. So the work moves up a level. You stop optimising each component for an imagined "average" user and start defining the boundaries and rules the system operates within — the space of good outcomes it's allowed to produce.
The designer becomes an architect of possibilities — someone who shapes the framework, not every screen inside it.
In practice, this means handing structure to the user rather than hard-coding it. In Axari, instead of shipping one fixed team, we let people compose their own — creating specialists, assigning them capabilities from a shared library, and setting the rules each one follows.
I was no longer designing the team. I was designing the system in which someone builds their own. The deliverable stopped being a set of finished screens and became a set of well-shaped possibilities — and the job became making the good choices easy and the incoherent ones hard.
An architecture of possibilities has to be adaptive — it has to generate the right path for the person in front of it, not force everyone down one road. The design question changes from "what is the ideal flow?" to "what are the rules that let a good flow emerge for each person?"
In Axari this took the shape of an autonomy ladder. Rather than deciding once, for everyone, how much the AI should do on its own, each responsibility could sit at the level of trust that fit it:
Human in the loop
Work that needs review and approval before anything happens. The AI prepares; the person decides.
Human on the loop
Work that can move forward with oversight. The AI acts; the person watches and can intervene.
Human out of the loop
Lower-risk, repeatable work the AI completes on its own, logged and auditable after the fact.
No single screen decides where a task sits; the framework does, guided by the person using it. That's the shift in a sentence: I wasn't drawing the path someone takes through their week. I was drawing the rules that let the right path assemble itself.
There's a failure mode hiding inside outcome-oriented design. The moment software acts on your behalf, a new anxiety appears: What did it do? Can I trust it? Am I still accountable? In high-stakes work the answer to that last question is almost always yes — the person still owns the result no matter who prepared it. If the design doesn't respect that, the outcome is worthless, because no one will rely on it.
The answer is to keep the person visible in the loop. In Axari, the system could prepare anything, but a person reviewed or edited whatever needed judgement. The interface's real job was to make a few things legible at a glance:
What needs me now?
The decisions only I can make, surfaced with their full context.
What's in progress?
What the AI team is doing right now, shown as a live plan I can follow.
What can wait?
What's safe to approve, delegate, or leave — without losing track of it.
The system didn't just hand over an answer; it showed its reasoning, prepared a complete action to review, and kept approve or dismiss one move away. Legibility, not just capability.
Outcome-oriented design without trust design is just automation people quietly stop using.
Making reasoning, ownership, and control visible is not a nice-to-have layered on top of the outcome. When the system does the steps, that legibility is the design.
It would be easy to read all of this as the profession shrinking — if the machine designs the steps, what's left for us? I think the opposite is true. As the step-by-step gets automated, the skills that were always underneath the craft become more valuable, not less: user-centric problem solving, critical thinking, and holistic thinking about the whole system a person lives in.
The step-by-step was never the hard part of design. The hard part was always upstream: understanding a person's real situation, framing the right problem, and deciding which outcomes are worth pursuing at all. A model can generate a flow. It cannot decide, on your behalf, what a particular person actually needs — or be accountable to their reality when it gets that wrong.
On Axari the work that mattered most happened before any screen existed, in understanding the shape of someone's day well enough to know which handful of things deserved their attention. That is old-fashioned, user-centred design, and it becomes more valuable as the machine takes over the production work, not less.
There's a personal edge to this shift, too. As the tools improve, the distance between designing something and building it collapses. On Axari I moved from designing the system to building parts of it directly — and that's less a story about me than a signal of where the craft is heading: designers working closer to the material, shaping the framework and then standing it up to feel how it actually behaves.
The technology absorbs the repetitive, step-by-step production work, and the designer moves toward higher-level strategy. The role isn't disappearing. It's moving up the stack — from arranging the steps to defining the outcomes and the framework that produces them, and often to building that framework directly.
Strip away the mechanics and outcome-oriented design comes down to one principle that I think travels far beyond any single product:
AI should not only automate tasks. It should make priorities, ownership, progress, and decisions easier for people to understand.
That's the real promise of outcome-oriented design, and it's also the reason our profession isn't going anywhere. Someone has to decide which outcomes are worth pursuing, draw the boundaries the system operates within, and make sure a person can still see, trust, and own what the machine does on their behalf. The tools that generate the steps don't answer any of those questions. Designers do.
We're not losing the work. We're being handed the part of it that always mattered most — and being trusted, finally, to design for the result instead of the ritual.
This essay expands on ideas from a short talk on outcome-oriented UX and intent-based outcome specification (YouTube). Axari is used here as a running example; if you want the full story of that product, the case study goes deeper.
See the Axari case study