Как театр начинается с вешалки, так и разработка крупных проектов начинается с создания дизайн-документации. Учитываются базовые компоненты, которые точно будут в макетах: кнопки, элементы навигации, секции и т.д.
Вроде бы всё понятно и для дизайна, и для разработки, но есть одно НО
Основная проблема команд – отсутствие или недостаточность коммуникации между отделами/компетенциями
Из-за этого возникают ситуации, в которых дизайнер закладывал одно наименование, а разработка использовала другое. Отсюда беспорядок в системе, абсолютное непонимание, на что ссылаться. Даже при выходе нового сотрудника на проект это создаёт миллион проблем
Помогает в таких ситуациях семантика и общие договорённости
Например, дизайнер при проектировании дизайн-системы именует компоненты так, как они выглядят и используются, а разработчик адаптирует их под технические ограничения и соглашения в коде. Если между ними нет договоренности, то в макетах могут быть «Primary Button» и «Secondary Button», а в коде – MainButton и AltButton. В итоге, путаница, ошибки в сборке интерфейса и лишние вопросы
Чтобы этого избежать, важно заранее договориться о правилах именования. Вот несколько рабочих подходов:
/ Унификация названий
Дизайнеры и разработчики должны говорить на одном языке. Например, если дизайнер называет кнопку «Primary», то и в коде она должна быть PrimaryButton, а не MainButton или BtnMain
/ Система именования
Лучше заранее определить, как будут именоваться компоненты: по роли (Primary, Secondary), по функции (Action, Navigation), по контексту (HeaderButton, FooterLink). Это поможет сразу понимать, что к чему относится
/ Единая документация
Все термины и названия должны быть зафиксированы в дизайн-документации и глоссарии. Тогда даже новые сотрудники смогут быстро разобраться, что означает AlertMessage или SnackbarNotification
/ Совместные ревью
Регулярные встречи дизайнеров и разработчиков по вопросам дизайн-системы позволяют избежать разночтений и синхронизировать терминологию
/ Использование токенов
Если закладывать систему токенов (цвета, отступы, тени) с четкими названиями (primary-color, secondary-bg), то разработчики смогут легко применять их в коде без необходимости разбираться в макетах
В итоге, продуманная семантика и согласованные принципы именования помогают избежать хаоса, ускоряют работу и упрощают поддержку проектов. Когда дизайнер и разработчик говорят на одном языке, интерфейсы собираются быстрее, а система остается чистой и понятной
Этот пост родился, когда я просматривал дизайн-систему Контура. Ребята настолько словили общий вайб, что назвали кнопку "Показать ещё" – ЕЩЁКАЛКОЙ 🤪
Важнее всего не то, как называется элемент, а то, насколько все понимают функкцию его работы)))
#дизайнсистемы