Скетч-дизайнер

Анализ ошибок: Чего не должно быть в дизайн-системе

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

С подачи поста Юрия Ветрова про сложности внедрения ДС, хочу рассказать, с какими глобальными подводными камнями можно столкнуться по пути.

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

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

Я выделил четыре проблемы:

1. Продукт на этапе созревания

Он постоянно меняется и сильно символизировать его рановато. Жёсткие правила и прибитые гвоздями символы устаревают и превращаются в технический долг. Особенно это касается символов с контентом.

2. Всем плевать на горячие клавиши, точные названия символов и поле поиска. Удобного каталога символов не было

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

3. Замусоривание частностями

Рано или поздно в UI-кит начинают попадать такие вещи, которые его замусоривают. Библиотека стала настолько огромна, что стала чёрным ящиком для всех, кроме меня.

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

Я включил в неё все хлебные крошки (чтобы были рядом в столбик, удобно же!), глобальный хедер и сайдбар со списком продуктов. Это было ошибкой: другие дизайнеры не могут менять библиотеку и матерятся, делая детач каждому встречному символу.

4. Слишком сложные названия

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

02-buttons / 05-button-big / 04-button-big -blue -disabled

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

Продолжение следует.