Что важно учитывать и с какими неожиданными сложностями вы можете столкнуться при создании и внедрении UI-кита? Делюсь опытом нашей команды: как косячили, ругались и делали выводы.
Привет! Я Камиля, UX/UI дизайнер. Не так давно участвовала в проектировании сервиса для музея, где за мной была закреплена задача по созданию UI-кита с нуля. Подробнее о проекте и обо всех процессах работы можно почитать в статье моей коллеги, я же поделюсь вынесенными уроками из создания UI-кита.

Что такое UI-кит? (спойлер: речь не о больших рыбах)
UI-kit — неотъемлемая часть дизайн-системы, включает в себя готовый набор элементов интерфейса: типографику, цветовую палитру, систему отступов, компоненты в различных состояниях. UI-кит можно воспринимать как множество кирпичиков, из которых строится интерфейс.

UI-киты позволяют поддерживать консистентность проекта, ускоряют и упрощают работу (особенно когда над проектом трудится команда дизайнеров), уменьшают вероятность ошибки.
К созданию UI-кита стоит приступать только после утверждения дизайн-концепции и согласования стилеобразующих страниц. Далее поддерживают его актуальность всё время развития продукта.
У меня был опыт создания UI-кита для личных проектов, но для проекта, над которым работает команда дизайнеров, я делала UI-кит впервые.
Итак, что я хотела бы знать о создании UI-кита, которым впоследствии будет пользоваться команда, ДО того как приступила к работе над ним? Это уберегло бы меня от многих ошибок, сэкономило время и нервы (моргни, если тоже уже потерял смысл слова UI-кит).
1. Прикидывайте, как внесенные вами изменения отразятся на страницах
При создании UI-кита вы можете вносить в проект изменения — значительные или не очень. Всегда смотрите, как будут выглядеть уже утверждённые страницы с заданными вами правилами.
Задача не в том, чтобы внести минимальные изменения, а в том, чтобы UI-кит содержал в себе стили и компоненты, использование которых обосновано и закрывает все необходимые потребности.
2. Не экономьте время на расписывание того, как пользоваться UI-китом
Хороший дизайнер думает об удобстве не только пользователей, но и коллег.
Где используется этот стиль текста? А этот стиль цвета? Какой тут должен быть отступ?
Сэкономьте время себя из будущего, которое вы потратите на бесконечные вопросы, если проигнорируете это правило.
А ведь вопросы будут только в лучшем случае. В худшем ваш коллега попросту сделает так, как посчитает нужным, и консистентность проекта покинет чат.
Делайте понятный нейминг, добавляйте описания, наглядно показывайте примеры использования.
3. При введении системы отступов будьте готовы к недовольству дизайнеров из-за того, что их объекты сдвинули
Чтобы постараться минимизировать недовольства, обговорите до отрисовки концепций хотя бы сетку: количество колонок и расстояние между ними. Так дизайнеры будут рисовать концепции в уже заданных рамках, а изменения после введения отступов будут не такие значительные.

4. Не бойтесь кардинально схлопывать шрифты, если их беспричинно много
На нашем проекте насчитала только на главной странице 30 стилей, что много даже для целого сервиса. Схлопнула в два раза (действовала аккуратно, схлопывала только похожие), прикидывая изменения на страницах (п. 1). Осталось 15, отправила на согласование лиду, произошёл такой диалог (подчёркиваю, это он увидел количество стилей уже ПОСЛЕ сокращения):

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

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

Если столкнётесь с подобным, объясните команде, что шрифтов было необоснованно много, а нам важна простота в использовании. Всегда представляйте, что к вашей работе присоединится новый диз, и ему придётся вникать в эти 30 стилей… Часть из которых использовались необоснованно, а иногда шрифт менялся просто потому, что дизайнер в моменте так чувствовал блок.
Консистентность и унификация, о которых я писала выше, важнее креатива. Не нужно искусственно усложнять количество стилей ради картинки — в проектах всегда будут ограничения, и нужно уметь качественно работать в заданных рамках.
6. Цвета в UI-кит добавляются не столько по оттенку, сколько по тому, где эти цвета используются
То есть в UI-ките два одинаковых оттенка могут быть забиты в разные стили (например, первый будет для фона, а второй — для шрифтов и иконок). В таком случае, если мы захотим изменить оттенок только у одной группы, у нас не возникнет сложностей.
Цвета тоже старайтесь не плодить, особенно оттенки серого.

7. Третье недовольство дизайнеров может быть связано с изменением оттенков их цветов
Главный инсайт, полученный от работы, заключался в том, что дизайнеры очень прикипают к своим дизайнам, и им тяжело мириться с любыми изменениями в макетах. Поэтому готовьтесь аргументировать каждое своё решение. В этом случае аргументация будет примерно такая же, как в случае со шрифтами.
8. Старайтесь делать компоненты «тупыми»
Идея тупых и умных компонентов подробно описана в этой статье.
Если кратко: тупые компоненты удобнее переиспользовать, потому что они — универсальные кирпичики построения интерфейса — содержат в себе максимальное количество состояний и элементов.
9. Считайте размер текстового контейнера в компоненте так, чтобы он вмещал в себя самые длинные слова/фразы и компонент при этом продолжал выглядеть хорошо
Вы будете себе за это благодарны. Просто поверьте.

10. В процессе работы смотрите готовые UI-киты
Они очень помогли мне в работе. Обращала особое внимание на сборку и нейминг. Сравнивала, что и как там реализовано, адаптировала всё под наш проект и задачи. Если для вас это тоже новый опыт, опирайтесь на работы более опытных коллег.
Человек, отвечающий за сборку UI-кита, смотрит на проект как бы сверху. Ему нужно иметь в виду все возможные состояния и случаи использования; важно сделать универсально, гибко и удобно для коллег. Для этого иногда придётся идти на компромиссы. Но именно они приведут к более стройным решениям в рамках продукта.
С макетами проекта и UI-китом для десктопа можно ознакомиться в фигме.
Всё написанное выше — исключительно мой опыт и выводы. Если есть что добавить, приглашаю в комментарии.
Также открыта для предложений и сотрудничества. Мой телеграм-канал.
Спасибо!
Комментарии (7)
Slavatitov173
14.02.2025 19:31Есть конкретные примеры тех китов, на которые ты ориентировалась в работе? Это в догонку по Пункту #10, сейчас у нас в тиме сложности не столько в создании составляющих, сколько в грамотной упаковке всего этого добра и в понятном нейминге.
Буду очень благодарен)
Spyman
14.02.2025 19:31Посягну на святое, но все-же интересно.
А есть какие-то доказательства - что ui кит - это вообще хорошая идея? Или набор правил - когда его стоит составлять, а когда забить.
В бытности аутстафф сотрудника поработал на десятках проэктов разных размеров и масштабов и методов разработки. И оооочень редко встречались достаточно масштабные проекты, где с точки зрения именно разработки ui кит себя оправдывал. Зато несколько раз были проекты - где ui кит был отдельным слоем который приходилось поддерживать и дорабатывать непрерывно, при том что никаких бонусов он не давал (новый функционал требовал новых компонентов или непростительных извращений со старыми, новые компоненты требовали недели дизайнинга, вагон согласований и макетов состояний). Переиспользовались в лучшем случае шрифты, цвета и кнопки.
suniverse
14.02.2025 19:31Это актуально для проектов с длинным циклом разработки и несколькими продуктовыми командами. Тогда нужны правила разработки и приемки дизайна и верстки, иначе изуродуют проект. Например в крупных интернет-магазинах бывает больше 10 продуктовых команд, работающих параллельно.
GiveMeFreeNickName
Тоесть, я правильно понял, надо потратить кучу рабочего времени на аргументацию недовольным дизайнерам того, почему они должны делать то, за что им платят?
Kenya-West
Как ни странно, у дизайнеров точно такая же работа и позиция в отношении всех других сторон, в том числе начальника, продукт овнера и инвесторов. И они тоже правы, но по-своему, вплоть до степени полной неправоты. Но правы.
В случае непримиримого спора имеет смысл эскалировать вопросы, а дальше тупо чиллим.
Лично я, как рядовой фронтенд-разнорабочий (специально отказался от повышения грейда и выбрал вместо этого повышение ЗП, чтобы сэкономить нервы), имеющий тесные отношения с дизайнерами и ходящий в основном под ними, в сложных случаях вообще дурачком прикидываюсь, искусственно понижаю свой IQ и пускаю слюни - здорово помогает! Главное, до вызова "скорой" не доводить.