Teaching Users How To "Talk" To An AI-Native Product

Teaching Users How To "Talk" To An AI-Native Product

Lesson 28 flagged a gap: opening input up to free text creates a discoverability problem - the user doesn't inherently know what they're allowed to say, or how much is enough. That lesson promised to handle it in depth here. This is that lesson.

Running example: back to DeskBuddy (Lesson 28) - the internal meeting-room booking app that just switched from 6 dropdowns to 1 free-text input.

1. Three mechanisms, answering three different user questions

Traditional UI doesn't need to teach users how to use it - the form structure itself is the instructions (see a dropdown with 5 options, you instantly know there are 5 options). AI-native features lose that "self-explaining" advantage once input opens up, so onboarding stops being a side feature (a welcome tooltip shown once) and becomes a required part of the interaction design itself:

• (a) Capability discovery - "what can this feature do?" The user doesn't know the scope. Mechanism: show a few sample prompts/tasks right in or next to the input box, not on a separate intro screen the user will skip.
• (b) Example-driven hint - "is this how I'm supposed to phrase it?" The user knows the scope but isn't sure how to word things. Mechanism: the placeholder isn't a generic prompt, it's a concrete example detailed enough for the user to understand what level of detail is good - a vague placeholder teaches the user to phrase things vaguely.
• (c) In-context correction - "did I just ask the wrong way?" Instead of letting the user guess and only find out they were wrong from a bad result, the system responds right there when it detects the input is missing something needed. This is continuous onboarding, not a one-time event when the app is first opened.

2. Example: DeskBuddy applies all 3 mechanisms, first-time success rate rises sharply

After switching from 6 dropdowns to 1 free-text input, initial usage dropped because users didn't know what to type. Fixed with 3 mechanisms: (a) right below the input, show 3 clickable suggestion chips - "5-person meeting this afternoon," "quiet room for 1 tomorrow morning," "room with a screen next week" - not just descriptive text but actually clickable prompts; (b) the placeholder changed from "Describe what you need..." to a concrete example, "e.g. 5-person brainstorm, 2-4pm tomorrow, need a screen"; (c) when a user types "need a meeting room" (missing time, headcount), the system doesn't block - it responds right away with "How many people, and when? I'll suggest the nearest open room first" plus 2-3 default suggestions to click quickly. Result: first-time success rate rose sharply, because users no longer had to "guess" how to talk to the system.

3. Three mechanisms answering three different questions, at three different moments

Note: don't confuse (a) with a separate intro screen (like a "How to use this app" slideshow shown on first launch) - that kind is almost always skipped because it's disconnected from the moment the user actually needs it. All 3 mechanisms above work because they sit right at the point of interaction.

4. Analogy: an empty room vs. a room with props hinting at its purpose

It's like the difference between putting someone in an empty room and saying nothing (they stand there blankly, not knowing what to do) versus putting them in the same room but with a few props laid out hinting at what to do, plus someone standing nearby ready to say "ah, you're missing this" the moment they get a step wrong - not waiting until the end to say anything.

Exercise 35.1 (record it, no need to build it): NoteMind - an AI app that lets users type freely to create tasks/reminders ("remind me to call client A next Thursday at 10am"). Right now it's just an empty input box with the placeholder "What would you like to remember?" Design 1 concrete example for mechanism (b), and describe 1 specific situation where mechanism (c) should trigger.