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