Familiar First
· Hui Huang
Agents, sessions, models, reasoning traces, context windows, skills, tools, memory, connectors, automations. AI products come with a dense vocabulary, and each term names a real engineering concern. But should a user have to learn any of it before getting something done?
Product teams often mix up the architecture of the system with the architecture of the experience. They assume that a feature that was hard to build deserves a visible place in the interface. The result is a powerful app that feels like a control panel for its builders instead of a useful service for the people who need it.
The design story behind Grok Bot shows another way. In an August 2026 Dive Club conversation, designer John Bai described an early chat experience that felt more like iMessage than a typical coding assistant. That wasn’t just visual polish. Messaging apps have already taught people where to type, how to follow a thread, and how to spot a reply. The product could borrow that learned behavior instead of asking for a new one.
The deeper lesson: familiarity should be the way in, not the limit of the design. A messaging interface is a great place to ask for help. On its own, it isn’t enough for software that acts independently, changes records, contacts other people, or keeps working after the conversation ends.
Borrow the habits, not just the look
Familiar design usually gets read as copying a popular app’s appearance. Rounded bubbles and a recognizable compose box help. The bigger win is borrowing the habits people already have for starting, answering, revisiting, and ending an exchange.
When you message a colleague, you don’t pick a model, configure a runtime, or choose a workflow first. You say what you want. Sometimes they ask a question back. Sometimes they come back with a result. That’s a strong starting point for AI, because nobody has to translate everyday intent into software operations.
The temptation is to stop there and offer nothing but chat. That works while the system is answering questions. It falls apart once the system takes on ongoing work. A long scroll of messages is a poor way to know which tasks are active, what’s done, what’s stuck, and what needs your permission.
Answering a question vs. owning a task
Compare two requests. “Summarize these meeting notes.” And: “Follow up with the participants, sort out conflicting commitments, and update our project plan.” Both start as a message. They are very different product problems.
The first mostly needs a good answer. The second brings in authority, changing information, timing, exceptions, and consequences for other people. A chat transcript can hold the instruction, but it can’t show every important change in status without becoming exhausting to read.
Grok Bot’s published design notes make this split explicit. The team cut the visible vocabulary down to a few meaningful objects, then added a persistent bot identity, a roster, and status and computer access that appear as work gets going. Users can see that the bot is working, look at its workspace when useful, and take over when needed. The interface doesn’t show every internal detail. It shows the details that change what the user decides.
That’s the move from designing conversations to designing delegation. Users don’t need every step of an agent’s reasoning. They do need to know what was asked, what the agent is allowed to do, whether it’s making progress, and when a human has to decide. Simplicity isn’t showing less. It’s showing what matters at the moment it matters.
Add interface as responsibility grows
A practical rule follows: add interface only when the user’s responsibility grows.
- At the start, offer one obvious action: describe what you want in plain language.
- Once work is underway, show a short status: working, waiting, blocked, or done.
- Before an action with real outside consequences, show a review screen that makes the effect clear.
- When something fails, make the way to recover obvious, without asking the user to debug the system.
Picture an assistant helping run a community event. It starts with one message: “Help me coordinate Saturday’s volunteers.” It drafts a schedule with no extra controls. Before it messages volunteers, it shows recipients and wording for approval. If several people drop out, it shows the open shifts instead of burying them in twenty chat updates. If the coordinator wants to step in, taking back control is easy.
None of this needs a busy home screen on day one. It needs a deliberate match between how much the system is responsible for and how much it shows. The more independently it works, the more clearly it has to communicate its authority and results.
Three things to test
Standard onboarding tests ask whether a new user can find the main feature. AI delegation needs a second test: can the person correctly explain what the system will do next?
I’d watch for three things:
- Can someone start a useful task without learning any AI terminology?
- After submitting it, can they tell an answer from a task in progress from a finished action?
- At a consequential moment, can they tell what needs their approval and what has already happened?
These are behaviors you can observe, not matters of taste. A product can pass the first with beautiful chat bubbles and fail the other two. A full dashboard can show every status and still make the first step intimidating. The job isn’t picking chat or dashboards. It’s adding the right amount of structure as the relationship between person and software changes.
That discipline matters more when you don’t yet know what the product will become. You can still learn from real behavior: where people hesitate, what they mistake for “done,” when they want more detail, and when extra controls are just noise. Let that, more than the team’s newest technical capability, decide how the interface evolves.
Familiar, then different
The goal isn’t to make every AI system look like a messaging app. It’s to use habits people already have to earn the right to teach them new ones. A familiar interaction makes the first try cheap. A trustworthy system makes the tenth and hundredth handoff feel safe and worth it.
That’s a higher bar than making advanced technology look simple. Design for the progression: asking a question, assigning work, following its progress, approving its consequences. Each step creates a new need, and each deserves an interface sized to the decision at hand.
Good design doesn’t show the machinery just because it exists, and it doesn’t hide it when someone needs to step in. Make the new capability approachable first, then make its growing responsibility easy to see.
Want more on working alongside AI? Subscribe below, or see how we build Deployable AI.
