When Non-Determinism Hits the Product Interface

When Non-Determinism Hits the Product Interface

AI Literacy Lesson 1 gave you a technology-choice framework: an unstructured problem with an acceptable Cost of Failure points to Model-based. Model-based means non-deterministic - the same input can produce a different output on different runs. That was an architecture decision. This module asks the next question: once you've chosen Model, exactly how does that non-determinism hit the interface you're drawing?

Running example: ReplyGenie - an AI tool that drafts customer-service reply emails for a SaaS startup.

1. Three axes traditional UI assumes are fixed, but Model breaks

Traditional UI is built on an implicit contract: a field always returns a length around X, an action always finishes within roughly Y, results always land on exactly N items. When a probabilistic model sits behind the feature, that contract breaks along 3 axes:

• Output shape/length - the same request might return one sentence one time, a full paragraph with conditions the next.
• Response time - no longer sitting in a narrow, predictable band the way rule-based systems do (say, 200-300ms) - it stretches with input complexity, and can differ by an order of magnitude between two calls.
• Reliability - a model never refuses to answer (AI Literacy Lesson 1), so the UI needs somewhere to hold that uncertainty instead of treating "the model was wrong" as a rare edge case.

One note on the second axis: rule-based systems aren't literally fixed at one number either - they still drift slightly with system load, but that drift sits inside a narrow band, tight enough that a static loading indicator stays accurate. With a model, that band widens by a large multiple and depends heavily on the input - that's the real break, not the claim that rule-based latency is "always exactly one number."

2. Example: ReplyGenie designed as if output were still fixed

ReplyGenie's first UI was built like a traditional autocomplete form: a fixed 4-line text box, a progress bar that always ran for exactly 1 second, no space to show "I'm not sure whether this customer is asking about the Basic or Pro plan." Result: long answers got cut off inside the 4-line box (shape axis broke), complex questions taking 6-7 seconds made the 1-second progress bar look like the app had frozen (time axis broke), and when the model guessed the wrong plan, support staff sent the wrong email straight out with no warning signal at all (reliability axis broke).

3. Old assumption vs. new reality

These three axes frame the rest of the module: Lesson 30 handles the latency axis, Lessons 29 and 31 handle the reliability axis, Lessons 28 and 33 handle input/output no longer having a fixed shape.

4. Analogy: the scripted call center vs. the live consultant

The difference is like calling a call center that reads from a fixed script (every question gets exactly one answer, at exactly one pace) versus asking a live consultant directly - someone who answers briefly when the question is easy, at length with conditions when it's hard, and sometimes says outright "let me double-check, I'm not sure about this part." AI-native product UI has to be designed for the second kind of response.

Exercise 27.1: TripBrief - an app that auto-generates travel itineraries. A user types "3 days in Da Lat" → the app shows a result card with 2 features: (1) a fixed height that always shows exactly 3 activities/day regardless of how many the model suggests; (2) a progress bar that always runs for exactly 1.5 seconds before showing results, with no way to signal if the model isn't sure a location is still open.

Point out 2 specific places in this design that will break once the engine behind it is a probabilistic model, and for each one, state which of the 3 axes just covered it belongs to.