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

Автор: Джей Томас

Создатель фреймворка “Думать как пользователь”

Определение целей и ограничений

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

Им можно сделать email-рассылку с предложением участия в исследовании.

Инструменты и среда

Подготовьте пространство для работы:

Планирование по слоям

Методология проработки атрибута Appearance предлагает двигаться в разрезе шести слоев. На старте полезно наметить план работы по каждому из них:

Снижение когнитивной нагрузки. Интерфейс должен требовать минимум умственных усилий для понимания. Используйте принцип “7±2” Миллера: человеческая кратковременная память одновременно удерживает около 5–9 элементов, поэтому не показывайте слишком много объектов сразу.

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

Ограничивайте число одновременных опций на экране—так пользователь быстрее примет решение (закон Хика гласит: время выбора растёт с количеством вариантов). Если опций много, структурируйте их: примените фильтры, категории или прогрессивное раскрытие (когда дополнительные детали показываются по мере необходимости, а не сразу).

Адаптация к ограничениям внимания. Учитывайте, что внимание пользователя рассеянное и быстро истощается. Важные элементы должны быть заметны с первого взгляда—это обеспечивается визуальной иерархией (о ней подробнее на визуальном слое).

Не заставляйте пользователя помнить информацию между экранами: лучше повторно покажите нужные данные. Например, при заполнении формы, если следующий шаг требует ранее введённых данных, отобразите их на экране (паттерн Reduce Short-Term Memory Load—”уменьшение нагрузки на память”—рекомендует внешне хранить информацию, чтобы не напрягать память пользователя).

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

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

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

Каждый элемент интерфейса также должен выглядеть согласно своей функции (принцип affordance, или “воспринимаемое назначение объекта”): например, кликабельные элементы отличаются визуально (подчёркнутый текст, выпуклая кнопка)—тогда пользователь интуитивно понимает, что на них можно нажать.

Поддержка принятия решений. Хороший интерфейс направляет пользователя по оптимальному пути, уменьшая время раздумий. Мы уже упоминали закон Хика (про количество опций)—его применение в UI означает: не перегружайте экран десятками равнозначных действий. Лучше выделите рекомендуемое действие (например, яркая кнопка “Добавить” на пустом экране списка, чтобы подсказать следующий шаг). Менее важные действия уберите в контекстное меню или вторичный экран.

Также помогает визуальный акцент на основных CTA (Call to Action)—контрастной заливкой или размером кнопки. И, напротив, второстепенные действия оформляйте как текстовые ссылки или бледные кнопки. Это упрощает выбор: пользователь ясно видит, куда нажать, чтобы достичь цели.

Предотвращение ошибок пользователя. С точки зрения поведения пользователя, интерфейс должен заранее снижать шанс неправильных действий. Относятся ли ошибки к визуальному атрибуту? Да, потому что многие механизмы предотвращения ошибок реализуются визуально: неактивные (disabled) состояния кнопок до заполнения обязательных полей, предупреждающие всплывающие сообщения при потенциально рискованных действиях, подтверждения удаления (”Вы уверены?”) и т.д..

Например, паттерн Error Prevention предполагает показать понятный маркер или подсказку, если пользователь делает что-то нежелательное.

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

Какие элементы обязательны на экране (исходя из пользовательских задач).

Где нужны подсказки, поясняющие тексты.

Какие интерфейсные паттерны будут использоваться (типовые расположения кнопок, иконки для действий, формы ввода с валидацией и т.д.).

Каких когнитивных перегрузок удалось избежать (например, длинный список разделён на вкладки, сложная функция вынесена в мастер-шаги и пр.).

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

Например, карточка товара или клиента должна выглядеть и работать одинаково во всех разделах системы—будь то список, поиск или отчет. Модульный подход означает, что мы сначала проектируем типовые “блоки” (скажем, панель поиска, профиль пользователя, навигационное меню), а потом комбинируем их. (Этот принцип потом ляжет в основу дизайн-системы на организационном слое).

Пример: В CRM-системе карточка контакта может использоваться и в разделе клиентов, и в разделе сделок, и в аналитических отчетах. Сделав ее однажды продуманной и самодостаточной, мы обеспечим единообразие и сэкономим время на разработке новых разделов.

Логичная структура и иерархия компонентов. Каждый экран должен иметь чёткую организацию: что главное—то наверху и выделено, что вторичное—сгруппировано и не мешает. Функциональный слой уже частично реализует визуальную иерархию (еще до детальной отрисовки): например, в макете дашборда аналитики мы закладываем крупные блоки для ключевых метрик в верхней части, а вспомогательные таблицы—ниже. Также структура должна отражать последовательность действий пользователя. Принцип “фокус на задаче, минимум лишнего” гласит: на экране только то, что нужно для текущей задачи, ничего больше. Если какой-то элемент не помогает пользователю в данном контексте—возможно, его стоит вынести на другой экран или спрятать под спойлер.

Пример: В таск-трекере типа Asana список задач по проекту показывает основную информацию (название задачи, ответственный, срок). Детали каждой задачи скрыты и открываются только при клике на задачу—это и есть прогрессивное раскрытие, позволяющее не загромождать экран деталями, пока они не нужны.

Консистентность и стандартизация. Функциональный слой устанавливает единые шаблоны: одинаковые элементы должны выглядеть и располагаться одинаково. Это облегчит жизнь пользователю (интерфейс предсказуем) и упростит сопровождение. Речь про базовые договоренности: например, все страницы списка в вашем приложении имеют вверху заголовок + кнопку “Добавить”, справа—панель фильтров, и т.д. Стандартизация снижает вероятность ошибок и ускоряет обучение пользователей.

Пример: В текстовых редакторах (Google Docs, Microsoft Word) панель инструментов и меню устроены схоже для разных документов—пользователь не тратит время на поиск, потому что везде однообразие.

Гибкость для разных типов пользователей. Продуманная функциональная структура учитывает как новичков, так и опытных пользователей. Новичкам—понятный базовый путь (никаких скрытых возможностей, всё основное на виду). Экспертам—альтернативные пути для ускорения работы. Это может означать наличие горячих клавиш, массовых операций, настраиваемых панелей. На дизайне функционального слоя закладываем такие возможности: например, предусмотрим чекбоксы для выбора нескольких элементов сразу и кнопку “Удалить выбранные” (опытные юзеры оценят пакетные действия), или возможность переключиться на компактный вид списка для отображения большего количества строк одновременно.

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

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

Простота выполнения задач: проведите внутреннее heuristic evaluation по критерию эффективности: сколько шагов требуется, чтобы выполнить типичные задачи? Можно ли сократить? Все ли очевидно, куда кликнуть вначале и затем? Если какие-то операции кажутся слишком сложными или спрятанными, вернитесь и упростите макет.

Consistency review: просмотрите все экраны вместе—едина ли структура? Повторяются ли шаблоны навигации, заголовков, расположения кнопок от экрана к экрану? Хороший признак—если можно описать “правило”, например: “во всех справочниках есть поиск в правом верхнем углу; на всех формах кнопка Сохранить внизу справа”. Если обнаружатся отклонения без веской причины – лучше привести к одному стилю до перехода к визуальному оформлению.

Покрывают всю необходимую функциональность продукта.

Имеют логичную навигацию между собой (продуманы переходы, ссылки, меню).

Содержат согласованный набор стандартных компонентов (однотипные элементы унифицированы).

Не содержат ничего лишнего: каждый элемент оправдан задачей пользователя.

Гештальт-принципы организации восприятия. Эти принципы из психологии восприятия описывают, как человек группирует элементы в единое целое. В UI-дизайне они помогают структурировать интерфейс:

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

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

Типографика и читабельность. Текст—основной носитель информации, поэтому шрифтовой стиль критичен:

Единый стиль и брендирование. Все визуальные элементы должны быть стилистически едины и отражать характер продукта. Если у бренда есть фирменные иллюстрации, иконки—используйте их. Если нет, держитесь выбранной стилистики везде: например, если выбраны плоские (flat) иконки—все иконки в продукте должны быть flat, без смешения с объемными. Толщина линий в пиктограммах, скругления уголков у кнопок, стиль теней—всё должно казаться частью одного набора. Этого легко добиться, если на визуальном слое у вас сформированы дизайн-токены—фиксированные значения для цвета, границ, скруглений, тени и пр. (например, все кнопки имеют радиус скругления 4px, и нигде 8px).

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

Визуальная иерархия: Возьмите несколько экранов и попросите коллегу или пользователя взглянуть на 5 секунд, затем спросите—что привлекло внимание? Ответ должен совпадать с тем, что вы планировали главным. Если нет—возможно, акценты расставлены неверно. Например, если человек заметил яркую картинку-рекламу вместо формы ввода, стоит уменьшить её влияние (сделать менее контрастной или переместить).

Консистентность: Просмотрите все экраны в одном обзоре—соответствуют ли они друг другу по стилю? Нет ли “инородных” элементов? Например, случайно разная толщина рамок в похожих полях или разные тени у кнопок—такие мелочи должны быть устранены. Единый стиль—признак проработанного Appearance.

Контраст и читабельность: Протестируйте макеты в градациях серого (многие графические редакторы позволяют временно убрать цвет). Так вы увидите, достаточно ли контрастен текст и кнопки без влияния цвета. Везде ли мелкий текст читается? Убедитесь, что фон не сливается с элементами.

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

Имеют применённую цветовую схему, шрифты, иконки—согласно выбранному стилю.

Чётко передают иерархию информации (главное выделено, второстепенное отступает на второй план).

Выглядят привлекательно и современно, внушают доверие.

Соответствуют единому стилю и бренд-айдентике.

Обратная связь и отзывчивость (Feedback & Responsiveness). Каждый клик или действие пользователя должно сопровождаться заметной реакцией системы. Это базовый принцип: пользователь не должен гадать, сработала ли кнопка—мы сразу показываем, что произошло.

Способы: подсветка нажатой кнопки, лоадер (индикатор загрузки) при ожидании ответа, сообщение об успешном сохранении и т.п. Принцип мгновенной обратной связи гласит, что даже если действие длительное (загрузка), интерфейс мгновенно реагирует хотя бы изменением состояния кнопки на "нажата/в процессе".

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

Состояния элементов управления. Все интерактивные компоненты имеют несколько состояний: обычное, при наведении (hover), при клике (active), неактивное (disabled), фокус ввода и т.д. Эти состояния нужно продумать и отрисовать. Пользователь по визуальному состоянию элемента понимает, как с ним взаимодействовать или почему он сейчас недоступен.

Пример: Неактивная кнопка “Отправить”—серая и не нажимается, появляется подсказка “Заполните обязательные поля”—предотвращение ошибки и ясность состояния.

Микровзаимодействия и анимации. Небольшие анимационные эффекты при взаимодействии делают опыт более плавным и дают дополнительную информацию. Это могут быть вспыхивающие подсказки, плавные переходы, анимация на кнопке при нажатии. Важно: анимация должна быть краткой (200–300 мс) и функциональной, не отвлекающей.

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

Адаптивность (Responsive/Adaptive design). В современном мире интерфейс обязан работать на разных разрешениях—от мобильных до больших мониторов. На интерактивном слое прорабатывается, как макет перестраивается под разные экраны: что происходит с меню на мобильном (например, свернётся в гамбургер), как масштабируются таблицы (горизонтальный скролл или складывание колонок), как изменяются отступы и размеры шрифта. Цель—сохранить удобство и доступность функций на любом устройстве.

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

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

Контекстная обратная связь. Речь про то, где именно отображаются сообщения о результате действий. Лучше всего в контексте самого элемента, а не на другом конце экрана. Например, ошибка в поле ввода должна сразу под этим полем поясняться (красным текстом), а не только в виде всплывающего тоста в углу. Контекстные подсказки позволяют пользователю быстро понять, что произошло именно там, где он взаимодействовал.

Пример: В Google Docs при сохранении документа появляется статус "Сохранено" прямо в заголовке окна документа—пользователь видит подтверждение, не отвлекаясь от текста.

Устойчивость к ошибкам и отмена действий. Интерфейс должен позволять пользователю легко исправить ошибку или отменить действие. Например, если удаление чего-то нельзя восстановить—нужно на интерактивном слое предусмотреть диалог подтверждения. Если действие выполнимо частично—показать предупреждение. Опционально, можно добавить функцию “Undo” (Отмена последнего действия)—многие современные приложения вводят плавное убирание элемента с возможностью нажать “Отменить” в течение нескольких секунд. Всё это внушает пользователю уверенность: он не боится нажать лишнее, зная, что интерфейс прощающий и не накажет необратимыми последствиями.

Создайте интерактивный прототип (в той же Figma или другом инструменте) со всеми переходами и основными состояниями. Пройдите сценарии: понятно ли, где кликнуть? Есть ли задержки или моменты, где непонятно, произошёл ли отклик?

Тест на разных устройствах: запустите макеты на нужных разрешениях (или используйте responsive-режим браузера) – все ли элементы доступны? Не обрезается ли текст, не уезжают ли кнопки за пределы экрана?

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

С точки зрения UX, можно провести коридорный тест: дать пользователю прототип на телефоне и на компьютере, попросить выполнить пару действий. Если он не понимает, нажалась ли кнопка или ищет элемент, которого не видно—это сигнал доработать интерактивность или адаптивность.

Все экраны связаны переходами, в том числе альтернативные пути, модальные окна, выпадающие меню.

Для ключевых элементов прорисованы состояния (в дизайне—отдельные спецификации или фреймы: кнопка normal/hover/disabled/active, поля ввода empty/focus/filled/error и т.д.).

Описаны или показаны анимации: переходы экранов, лоадеры, микроанимации.

Макеты адаптивного дизайна подготовлены (обычно это отдельные версии ключевых страниц для мобильного разрешения).

Обеспечить ясность: пользователю должно быть сразу понятно значение каждого элемента (благодаря надписям, меткам, подсказкам).

Обеспечить достаточную информативность: где нужно—дать объяснение, контекст, пример.

Выдержать тон общения с пользователем, соответствующий бренду и ситуации (где-то официально, где-то с юмором—в зависимости от продукта).

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

Краткость и ясность. Тексты интерфейса должны быть максимально лаконичными, но при этом информативными. Пользователь сканирует экран, а не читает роман, поэтому формулировки—короткие, в прямом утвердительном залоге. Правило одной мысли: одна UI-единица (кнопка, пункт меню)—одна идея, выраженная несколькими словами.

Пример: Вместо длинной кнопки “Нажмите для сохранения настроек” пишем просто “Сохранить настройки”. Вместо “В вашем профиле не заполнен email, без этого вы не сможете восстановить пароль” пишем кратко: “Укажите email для восстановления пароля.”

Состояния элементов управления. Все интерактивные компоненты имеют несколько состояний: обычное, при наведении (hover), при клике (active), неактивное (disabled), фокус ввода и т.д. Эти состояния нужно продумать и отрисовать. Пользователь по визуальному состоянию элемента понимает, как с ним взаимодействовать или почему он сейчас недоступен.

Пример: Неактивная кнопка “Отправить”—серая и не нажимается, появляется подсказка “Заполните обязательные поля”—предотвращение ошибки и ясность состояния.

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

Пример: Под полем ввода телефона можно мелким текстом указать “Без кода страны, только 10 цифр”. Пользователь сразу понимает требование и с меньшей вероятностью ошибётся.

Единый голос бренда. Все тексты—от заголовков до мелких уведомлений—должны быть написаны в едином стиле, который соответствует бренду и аудитории. Если это банковское приложение—тон может быть профессиональный, спокойный. Если молодежный сервис—более неформальный и дружелюбный. Главное—последовательность: не смешивать разные стили в одном продукте.

Также учитывайте эмоциональный контекст: сообщения об ошибке—сочувственные и помогающие (”Не удалось загрузить данные. Проверьте подключение.”), успех—ободряющий (”Готово! Задача выполнена.”).

Пример: В корпоративной финансовой системе уведомление может звучать официально: “Отчет успешно сформирован.” В приложении для командной работы более живо: “Отлично, отчет готов!”. Стиль разный, но каждый выдержан последовательно внутри своего продукта.

Консистентность терминологии. Термины и названия одних и тех же сущностей должны быть одинаковыми во всех местах. Если у вас есть “задачи”—везде называйте их задачами, а не где-то “tickets”, где-то “items”. Согласованность контента убирает когнитивное напряжение от лишних терминов. Заведите глоссарий основных терминов продукта и придерживайтесь его. Особенно это важно, если несколько авторов пишут тексты—нужна единая редакционная политика.

Доступность контента. Контентный слой тесно связан с понятием accessibility. Убедитесь, что:

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

Тест на понимание: дайте незнакомому с продуктом человеку прочитать тексты вне контекста (например, список пунктов меню или сообщение ошибки)—понятно ли ему, о чем речь? Если нет, возможно, нужно уточнить формулировку. Иногда полезно использовать сервисы оценки читабельности текста (например, индекс Flesch-Kincaid, хотя для русского он менее распространен)—но в интерфейсах обычно и так очень короткие фразы.

Юзабилити-тестирование контента: На этапе тестирования (атрибут Usability) особое внимание уделяется тому, не вводят ли тексты пользователя в заблуждение. Уже сейчас, на контентном слое, можно провести небольшой опрос пользователей: например, показать несколько вариантов надписи на кнопке (”Завершить” vs “Готово” vs “Сохранить изменения”)—какой понятнее назначение действия? Контент—это тоже то, что можно итеративно улучшать по обратной связи.

Собрать все созданные визуальные компоненты, стили и паттерны и оформить их в централизованную библиотеку.

Обеспечить механизм обновления дизайна: например, если нужно поменять цвет брендв—чтобы это можно было сделать один раз в системе, и изменение распространилось везде.

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

Наладить процесс версиирования дизайна и коммуникации команды (дизайнеров, разработчиков, продакт-менеджеров) через артефакты дизайн-системы.

Единый источник правды (Single source of truth). Всё—от палитры цветов до кода компонентов—должно храниться централизованно и быть доступно команде. Обычно это реализуется через специальные инструменты: например, библиотека стилей в Figma + Storybook для компонентов в коде. Принцип: дизайнеры и разработчики используют одни и те же описания компонентов, чтобы не расходиться в мелочах.

Модульность и повторное использование. Мы уже закладывали модульность на функциональном слое; на организационном это проявляется в создании библиотеки компонентов. Каждый часто используемый элемент (кнопка, инпут, карточка, модальное окно и т.д.) оформляется как самостоятельный компонент в системе, с возможностью настройки параметров (вариантов).

Пример: В SaaS-продукте для аналитики в библиотеке будут модули графиков, таблиц, фильтров, из которых потом собираются разные страницы. Это экономит время (не рисуем и не разрабатываем заново похожие вещи) и гарантирует единообразие интерфейса.

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

Пример: Дизайн-система крупной платформы содержит разделы: кнопки (с примерами и кодом), формы (с правилами валидации и сообщениями об ошибках), навигация, и пр. Это облегчает внедрение новых людей и поддерживает целостность интерфейса.

Масштабируемость и адаптивность системы. Организационный слой предусматривает рост продукта: добавление новых функций, поддержка новых платформ. Дизайн-система должна быть гибкой к изменениям. Например, при добавлении нового модуля продукта мы должны суметь создать новые экраны, комбинируя существующие атомы и молекулы, и при необходимости аккуратно расширить систему новыми элементами, не ломая существующее.

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

Управление версиями и совместная работа. Время от времени дизайн-система обновляется—важно отслеживать её версии, чтобы разработчики знали, что изменилось. Принцип: координация изменений. Внедряйте процессы, при которых изменение в дизайн-системе (например, новый стиль заголовков) коммуницируется всей команде, и все синхронно переходят на новую версию. Это часто достигается через хранение системы в репозитории (например, Git для кода компонентов) и рассылку уведомлений о обновлениях.

Атомы—самые базовые элементы (кнопка, поле ввода, иконка, цветовая переменная).

Молекулы—сочетания атомов, образующие функциональный элемент (например, поле поиска = поле ввода + иконка-лупа-кнопка).

Организмы—сложные блоки UI, объединяющие несколько молекул и атомов (например, шапка сайта с логотипом, полем поиска, меню и аватаром пользователя).

Шаблоны—макеты страниц, размещающие организмы в структуру, но без конкретного контента (каркас).

Страницы—готовые экраны с реальным контентом.

Дизайн-система охватывает все элементы, использованные в продукте (нет “оторванных” решений, которые существуют только в одном месте и не описаны).

Команда может быстро собрать прототип нового экрана, используя лишь документацию дизайн-системы (т.е. она достаточно полна и понятна).

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

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

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

Библиотека компонентов (в design tool, например, Figma, и в коде).

Документация (гайдлайн) по использованию компонентов, стилей, отступов, примеры экранов.

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

UX-проектировщик; создает команды UX-исследований, руководит командами дизайна, внедряет в компаниях Jobs to be Done. На протяжении 10 лет разрабатывает как сложные узкопрофильные админ-панели, так и функции, которыми пользуются многомиллионные аудитории.

В прошлом руководил командой развития пользовательского опыта в Домклик, и там же—руководил дизайн-системой. Приглашенный лектор в ВШЭ и Bang Bang Education. Обучался JTBD в Harvard Business School.

Работал с ONY, QIWI, Сбером, ЦИАН, Мегафон, Shell, МТС, Adidas и другими командами.