Как превратить разбор аналогов в принципы, по которым команда сможет решать

Разбор перестаёт быть подготовкой к одному макету и становится общей опорой для решений.

Две ловушки ступени

• Лозунги вместо принципов. «Делаем просто», «уважаем время пользователя», «пользователь в центре». Спорить с этим трудно, но и решить по этому тоже нельзя: под «делаем просто» подходит и диалог подтверждения, и его отсутствие. Признак: за месяц на принцип ни разу не сослались в споре.
• Принципы как личная власть. Вы написали их сами, сами объясняете и сами решаете, где они применимы. Формально принципы есть, а на деле это всё тот же ответ «как решил старший», только в письменном виде. Признак: без вас принцип никто не берётся применить.

Первый навык. Не каждая находка тянет на принцип — и это нормально.

Принцип — это повторяющееся решение, которое команда принимает одинаково в разных местах продукта. Если находка касается одного экрана, это просто решение. Если из неё следует, как поступать и в отмене заказа, и в удалении адреса, и в отписке от рассылки, — вот это принцип.

Три вопроса, которые превращают находку в принцип

1. Повторится ли эта ситуация в других местах продукта? Отмена заказа, удаление адреса, отмена подписки, удаление файла — одна и та же ситуация: обратимое действие, которое страшно сделать случайно. Значит, тянет на принцип.
2. Какое общее правило стоит за конкретным решением? От диалога отказались не потому, что диалоги плохие, а потому что действие обратимо. Правило: там, где можно откатить, — откатываем вместо подтверждения.
3. Есть ли противоположный случай? Если у принципа вообще нет границ, он легко превращается в лозунг. Здесь исключение есть: удаление аккаунта откатить нельзя, значит, там подтверждение остаётся. Наличие границы и делает принцип применимым.

Второй навык. У рабочего принципа пять частей, и примеры «так / не так» делают его применимым.

Принцип пишется не для вас, а для человека, который не был на разборе и через полгода откроет документ, чтобы решить спор. Ему нужны: формулировка, причина (откуда это взялось), примеры «так» и «не так», граница (когда принцип не применяется) и условие пересмотра.

Раскройте карточки ниже — первые три выведены из разбора выше, четвёртая показывает, как выглядит то же самое, но в виде лозунга.

Надёжная проверка принципа — попробовать решить им настоящий спор.

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

Как принцип используют в разговоре

• Сначала ссылка, потом объяснение. «У нас принцип: там, где можно откатить, — откатываем. Он отсюда-то и вот почему». Если начать с объяснения, разговор снова станет спором двух мнений.
• Спорить с принципом можно и нужно. Правильный ответ на «я не согласен с принципом» — не защита, а «давай проверим его основание». Если основание изменилось, принцип пересматривается; если нет — решение принято.
• Границу называйте сами. Когда вы первым говорите «здесь принцип не применяется, потому что действие необратимо», доверие к нему растёт. Принцип, который натягивают на всё, перестают уважать.
• Источник принципа — разбор, а не вы. Ссылайтесь на документ и на данные, а не на себя. Иначе «ссылка на принцип» снова превращается в «мнение старшего», только с лишним шагом.

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

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

Пятый навык. Самая уважаемая и самая опасная форма копирования.

Копировать лидера рынка кажется безопасным: у них большая команда, много данных, они наверняка всё проверили. Иногда так и есть. Но решение лидера часто держится на условиях, которых у вас нет.

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

Третий навык. Принцип, который нельзя пересмотреть, со временем начинает мешать.

Принцип выведен из состояния рынка и из ваших ограничений на конкретную дату. И то и другое меняется. Если основание исчезло, а на принцип продолжают ссылаться, он превращается в догму: текст остался, а причины уже нет.

Как пересматривать вслух

• Раз в полгода, на общей встрече, по списку. Двадцать минут на три принципа: основание ещё в силе? числа те же? рынок изменился?
• Решение фиксируется письменно рядом с принципом: «проверено в марте, основание в силе» или «переписан, причина такая-то».
• Историю не стирайте. Оставляйте прежнюю формулировку зачёркнутой с датой: через год кто-нибудь спросит, почему поменяли, и ответ должен быть в документе.
• Отменить принцип — нормально. Принцип, у которого исчезло основание, надо убрать, а не подпирать новыми объяснениями.
• Пересматривайте при всех. Принцип, изменённый вами в одиночку, снова становится вашим личным мнением — и команда перестанет на него ссылаться.

Провести разбор с командой и вынести из него три принципа.

Часть 1 · Разбор с командой

1. Позовите тех, кто будет принимать решения (продукт, разработка, поддержка), а не только дизайнеров. Разбор, сделанный в одиночку, потом придётся объяснять и защищать; разбор, сделанный вместе, проще принять.
2. Подготовьте материал заранее — таблицу и экраны. На встрече лучше разбирать, а не собирать: сбор в группе съедает время, а закономерности всё равно видны хуже.
3. Полтора часа, по критериям. Идите по колонкам, а не по продуктам: так видны закономерности, а не отдельные красивости.
4. Фиксируйте развилки вслух: «у троих так, у двоих иначе — из-за чего?» Именно в этих местах и рождаются принципы.

Часть 2 · Три принципа

1. Отберите находки, которые повторяются в разных местах продукта, по трём вопросам из раздела 2.
2. Запишите каждый по пяти частям из раздела 3: формулировка, причина, «так» и «не так», граница, условие пересмотра.
3. Проверьте применением. Возьмите три настоящих спора из последнего месяца и посмотрите, встаёт ли принцип на одну из сторон. Не встаёт — переписывайте.
4. Дайте прочитать тому, кто не был на разборе, и попросите решить по принципу один из этих споров. Не смог — принцип написан для вас, а не для команды.
5. Положите туда, где принимаются решения: в вики продукта, рядом с макетами, в описание задач. Не в папку дизайна.

Ориентир: полтора часа встречи плюс 4–5 часов на подготовку и запись принципов.

Что сдаём

• Разбор с критериями и датой — как на предыдущих ступенях.
• Три принципа, каждый по пяти частям, с примерами «так» и «не так».
• Проверка применением: три реальных спора и что говорит по ним каждый принцип.
• Где лежат и когда следующая плановая проверка.

Частые сложности

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

Принцип написан правильно, если

• Из него следует, что делать в конкретной развилке
• Есть причина с датой и источником — откуда он взялся
• Есть пример «не так» — то, что принцип запрещает
• Названа граница: где он не применяется
• Названо условие пересмотра
• Человек, не бывший на разборе, может по нему решить спор
• Принципов три, и их можно назвать по памяти
• Они лежат там, где команда принимает решения

Ошибки, характерные для этой ступени

• Лозунг вместо принципа. «Заботимся о пользователе» — под это подходит и решение, и его противоположность.
• Нет строки «не так». Принцип, который ничего не запрещает, не может закрыть ни один спор.
• Нет границы. Первый же случай, где принцип явно не работает, обнуляет доверие ко всему списку.
• Принцип без причины. Невозможно проверить, устарел ли он, и невозможно оспорить по существу.
• Десять принципов. Их не помнят, значит, в споре не используют.
• Принципы написаны в одиночку. Формально общие, фактически ваши личные — команда это чувствует и не ссылается.
• Вы единственный толкователь. Применить принцип без вас никто не берётся — это тот же «как решил старший», только в длинной форме.
• Принципы не пересматриваются. Основание исчезло, а ссылаться продолжают — принцип превратился в догму.
• Лидер помечен эталоном. Разбор превращается в обоснование копирования.
• «Так делают все» принято как «так работает». Существование решения выдано за доказательство его пользы.
• Данные отвергнуты ради разбора. Обратная ошибка: вам принесли цифры, ломающие ваш вывод, а вы защищаете разбор.

Тема закрыта. Ниже — вся лестница одним взглядом.

• Интерфейс. Основы проектирования взаимодействияАлан Купер и соавторы, 4-е издание · книга на русском · платнаяОткуда берётся принцип «откат вместо подтверждения»: глава 15 об отмене и истории операций, глава 21 о том, когда подтверждение не нужно, и глава 7 о принципах проектирования взаимодействия. В открытом доступе оглавление и начало главы 15.
• Crafting Product-Specific Design Principles to Support Better Decision MakingNielsen Norman Group, Мария Розала · на английском · бесплатноКак команде написать принципы продукта: каждый выбирает одну ценность против другой, их немного, пишут их вместе и ссылаются на них в спорах. Примеров «не так», границы и условия пересмотра, которые требует урок, в статье нет.
• Windows UX Design PrinciplesMicrosoft, 2014 · на английском · бесплатноВосемь принципов Windows 7 в виде вопросов-проверок. Явное «не так» есть только в одном: иконка на рабочем столе, уведомление и тур не решают проблему, если функцию не находят. Страница 2014 года, без пояснений.
• PrinciplesGitLab, дизайн-система Pajamas · на английском · бесплатноОдиннадцать принципов GitLab: у каждого вопрос для проверки и пример «так» из продукта, а примеров «не так» почти нет — удобно сравнить с тем, что требует урок. Страница обновлена в сентябре 2026 года.