Будьте осторожны! «Дизайн‑система» — это новый «брендбук». Все её хотят, потому что она выглядит красиво, весомо и по‑дизайнерски, но при этом часто забывают про реальную пользу от систематизации. Нередко получается простыня из элементов во всех состояниях, которая просто мешает развивать продукт, потому что как раз нужного‑то состояния или элемента в ней не находится.
Первый шаг — создать библиотеку повторяющихся компонентов
Рекомендую начать систематизацию с анализа того, что есть. Какие из компонентов и стилей у вас используются давно и успели доказать свою нужность и универсальность? Попробуйте собрать из них документ в Фигме. Может, получится всего несколько стилей текста, три кнопки, четыре иконки и какой‑нибудь один попап — то есть, очень небольшая часть продукта. Это совсем не похоже на то, что нам выдают за дизайн‑систему на дриблах! Но не страшно, мы ж дело делаем, а не музейный экспонат. Подумайте и нарисуйте, как эти элементы поведут себя с длинным текстом, в тёмном режиме, на маленьком экране. Потом покажите разработчикам, сделайте эталонную реализацию, оттестируйте и внедрите везде.
Результат этого шага — везде, где используются эти компоненты, они берутся из общей библиотеки, то есть код не копируется. Если в компонент внести изменение, то оно автоматически проявится везде без дополнительных усилий программистов. Прям проведите с разработчиками эксперимент: перекрасьте кнопки из красных в зелёные и поменяйте шрифт на Комик‑санс, и убедитесь, что это изменилось во всём продукте. Если это изменение заняло больше минуты, к следующему шагу переходить рано.
Дальше — развивать библиотеку вместе с продуктом
Теперь, когда библиотека разработанных и оттестированных компонентов есть, её можно развивать, постепенно переходя с несистемных компонентов на системные. Скажем, у вас в продукте есть в одном месте кнопка, в которой рядом с текстом стоит иконка, а библиотечные кнопки у вас умеют быть только текстовыми. Ну, научите библиотечные иконкам, оттестируйте, внедрите.
При этом не забывайте, что библиотека — не самоцель, а инструмент, то есть заниматься развитием библиотеки самой по себе неэффективно. Лучше развивать библиотеку вместе с продуктом: когда строите что‑то новое в продукте, заодно подтягивайте библиотеку.
Как вы знаете, мы работаем над разными задачами для Ворлд Чесс. Исторически сложилось, что в разных частях продукта были разные виды выпадающих переключалок. Хотелось их унифицировать для аккуратности и порядка, но выделять на это время среди более срочных задач было нерационально. И вот появилась задача, которая сама потребовала выпадающее меню. Разумеется, мы сразу задизайнили универсальное, чтобы можно было везде на него перейти.
Лекция «Систематизация» из курса «Пользовательский интерфейс и представление информации»
Тут уже нет результата, потому что результат типа «Дизайн‑система готова» никому не нужен, да и невозможен в живом продукте. Может оказаться, что до каких‑то частей продукта систематизация не дойдёт ещё несколько лет. Ну и что? Значит вы просто их не трогаете, потому что они не важные. Никому не мешает, что там использовано какое‑то одноразовое решение. А когда несистемность в этом месте начнёт мешать развитию самого продукта, у вас появится убедительная причина её устранить.
Лекция «Систематизация» из курса «Пользовательский интерфейс и представление информации»