Как собрать общий паттерн, чтобы одинаковые задачи решались одинаково

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

Каждый экран магазина по отдельности выглядит разумно.

Но человек, который удалил товар из корзины, а потом адрес из профиля, встречает два разных ответа на один вопрос:

«Что будет, если нажал случайно?»

Таблица к листу

Лист с экранами дополните таблицей: где задача встречается, как решена и что будет при ошибке. Таблица находит и то, что на снимках не видно.

Инвентаризация интерфейса

Дизайнер Брэд Фрост в 2013 году в своём блоге назвал такой сбор инвентаризацией интерфейса, а потом описал его в книге «Atomic Design».

Снимают не каждый экземпляр, а по одному на каждый непохожий вариант, и раскладывают по категориям. Когда похожие, но разные решения стоят рядом, лишние видны сразу.

Фрост собирал так кнопки, поля и другие детали. Для паттерна собирают не детали, а решения одной задачи.

Оставляют не то, что нравится, а то, что лучше решает задачу. Для удаления главный вопрос — чего стоит ошибка.

В Nielsen Norman Group советуют спрашивать подтверждение перед действиями с серьёзными последствиями — когда пропадает работа человека или крупная сумма денег.

Если спрашивать на каждое обычное действие, люди перестают читать вопрос и нажимают «Да» не думая. Тогда подтверждение не защищает и там, где оно действительно нужно.

Там же советуют по возможности давать отмену: она спасает от ошибки и не мешает, когда ошибки нет.

Если подтверждение нужно

Оно называет последствия, а кнопка — действие.

«Вы уверены?» с кнопками «Да» и «Нет» заставляет перечитывать вопрос.

Проверьте себя

Восемь удалений в магазине. Как удалять в каждом случае?

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

В GOV.UK Design System компоненты и паттерны разделены.

Компонент — многоразовая часть интерфейса: кнопка, поле, плашка.

Паттерн — проверенное решение задачи человека. Он часто собран из нескольких компонентов и объясняет, как применить их к случаю.

Например, «Плашка» — компонент. «Удаление с возвратом» — паттерн: в нём плашка, кнопка «Вернуть», поведение списка и тексты.

Про плашку с действием есть готовое правило в Material Design 3. У такой плашки одно действие, и она остаётся на экране, пока человек его не нажмёт или не закроет плашку. Пример в руководстве — письмо, отправленное в архив, с кнопкой Undo.

Как это устроено в GOV.UK

У страниц паттернов в GOV.UK Design System повторяются одни и те же разделы:

• когда применять;
• как работает;
• что показали исследования;
• у части — ещё и когда не применять.

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

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

Паттерн в отдельном файле находят те, кто его писал. Остальные собирают экран из компонентов и о паттерне не знают.

Дизайнер, который делает новый экран, открывает библиотеку компонентов, а не папку с документами. Разработчик открывает компоненты в коде.

Значит, паттерн должен встретиться обоим там, куда они и так идут.

В Nielsen Norman Group хранилище дизайн-системы делят на три части: руководство по стилю, библиотеку компонентов и библиотеку паттернов.

Компоненты — отдельные элементы, паттерны — их сочетания и раскладки. Это части одного хранилища, а не три разных места.

Для кода и документации есть готовые инструменты. Storybook — открытый бесплатный инструмент, в котором разработка собирает, проверяет и описывает компоненты отдельно от продукта. Туда же кладут пример паттерна.

zeroheight — платформа дизайн-системы, куда подтягиваются материалы из Figma и Storybook. Так описание паттерна и живой компонент оказываются на одной странице.

Разнобой не убирают за один спринт. Его убирают по списку мест, у каждого из которых есть статус.

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

Паттерн работает, когда по нему собирают экраны без вас. Первый такой экран стоит прочитать внимательно.

Коллега собрал экран подписки «Кофе каждый месяц» и сделал удаление товара из подписки «по паттерну». Ниже его описание.

Пять строк расходятся с паттерном «Удаление с возвратом» — с тем, как он работает, или с тем, когда его применять. Нажимайте на них.

Паттерн — не закон навсегда. Когда он перестал работать, его выводят открыто, а не молча перестают применять.

Признаки

• Его обходят. Новые экраны снова собирают по-своему, и у каждого находится причина.
• Случаи не помещаются. Раздел «Когда применять» обрастает исключениями.
• Данные против. Жалобы в поддержку, ошибки в аналитике, провалы на проверках с людьми.
• Изменилась основа. Платформа или компоненты, из которых собран паттерн, стали другими.

Вывод по статусам

Так устроено в больших системах. В Atlassian Design System у компонентов три фазы выпуска и две фазы вывода:

• «собираемся вывести» — в новом не использовать, брать замену;
• «выведен» — заменитель назван, переезд описан.

Ни один стабильный компонент там не удаляют без заранее объявленного срока.

В GOV.UK Design System с августа 2026 года у компонентов два статуса — «проба» и «стабильный». Компонент на пробе может заметно измениться или быть выведен.

Сказать вслух

Это четыре действия:

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

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

Часть 1 · Инвентаризация, 1 час

1. Выберите задачу, которая встречается на многих экранах: удаление, пустой поиск, подтверждение действия, выбор даты, ошибка в форме.
2. Найдите все места, где она решается. Снимите по одному экрану на каждое непохожее решение.
3. Сведите в таблицу: где, как решено, что будет при ошибке, какой текст.

Часть 2 · Паттерн, 2 часа

1. Выберите решение по цене ошибки, частоте и данным. Если данных нет, проверьте варианты на людях.
2. Опишите паттерн по шаблону. «Когда не применять» пишите сразу после задачи.
3. Положите описание рядом с компонентами и поставьте на него ссылку из каждого компонента, который в нём участвует.

ПАТТЕРН: ______________________   статус: проба / принят / под вопросом / устарел
владелец: ______________   дата: __.__.____   пересмотр: __.__.____

ЗАДАЧА: ______________________
КОГДА ПРИМЕНЯТЬ: ______________________
КОГДА НЕ ПРИМЕНЯТЬ и что вместо: ______________________

КАК РАБОТАЕТ
шаги: ______________________
состояния: ожидание / успех / ошибка / нет связи: ______________________
крайние случаи: ______________________

ТЕКСТЫ: ______________________
КОМПОНЕНТЫ (ссылки на библиотеку): ______________________
ПОЧЕМУ ТАК (данные, проверки, жалобы): ______________________

ГДЕ ИСПОЛЬЗУЕТСЯ
место ______________   заменено / в работе / позже / оставлено, причина ______________
место ______________   заменено / в работе / позже / оставлено, причина ______________

ЖУРНАЛ
__.__.____ · что изменилось ______________ · почему ______________

Часть 3 · Замена, по списку мест

1. Замените два места: самое дорогое по ошибке и то, которое и так сейчас в работе.
2. Остальным дайте статус и, где нужно, причину.
3. Скажите команде: что за паттерн, где лежит, с какого дня новые экраны собираются по нему.

Что должно получиться

• Лист инвентаризации с тремя и больше решениями одной задачи.
• Описание паттерна рядом с компонентами, со ссылками из них.
• Список мест со статусами, два места заменены.
• Сообщение команде и первая запись в журнале.

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

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

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

Паттерн готов, если

• Решения задачи со всех экранов собраны на один лист
• Решение выбрано по цене ошибки и данным, а не по вкусу
• В описании есть «когда применять» и «когда не применять»
• Описаны поведение, состояния и крайние случаи
• Есть готовые тексты
• Паттерн лежит рядом с компонентами, из компонентов на него есть ссылка
• Места с разнобоем выписаны, у каждого статус
• У паттерна есть статус, владелец и журнал изменений

Что мешает

• Паттерн-картинка. Есть макет, нет «когда не применять» — и паттерн применяют везде.
• «Заменим всё сразу». План на полгода, который никто не начинает.
• Отдельный документ. О паттерне знают только авторы.
• Молчаливое устаревание. Паттерн не работает, а в библиотеке висит как принятый.
• Обманный паттерн в библиотеке. Его повторяют в каждом новом экране.

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

• The Atomic WorkflowAtomic Design, Брэд Фрост, глава 4 · книга на английском · полный текст открыт на сайте книгиКак провести инвентаризацию интерфейса: снимать по одному примеру каждого непохожего решения, раскладывать по категориям (ошибки, успех и загрузка — отдельная, их труднее всего поймать) и показывать разнобой всей команде. Это около трети главы; остальное — как продать дизайн-систему и работать без водопада.
• Patterns · Contribution criteria · Component lifecycle statusesGOV.UK Design System · на английском · бесплатноЧем паттерн отличается от компонента в GOV.UK Design System и по каким пяти признакам решают, принимать ли новый: полезен многим командам, не повторяет существующее, проверен на людях, собран из готового, подходит разным сервисам. Третья ссылка — два статуса компонентов, «проба» и «стабильный».
• Confirmation Dialogs Can Prevent User Errors — If Not OverusedNielsen Norman Group, Якоб Нильсен · на английском · бесплатноВосемь правил для подтверждений: спрашивать только перед тем, что уничтожает работу или стоит больших денег, называть последствия, подписывать кнопки действием («Удалить файл» и «Оставить файл» вместо «Да» и «Нет»), а для самых опасных действий просить ввести слово. Статья 2018 года, пересмотрена в 2026-м.
• Release phasesAtlassian Design System · на английском · бесплатноТри фазы выпуска (Early Access, Beta, General Availability) и две фазы вывода (Intent to Deprecate, Deprecated): что значит каждая и можно ли брать компонент в новую работу. Стабильное не удаляют без объявленного заранее срока. Страница на минуту чтения.
• Types of deceptive patternDeceptive Patterns, Гарри Бриньолл · на английском · бесплатноВосемнадцать типов обманных паттернов — от скрытых доплат до стыжения (confirmshaming) и подписки, которую трудно отменить: у каждого определение, пример, случаи из «Hall of shame», законы и решения регуляторов. У двух самых новых типов законов пока нет, только примеры.