Когда бизнес-сайту нужна дизайн-система и с каких компонентов её начать

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

Соберите примеры вокруг действий

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

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

Решите, что действительно стоит стандартизировать

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

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

Опишите состояния одного компонента

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

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

Проверьте пилот в настоящем маршруте

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

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

Определите собственника изменений

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

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

НОУ-ХАУ

Свобода от рекламной зависимости – за 1 день

ЛидБлог за 1 день превращает сайт в канал привлечения новых клиентов из Яндекс, Google и поиска в нейросетях. Работает без вашего участия

Дмитрий РучинВ маркетинге с 2011 года

.PDF ФАЙЛ

Выберите способ связи и укажите номер, чтобы получить персональный план привлечения клиентов с помощью нового канала «ЛидБлог» и узнать стоимость внедрения

Куда направить?

На телефонTelegramMAX

ТелефонСайтСКАЧАТЬ PDFСогласен на обработку персональных данных согласно политике обработки данных.

Вопросы и ответы