Я начинаю новую функцию не с экрана, а с решения пользователя

Когда мне предлагают начать новую функцию с макета, я обычно задаю другой вопрос: какое решение человек сможет принять быстрее или увереннее? Экран сам по себе ничего не улучшает. Он лишь становится местом, где человек либо понимает следующий шаг, либо снова идёт спрашивать коллегу.

Это особенно заметно в SaaS. В очереди всегда найдётся просьба «добавить раздел», «вывести ещё один столбец», «сделать переключатель». Если отвечать на каждую просьбу интерфейсом, продукт быстро превращается в шкаф с хорошими ручками: открыть легко, найти нужное трудно.

Функция начинается с момента выбора

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

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

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

Четыре вопроса перед первым экраном

Перед тем как обсуждать интерфейс, я записываю коротко и обычными словами:

• кто оказывается в этой точке работы;
• что он уже знает на этот момент;
• какое решение он должен принять;
• что изменится после решения и кто это увидит.

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

Полезно описать и плохой вариант. Что сделает человек, если система не поможет? Откроет Excel, напишет в чат, позвонит знакомому сотруднику, выгрузит список и будет сверять его вручную. Этот обход часто точнее объясняет цену задачи, чем длинный список пожеланий.

Не всякая просьба — запрос на новую возможность

Фраза «нам нужен отдельный экран» иногда означает совсем другое. Возможно, в существующем маршруте не видно статуса. Возможно, правило известно только одному человеку. Возможно, система показывает верные данные, но слишком поздно. А иногда сотруднику просто не дали права на действие и он просит экран как обходной путь.

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

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

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

Я также стараюсь отделить частый сценарий от громкой просьбы. Самая эмоциональная обратная связь не всегда указывает на главную потерю времени. Один сложный случай может требовать отдельного решения, но не должен незаметно переписать маршрут для сотен обычных операций. Полезно прямо спросить: как часто это происходит, что делает человек сейчас и какие последствия у ошибки. Не ради строгой статистики, а чтобы не перепутать заметную проблему с важной.

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

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

Границы важнее универсальности

У новой функции почти всегда есть соблазн стать «на всякий случай» универсальной. Появляются настройки для редких исключений, пустые поля на будущее и пять вариантов одного действия. В итоге продукт берёт на себя решение, которое бизнес ещё не сформулировал.

Я предпочитаю начать с узкой, честной границы: для какой роли, какого этапа и какого правила это работает. Остальным сценариям можно сказать «пока нет» — при условии, что мы понимаем, что именно не покрыли. Узкая первая версия не означает слабую. Она означает, что команда может увидеть реальное использование и решить, куда развивать продукт дальше.

Перед выпуском стоит проверить не только сценарий успеха. Что будет, если нужных данных нет? Если человек не имеет права действовать? Если правило сработало, но его нужно отменить? Если решение нужно объяснить клиенту? В таких вопросах часто прячется настоящая работа. Готовность продукта к обычному рабочему дню важнее красивой демонстрации — об этом я писал отдельно, когда разбирал проверку продукта перед понедельником утром.

Как понять, что функция получилась

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

Полезно заранее договориться, кто вернётся к этому через две-три недели. Не чтобы устроить отчётную встречу, а чтобы сравнить ожидание с реальностью. Решение, дата проверки и владелец — гораздо полезнее бесконечного списка задач. Такой журнал помогает не смешивать обещания, догадки и уже принятые выборы. О том, зачем он нужен после запуска, я писал в материале про журнал решений продукта.

Короткая проверка перед разработкой

• Назван ли один человек или одна роль, которая принимает решение?
• Можно ли одной фразой описать это решение?
• Понятно ли, какие данные нужны именно в этот момент?
• Есть ли понятный следующий шаг после выбора?
• Знаем ли мы ручной обход, который функция должна убрать?

Если ответы есть, интерфейс обычно собирается спокойнее. Если их нет, лучше ещё немного побыть в разговоре о работе, а не ускорять макет. У хорошей функции есть не только экран. У неё есть понятная причина появиться в рабочем дне человека.

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