Opening Input From Rigid Forms To Natural Language And Multi-Modal
Understand why opening input to natural language/multi-modal drags in a discoverability problem, and when structured input is still the cheaper choice.
Opening Input From Rigid Forms To Natural Language And Multi-Modal
Lesson 27 was about output: once a model sits behind a feature, output stops having a fixed shape/time/certainty. The same logic applies in reverse to input. Traditional UI forces input into a fixed structure (dropdowns, checkboxes) because rule-based systems only understand a finite set of pre-defined states. Model-based is the opposite: it can accept open input (free text, voice, images) because it infers intent from patterns instead of matching a hardcoded case.
Running example: ClaimWise - an app for handling car insurance claims.
1. The hidden cost of opening up input: discoverability
Opening input sounds like a pure upgrade, but it drags in a problem rigid forms never had: discoverability. A dropdown tells the user, on its own, "here's what you can pick." An empty text box doesn't - the user has to guess what they're allowed to say and how much is enough.
Structured Input vs. Open-Ended Input
Compare 4 dimensions - and the hidden cost of opening input up to free text.
A dropdown tells the user, on its own, "here's what you can pick." An empty text box doesn't - the user has to guess what they're allowed to say and how much is enough.
2. Example: ClaimWise swaps 15 fields for 1 free-text box - and the price it pays
ClaimWise's old version: 15 required fields (vehicle type, plate number, incident date, damage description picked from 8 preset categories...). The AI-native version: the user snaps 1 photo of the damage + types a free sentence like "someone hit my parked car this morning in the parking lot." The model extracts the damage type, estimates the impact location from the photo, and asks follow-up questions if a required field (plate number) is missing.
The problem that surfaced: the first version handed the user an empty box with the placeholder "Describe the incident..." - the user didn't know whether to mention the date, whether to attach a photo, typed 5 words and hit submit, and the model had to ask 3 rounds of follow-up questions for missing data - a worse experience than the old form despite the input being "more open."
3. Structured vs. open-ended input: the trade-off depends on the case
| Structured input (form/dropdown) | Open-ended input (NL, multi-modal) | |
|---|---|---|
| Does the user know what they can say | Yes - options are shown on screen | Not by default - has to be designed in |
| Handling missing/wrong input | Blocked right at the field (hard validation) | Has to infer what's missing, then ask (clarification loop) |
| Speed on simple cases | Fast (a few clicks) | Can be slower if the user doesn't know where to start |
| Speed on complex, context-heavy cases | Slow - many separate fields to fill | Fast - one sentence carries multiple pieces of information at once |
That discoverability gap gets handled in depth in Lesson 35 (onboarding) - for now, hold onto the principle: opening up input means designing a way to surface capability at the same time, not just dropping an empty box and calling it done.
4. Analogy: a physical filing cabinet vs. a librarian standing right there
Structured input is like a physical filing cabinet - every document has to be found under a pre-known drawer and label. Open-ended input is like asking a librarian standing right in front of you: you just describe what you need in plain language, and they translate your vague request into the right document. But if that librarian just stands there, offering nothing, asking nothing back, you don't even know how to phrase your question - that's exactly the discoverability gap above.
Exercise 28.1: DeskBuddy - an internal meeting-room booking app. The old version has 6 dropdowns (building, floor, capacity, equipment, start time, end time). The proposal is to switch to 1 free-text input like "5-person brainstorm tomorrow afternoon, need a screen." Design what that input box needs at minimum to solve the discoverability problem above - it cannot stay "just an empty text box + placeholder."