From deterministic to probabilistic design

Almost everything I learned in design assumes determinism. If the user clicks button A, X happens. Always. Buttons advertise themselves, forms validate known rules, screens are designable in Figma because what they’ll show is predictable.

AI breaks this. The same prompt can return different answers in the same conversation. The same agent can pick one tool today and another tomorrow for the same task. Our favourite weapon, the static screen, stops describing what will happen.

This shift sits at the centre of almost everything that changes in Product Design when AI enters. Worth seeing what it asks of us, and what it leaves intact.

How it was in determinism

In the deterministic world, the method is clear:

1. Identify the user’s problem.
2. Map flows.
3. Design mockups with exact text and known states.
4. Validate in prototype.
5. Hand off specs with clear rules: input X yields output Y.

Everything on screen is intentional. Errors, empty states, validation: all enumerable. Figma works well because the work is choreographing the predictable.

The research methods we use, from JTBD to usability testing, assume this frame. You test the interface against the expected task. If the button is visible and legible, the test passes.

What changes with AI

Three things break at once.

First: the output stops being fixed. An agent recommending restaurants might show 5 options today, 8 tomorrow, ask a clarifying question next week. The text that appears also varies. You’re no longer designing one answer; you’re designing a space of acceptable answers.

Second: the input stops being structured. Before, it was clicks and form fields. Now it’s a sentence typed in a hurry, possibly with typos, irony, ambiguity. What the user types is rarely what they meant.

Third: the interaction stops being turn-based in the traditional sense. The agent can interrupt, follow up, act in the background, return with news. The “input → output → input” paradigm dissolves.

Designing for probabilism

What replaces the fixed mockups? Four practices I see emerging.

1. Design examples, not final answers. Instead of defining the exact text that should appear, define 3 to 5 examples of what counts as good output. Those examples are then carried into the prompt as few-shot examples. The designer writes what the AI should replicate, not exactly, but in spirit.

2. Reverse engineering. Instead of imagining the prompt from scratch, mock the ideal message and build the prompt that produces it. Covered in depth in Prompt engineering as design work.

3. Boundaries instead of scripts. What should never happen is more useful to define than what should happen. The classic example: in AI-driven restaurant discovery, filter relaxation is allowed (a 1 km radius can become 2 km). But allergy filters, like gluten-free or peanut-free, can never be relaxed. The boundary is the rule, not the script.

4. Service blueprints over wireframes. The focus moves from “what’s on screen” to “how do agents, tools, data, and the user connect”. The deliverable looks more and more like an agent flow diagram with mapped tools, less and less like a Figma file.

What still applies

Not everything is thrown out. Heuristics like visibility of system status, user control and freedom, help and documentation still work. They apply differently, but the principle holds: the user needs to know what’s happening, needs to be able to pause, needs help when lost.

What changes is the sophistication required. Visibility of system status, in an agent running 12 background steps, is a harder problem than a form with a spinner.

The mindset shift that costs the most

The hardest thing, in my experience, is to stop confusing specific output with desired output.

Designers spent years defending the right copy, the precise microcopy, the exact validation rule. It’s our job. When AI enters, that instinct turns into asking data science to guarantee the output says exactly that sentence. It doesn’t work in probabilism.

The healthy version of the same instinct is saying: “we want the output to satisfy these three properties: friendly tone, no mention of price, always offer a next action.” Those three properties are specifiable, testable, and they live happily inside a probabilistic system. The exact sentence doesn’t.

Where this catches you

Three symptoms that you’re still designing as if it were deterministic:

• You try to write the final copy inside a chatbot mockup.
• You ask for “the output should always look like this” instead of “it should satisfy these properties”.
• Your QA checks if the AI said the predicted sentence, not whether it met the objective.

If any of these sounds familiar, the method hasn’t caught up with the tech yet. Good news: almost no one is fully through this shift. What matters is to start.

More on the background in the Design for AI guide. On collaborating with data science when writing prompts, see Prompt engineering as design work.