Chapter 141 · Interface and adoption

The interface shapes what people ask

An empty box with a blinking cursor is a design decision, and it produces the question distribution you then spend a year engineering around. Four surfaces, measured, and the one that worked.

7 min read

A hundred and forty chapters have treated the question as an input. It is not: it is an output of the interface, and the interface is the cheapest lever in the entire system.

Chapter 102 measured Atlas's real traffic — median six words, 31% containing a typo or abbreviation, 42% fully specified. Those numbers are not facts about users. They are facts about a text box.

The empty box

<input placeholder="Ask me anything" />

// What it communicates, and all three are wrong:
//   1. The system can answer anything. It cannot — chapter 20 listed
//      what it should refuse, and 18% of traffic is out of scope.
//   2. There is no wrong way to ask. There is: an underspecified
//      question gets an underspecified answer.
//   3. You are talking to something general-purpose. It is a tool with
//      a defined surface over a defined corpus.

Atlas's first month, with an empty box:


Median question length	6 words
Fully specified	42%
Out of scope	18%
Needed a clarification	11%
Users who asked more than three questions ever	34%

That last row is the one that matters. Two thirds of the company tried it, found it did not work the way they guessed, and did not come back. Chapter 148 is about that number; this chapter is about the cause.

Four surfaces, measured

Atlas ran all four over a quarter.

Surface	Median words	Fully specified	Out of scope	Repeat use
Empty box	6	42%	18%	34%
Box with example chips	11	61%	12%	52%
Structured starters	14	79%	6%	71%
Form per task	22	96%	1%	19%

The last row is the instructive failure. A form that captures everything produces near-perfect inputs and nobody uses it, because a form is a worse version of the system it replaced — if a rep has to fill in six fields, the email they used to send was faster.

Structured starters won by a clear margin, and they are barely more work than the empty box.

Structured starters

// Not placeholder text and not an autocomplete. Real entry points, each
// of which names a capability and leaves the specifics to the user.
const STARTERS = [
  { label: 'Check an order',        template: 'What is the status of order ___?' },
  { label: 'Look up a policy',      template: 'What is our policy on ___?' },
  { label: 'Compare suppliers',     template: 'Compare ___ and ___ on ___' },
  { label: 'Check stock',           template: 'Do we have ___ in stock?' },
  { label: 'Draft a customer reply',template: 'Draft a reply to ___ about ___' },
]

// Clicking one fills the box with the template and places the cursor in
// the first blank. The user is now editing a well-formed question
// instead of composing one from nothing.
<Starters onSelect={(t) => setQuestion(t.template)} />
<textarea value={question} onChange={...} />

Three properties doing the work:

// 1. It teaches the surface. Five starters tell a new user what the
//    system does more effectively than any onboarding document, and
//    chapter 146 found the document was read by 12% of people.
//
// 2. It makes a well-formed question the default path. The blank in
//    "What is our policy on ___" is a prompt for the specificity that
//    an empty box never asks for.
//
// 3. It reduces out-of-scope by making the scope visible. 18% to 6%
//    without a single refusal being improved.

That third effect is the one worth dwelling on. Section 9 spent a chapter on refusal quality and measured human agreement at 0.66 on whether a refusal was correct. Showing people what the system does cut the problem by two thirds at the source, which no amount of refusal tuning would have achieved.

The cheapest improvement to refusal is not a better refusal. It is an interface that makes the out-of-scope question less likely to be asked.

What not to put in the box

// Three affordances that measured badly.
const REJECTED = {
  autocomplete: 'Suggesting whole questions from other users’ history. ' +
    'It leaked what colleagues were working on — chapter 121’s eighth path, ' +
    'arriving through a convenience feature.',
  voice: 'Lower specificity than typing (median 5 words) and no editing step.',
  'single-line input': 'A one-line field caps question length by implication. ' +
    'Switching to a 3-row textarea took the median from 6 words to 9 ' +
    'with no other change.',
}

The textarea result is the smallest change in this chapter and one of the largest effects. A one-line input tells people the expected answer is short, and they comply.

Follow-ups are an interface problem too

// After an answer, offer the next question rather than an empty box.
// Generated from the answer's content and the available tools, not from
// a model call — these are templates filled from the entities in play.
const followUps = suggestFollowUps(answer, state)
// For an order status answer:
//   "When is it expected to ship?"
//   "Show the full order history"
//   "Who is the account owner?"

Follow-up suggestions raised multi-turn sessions from 29% to 44%, and chapter 92 already built the state that makes them cheap. The suggestions are deterministic templates rather than a generated list, which keeps them fast, free, and incapable of suggesting something the system cannot do.

Where the interface lives

// A decision that precedes all of the above, and the measured answer
// was not the one the team expected.
const PLACEMENT = {
  standalone: 'A page people must navigate to. Requires remembering it exists.',
  embedded:   'Inside the tool they already have open all day.',
  chat:       'In the messaging platform the company already uses.',
}

Atlas's weekly active users: standalone 31%, embedded in the order system 58%, chat 49%. Embedded won because the question occurs while someone is looking at an order, and a system that requires leaving the context loses to the colleague sitting nearby.

The embedded surface also arrives with context for free — the order on screen is the entity in focus, which means chapter 92's focus slot is populated before the user types a word.

Key points

The question distribution is an output of the interface, not a fact about users.
An empty box communicates three false things: that it answers anything, that there is no wrong way to ask, and that it is general-purpose.
With an empty box, only 34% of people who tried Atlas asked more than three questions ever.
Four surfaces measured. Structured starters won: median 14 words, 79% fully specified, 6% out of scope, 71% repeat use.
A form per task produced 96% specified inputs and 19% repeat use. A form is a worse version of the email it replaced.
Starters teach the surface better than documentation, which 12% of people read.
Out-of-scope fell 18% to 6% with no change to refusal handling. The cheapest refusal improvement is an interface that prevents the question.
Reject history-based autocomplete: it leaks what colleagues are working on through a convenience feature.
A three-row textarea instead of a one-line input took median question length from 6 words to 9.
Deterministic follow-up suggestions took multi-turn sessions from 29% to 44%.
Embed it where the work happens. Embedded beat standalone 58% to 31%, and arrives with the entity in focus already known.

Next: streaming UX, and what to show while it thinks — the seconds after they press enter.