Deterministic Interfaces vs. Probabilistic AI Behavior

Hello! This course begins with a distinction that will shape nearly every design decision you make in an AI-powered product: some interface behaviors can be specified exactly, while others produce a useful answer without guaranteeing precisely what that answer will be.

In this lesson, you’ll learn to spot deterministic and probabilistic behavior in familiar products. You’ll also see why an AI-native product usually contains both—and why identifying the boundary matters when you design what users can expect.

When an interface follows an exact rule

Imagine a notes app with a Cancel button. Its intended behavior is specific: discard the current edit and return to the previous view. Given the same relevant state and the same click, the product should follow the same rule. A designer can specify that behavior precisely, and a developer can test whether it happened.

That is deterministic behavior: with the same inputs and system state, the same rule produces the same output. “Same state” matters. A Save button might show different results depending on whether the document has changed, but its behavior can still be governed by exact rules for each state.

Now imagine the app offers to summarize a meeting. You can specify the request—“summarize these notes in three bullets”—but not every word the system will produce. It might emphasize a deadline on one attempt and a decision on another. It may also omit something important. This is the kind of probabilistic behavior associated with generative AI: the model produces an output based on learned patterns and the context it receives, rather than following a complete set of rules specifying every possible answer.

Read NN/g’s short discussion of how this changes a designer’s relationship with a specification. The weather example comes first; it makes the abstract distinction concrete.

There is a useful nuance in the word probabilistic. It does not mean the output must change every time. An AI system may give the same answer repeatedly, and some configurations can make its output more repeatable. The design distinction is that an exact response is generally not guaranteed by a rule that covers every case. Conversely, a deterministic rule can produce many different outputs when its inputs differ. Variation alone does not tell you which kind of behavior you are seeing.

Prediction can be useful without being certain

AI behavior is not limited to writing text. A system might predict which photos contain a cat, which email needs attention, or which meeting-note sentence describes an action item. It can make a useful prediction and still get a particular case wrong.

Watch this brief example from a Google People + AI Guidebook presentation. You do not need to study the later technical discussion of evaluation measures; concentrate on the difference between a prediction and the reality it is meant to represent.

Suppose an AI labels a sentence “Jordan will send the draft by Friday” as an action item. The label is a prediction about the sentence’s meaning. If the notes actually say “Jordan might send the draft,” presenting it as a firm commitment would mislead the team. By contrast, a rule that displays the saved note verbatim can be tested against the stored text. It might still have a software bug, but its intended behavior is exact.

The following image offers a quick visual comparison. Treat it as a starting point, not a strict test: multiple inputs do not make a system probabilistic. A rule-based feature can combine several data sources, and an AI model can make a prediction from a single input.

One product, two kinds of behavior

Consider a meeting-notes product. A user uploads notes, asks for action items, reviews the suggestions, and saves the ones they accept. It would be a mistake to call this entire experience either “deterministic” or “probabilistic.” Classify the individual behaviors instead.

Notice the boundary around the AI output. Generating a suggestion is probabilistic; preserving the user’s approved choice should be deterministic. If the product quietly changes an accepted action item while saving it, that is not an unavoidable property of AI—it is a failure of the surrounding product behavior.

This distinction gives designers a practical way to write requirements. For a Cancel button, a requirement can state the exact result. For AI-generated action items, “always extract the correct three items” is usually not a realistic interface specification. You can instead specify the feature’s purpose and the user’s ability to inspect a suggestion before treating it as a commitment. Later in the course, you’ll work in more detail on how to design that review experience.

There is one more caution: appearance does not prove implementation. A personalized-looking greeting might come from a simple rule that inserts someone’s name. An automatically suggested deadline might come from a fixed rule or from a model interpreting a sentence. When the implementation is unknown, describe what you can observe and ask what guarantees the product actually makes; don’t assume that every dynamic feature uses AI.

Decide where variability earns its place

Probabilistic behavior is valuable when a fixed set of rules struggles with varied language, preferences, or situations. But flexibility has a cost: the result may be less predictable, harder to explain, or sometimes wrong. The design question is not “Where can we add AI?” It is “Which user problem benefits enough from this flexibility to justify it?”

Google’s People + AI Guidebook makes that comparison through concrete product examples.

A recommendation for which document to read next may improve when it adapts to a person’s work. A Cancel button does not improve by guessing what that person might have meant. Both can sit in the same product, but they make different promises to the user. The recommendation says, in effect, “This may help”; Cancel says, “This action will happen.”

Key takeaways

To distinguish the two behaviors in a product example, identify the specific action rather than labeling the whole product. Ask whether the same relevant inputs and state are governed by an exact, testable rule, or whether the system is interpreting information and producing a result that may be useful without being guaranteed. Remember that changing output does not automatically mean AI, and repeating output does not automatically mean a deterministic rule.

For AI-native product design, the goal is not to make everything probabilistic. It is to use AI’s flexibility where it helps, while keeping essential controls and commitments dependable. Next, you’ll look more closely at which productivity tasks current large language models are well suited to assist with.