The first thing I had to establish with product teams was that familiar patterns break here. In an app, the user states a request in the shape we designed, sees the whole state at once, and moves freely between sections. With an agent, the request arrives in the user's own words — imprecise and incomplete — the state arrives one message at a time, and the path is strictly sequential.

Первое, что пришлось проговорить с продуктовыми командами: привычные паттерны здесь ломаются. В приложении пользователь формулирует запрос в той форме, которую мы заложили, видит всё состояние сразу и свободно ходит по разделам. С агентом запрос приходит его словами — неточно и неполно, — состояние приходит по одной реплике, а путь строго последовательный.

Design an agent like a screen — long option lists, forms, «Next» buttons — and the user wonders why they're having a conversation at all. Force a dialog onto a task that needs visual control over every parameter, and you've built something worse than a form. Knowing which of the two you're holding is the first design decision, and it happens before anything is drawn.

Спроектируешь агента как экран — с длинными списками опций, формами и кнопками «Далее» — и пользователь не поймёт, зачем ему диалог. Загонишь в диалог задачу, где нужен визуальный контроль над всеми параметрами, — получишь нечто хуже формы. Понять, что именно у тебя в руках, — это первое проектное решение, и оно принимается до того, как что-либо нарисовано.

A classic home screen sorts by recency: newest on top. For an agent surfacing proactive work across many services, that model collapses. The user doesn't want what just happened — they want whatever creates the most value right now for the least cognitive effort.

Классическая главная сортирует по свежести: новое сверху. Для агента, который проактивно показывает работу по многим сервисам, эта модель рассыпается. Пользователю не нужно то, что только что произошло, — ему нужно то, что прямо сейчас даёт больше всего пользы при наименьшем усилии.

So I designed the home as a competition for slots rather than a list. Every candidate card is scored on usefulness, fit to the surface it would appear on, urgency, novelty, the user's demonstrated affinity for that kind of scenario, and a cooldown that punishes repetition. A diversity penalty applies after ranking, so the top of the screen can't fill up with five variations of the same thing.

Поэтому я спроектировал главную как конкуренцию за слоты, а не как список. Каждая карточка-кандидат оценивается по полезности, соответствию поверхности, срочности, новизне, доказанной склонности пользователя к сценариям такого типа и по «остыванию», которое штрафует повторы. Штраф за однообразие применяется уже после ранжирования — чтобы верх экрана не заполнился пятью вариациями одного и того же.

The most common failure I saw was treating every scenario the same way. There are two fundamentally different kinds, and they need opposite design instincts.

Самая частая ошибка, которую я видел, — проектировать все сценарии одинаково. Есть два принципиально разных класса, и они требуют противоположных инстинктов.

Consultation. The user arrives with a vague problem — «help me choose», «where should I go», «how does this work». The agent's job is to help them work out what they actually want and explain why. Success is the user leaving with understanding.

Консультация. Пользователь приходит с размытой задачей: «помоги выбрать», «куда сходить», «как это работает». Задача агента — помочь разобраться и объяснить почему. Успех — человек вышел с пониманием.

Action. The user knows exactly what they want done. The agent's job is to collect what's missing, show the result, confirm, execute. Success is completion in the fewest turns.

Действие. Пользователь точно знает, что нужно сделать. Задача агента — быстро собрать недостающее, показать итог, получить подтверждение и выполнить. Успех — результат за минимум шагов.

Design a consultation like an action and you skip the explanation, so the user doesn't trust the answer. Design an action like a consultation and you ask three clarifying questions and lose them. Most real scenarios begin as one and end as the other — the handover is where the design actually lives, and it's where products feel «off» without anyone being able to say why.

Спроектируешь консультацию как действие — пропустишь объяснение, и человек не поверит ответу. Спроектируешь действие как консультацию — зададишь три уточняющих вопроса и потеряешь его. Большинство реальных сценариев начинаются как одно и заканчиваются как другое, и именно на переходе живёт весь дизайн. Там же продукты и начинают «ощущаться странно», хотя никто не может объяснить, почему.

When an agent can move money, place an order or book something, the design question stops being «is this usable» and becomes «does the person stay in control». I wrote the behavioural guidelines the product teams design against. A few of the rules that mattered most:

Когда агент может перевести деньги, оформить заказ или что-то забронировать, вопрос перестаёт быть «удобно ли» и становится «остаётся ли человек в контроле». Я написал поведенческие правила, по которым проектируют продуктовые команды. Несколько из тех, что оказались важнее всего:

Anything that changes state gets a confirmation with a legible summary. Anything that only reads state gets none — over-confirming is its own failure.

Всё, что меняет состояние, получает подтверждение с понятным итогом. Всё, что только читает состояние, — не получает: избыточное подтверждение это тоже провал.

A person must be able to correct a parameter mid-conversation. Sending them back to the start is the fastest way to make an agent feel like a bad form.

Человек должен иметь возможность поправить параметр по ходу разговора. Отправить его в начало — самый быстрый способ превратить агента в плохую форму.

Honesty beats fluency. A made-up answer doesn't fail once — it costs trust in the whole agent, and that's not recoverable per-scenario.

Честность важнее гладкости. Придуманный ответ проваливается не один раз — он стоит доверия ко всему агенту, а это не чинится в отдельно взятом сценарии.

Voice is an interface with a severe attention deficit. Five cards on a screen become thirty seconds of monologue, and the person disengages at second ten. So I set symmetry as a constraint: voice reads the top item plus a count of the rest, every card carries a short and a long spoken form, and anything that can't be said in eight seconds doesn't get spoken at all — it's shown instead.

Голос — это интерфейс с острым дефицитом внимания. Пять карточек на экране превращаются в тридцать секунд монолога, и человек отключается на десятой. Поэтому симметрия стала ограничением: голос читает первое и называет число остальных, у каждой карточки есть короткая и длинная озвучка, а всё, что нельзя сказать за восемь секунд, не озвучивается вовсе — только показывается.

That constraint turned out to be a quality filter for text too. If a reply can't be read aloud naturally — masked account numbers, ten-item lists, nested clauses — it was badly written to begin with.

Это ограничение оказалось фильтром качества и для текста. Если реплику нельзя естественно прочитать вслух — маскированные номера счетов, списки из десяти пунктов, вложенные конструкции — значит, она изначально плохо написана.

The related rule: widgets show, conversation collects. Cards, charts and maps are excellent for presenting an outcome. A form inside a dialog is an anti-pattern — at that point you should be building a screen.

Смежное правило: виджеты показывают, разговор собирает. Карточки, графики и карты отлично показывают результат. Форма внутри диалога — антипаттерн: если дошло до неё, надо было делать экран.

Dozens of product teams across the ecosystem needed to design agent scenarios, most of them for the first time. Rather than review everything myself, I built the path they walk: a decision framework for whether an agent suits the task at all, a short intake conversation where we pressure-test the idea against what's already been tried, guidance for the design phase, and a review gate before development.

Десятки продуктовых команд по всей экосистеме должны были проектировать сценарии агента, большинство — впервые. Вместо того чтобы ревьюить всё лично, я построил путь, по которому они идут: рамка для решения, подходит ли агент этой задаче вообще, короткая установочная встреча, где идею проверяют на чужом опыте, руководство на этап проектирования и точка приёмки перед разработкой.

Two artefacts do most of the work: a guide that walks a team from idea to handoff, and a do/don't reference a designer opens mid-task when they need to know how to phrase something. Both are written to be used at the moment of the question, not read once at onboarding.

Основную работу делают два артефакта: гайд, который ведёт команду от идеи до передачи в разработку, и справочник do/don't, который дизайнер открывает по ходу задачи, когда нужно понять, как что-то сформулировать. Оба написаны, чтобы ими пользовались в момент вопроса, а не читали один раз на онбординге.

This is the part I care about most. An hour of conversation early saves a team weeks of building in the wrong direction — and a framework that outlives me is worth more than any screen I could draw myself.

Это та часть, которая мне важнее всего. Час разговора в начале экономит команде недели работы не в ту сторону, а рамка, которая переживёт меня в компании, стоит больше любого экрана, который я нарисую сам.