Единые элементы сайта: когда компании нужна дизайн-система и что в неё включить

Нужна ли библиотека, если сайт небольшой?

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

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

Что отличает систему от красивого файла

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

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

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

Какие элементы действительно объединять

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

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

Содержание задаёт варианты

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

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

Удобная граница проходит по поведению. Объединяйте то, что посетитель узнаёт и использует повторно, а уникальную подачу содержания оставляйте странице, пока не возникнет осмысленная необходимость повторить её в другом месте.

Состояния важнее количества картинок

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

Доступность в составе обычной работы

Контраст относится к читаемости. В WCAG 1.4.3 для обычного текста указан коэффициент не ниже 4.5:1, с оговорёнными исключениями. Для крупного текста этот критерий устанавливает 3:1. Эти значения полезно закрепить в общих элементах, чтобы светло-серая подпись не возвращалась при каждом новом макете. Стандарт здесь служит выбранным ориентиром качества, а вопрос юридических обязательств сайта рассматривается отдельно.

Маленькая иконка может иметь более широкую область нажатия. Критерий 2.5.8 задаёт цель не меньше 24×24 CSS-пикселей и описывает исключения, включая расстояние между целями. Поэтому в задании различают размер рисунка и размер действующей области. Заказчик получает проверяемый признак вместо требования сделать кнопки удобными.

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

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

Как выглядит короткое задание исполнителю

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

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

Кто принимает спорные изменения

Маркетолог отвечает за смысл и названия действий, дизайнер — за внешний вид и состояния, разработчик — за повторное использование на сайте. Это пример распределения, который компания уточняет под свою команду. Решающий вопрос — кто разрешает добавить новый вариант. Без такого человека любой срочный запрос превращается в отдельную кнопку, и через некоторое время в библиотеке оказывается несколько конкурирующих решений одной задачи.

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

Цена разрозненных решений проявится при следующем изменении

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

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

Что оставить после первой сдачи

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

Разовая сборка без сопровождения быстро устаревает. Заложите обновление описания в ту же задачу, которая меняет общий элемент, чтобы документация и сайт не расходились после срочной правки.

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