![](https://habrastorage.org/getpro/habr/upload_files/d9b/0a1/cf5/d9b0a1cf552be530d7c358937f358d69.png)
Меня зовут Илона, я Lead Experience Designer в EPAM. Работа для меня удачно совпадает с хобби — в EPAM я проектирую интерфейсы для зарубежных заказчиков, читаю лекции для сотрудников и студентов лабы, менторю дизайнеров. В свободное время преподаю проектирование интерфейсов в магистратуре Университета ИТМО и веду Телеграм-канал о UX-дизайне.
В работе и преподавании я часто сталкиваюсь с проблемой: сложно организовать компоненты интерфейса так, чтобы было всегда понятно, какой компонент использовать, чтобы похожие компоненты не плодились и не путали дизайнеров и разработчиков.
Делюсь подходом, который помогает мне удобно организовать компоненты и упростить жизнь себе и разработчикам.
Что вообще такое компоненты
Графический интерфейс (GUI), как правило, состоит из кнопок, полей, чекбоксов, текстовых блоков и пр. Именно это мы называем «компоненты» — эдакая интерактивная (или нет) «обёртка» контента: кнопка «Оформить заказ»; чекбокс «Я принимаю условия соглашения» и т.д.
Для UX-дизайнера интерфейс в первую очередь — инструмент решения пользовательских задач. Задача всегда существует в контексте: регистрация в контексте сайта авиакомпании, покупка в контексте интернет-магазина одежды. Поэтому дизайнеру очень важно использовать реальные заголовки, названия кнопок, пункты списков. Именно так мы иллюстрируем решение определённой задачи в определённом контексте.
Но привязанность к контексту таит в себе потенциальную опасность, особенно для крупных и долгоиграющих проектов: контекстуализированные компоненты может быть сложно переиспользовать.
Посмотрим на простом примере
Дизайним карточку товара в интернет-магазине: картинка, информация, цена и кнопка «Купить».
![](https://habrastorage.org/getpro/habr/upload_files/8e5/710/2d3/8e57102d365baf80dd2ff7bd2e07de61.png)
А ещё требуется карточка товара для корзины. Там нет кнопки «Купить», зато есть кнопка «Удалить» и селектор количества товара. Звучит как новый компонент. Делаем!
![](https://habrastorage.org/getpro/habr/upload_files/d0f/f2f/bb1/d0ff2fbb1ed36010f1d789543fd63a12.png)
Спустя какое-то время дизайним новую фичу — личный кабинет. Карточка требуется уже не для товара, а для пользователя. Совсем другой компонент. Делаем!
![](https://habrastorage.org/getpro/habr/upload_files/2a8/808/d0d/2a8808d0de445a473425a4807e317cd8.png)
И вот у нас уже 3 компонента «Карточка».
![Карточки во всем своем многообразии Карточки во всем своем многообразии](https://habrastorage.org/getpro/habr/upload_files/ef4/7bd/010/ef47bd01022bf66b8c341e5256f66403.png)
Теперь мы хотим показать информацию о заказе в личном кабинете. Неплохо смотрелась бы… Карточка!
Какую же из трёх использовать? Ни одна толком не подходит. Проще уже сделать новую.
Проходит время, карточки разработаны и живут в разных местах системы.
Однажды мы решаем разом модернизировать все карточки — сделать изображения круглыми. Модно!
Изменения во всех карточках становятся испытанием для дизайнера и болью для разработчиков, потому что карточек много и они разные.
![Три группы правок в нескольких местах на макетах и в системе Три группы правок в нескольких местах на макетах и в системе](https://habrastorage.org/getpro/habr/upload_files/361/093/ed0/361093ed068227d42716c5b3cc95ad54.png)
Изменений бы потребовалось в три раза меньше, если бы карточку переиспользовали.
Зачем и как переиспользовать компоненты
Переиспользование компонентов помогает:
облегчить жизнь себе и разработчикам;
пользователям предсказывать поведение интерфейса (увидел компонент — понял как работает — знаю чего ожидать)
Во имя переиспользования, по примеру разработчиков React.js, делим компоненты на два типа: «тупые» и «умные».
![](https://habrastorage.org/getpro/habr/upload_files/1b9/2be/113/1b92be1132ca90186d730f18cd7cabf4.png)
«Тупой» компонент не привязан к бизнес-логике. Вместо контента в нём — рыба, максимальное количество состояний и элементов. Универсальный кирпичик для конструктора интерфейса.
Если же «тупой» компонент размещается в контексте, на определённой странице, оснащается конкретным контентом и функциональностью — он становится «умным».
«Умный» компонент привязан к бизнес-логике. Он исполняет определённую функцию в конкретном месте. Умный компонент является реализацией «тупого».
Можно сказать, что тупой компонент — шаблон, а умный компонент — пример его применения.
![Шаблон карточки и примеры его применения Шаблон карточки и примеры его применения](https://habrastorage.org/getpro/habr/upload_files/07d/8bf/c23/07d8bfc23391ce6cffe396294be58edd.png)
Пример с карточками сделан в Figma. «Тупая» карточка — Figma-component с применением Auto Layout. Благодаря этому элементы карточки можно удалять и менять, а её размер подстроится под изменения. Умная карточка — Figma-instance.
![](https://habrastorage.org/getpro/habr/upload_files/9be/ad4/889/9bead4889c993c8749e934f91d8db175.png)
Достаточно внести изменения в «тупом» компоненте, и они автоматически окажутся в «умных». Также происходит и в разработке, если код компонента переиспользуется.
![Скругление всех картинок одним движением Скругление всех картинок одним движением](https://habrastorage.org/getpro/habr/upload_files/acc/9fe/2be/acc9fe2be0b5c09acb3eb18530c23451.png)
Тупой UI kit
Простая и понятная библиотека компонентов (UI kit), элементы которой легко переиспользовать и обновлять — турбо-ускоритель дизайна и разработки. И состоит такая библиотека из тупых компонентов. Я называю её «Тупой UI kit».
Если на вашем проекте уже есть UI kit, попробуйте сделать все компоненты в нём тупыми. Скорее всего, вы с удивлением обнаружите, что многие компоненты можно унифицировать: объединить похожие или удалить повторяющиеся. «Отупить» UI kit может быть непросто, понадобится время на ревизию системы и сильный дизайн-инструмент. Figma отлично справляется, но и Sketch не отстает.
«Тупой UI kit» облегчит работу над дизайном, избавив от необходимости плодить компоненты и изобретать велосипед. Разработчики тоже скажут вам спасибо за то, что они могут переиспользовать код компонента.
«Тупой UI kit» также может стать основой для создания Storybook проекта.
Выводы
![](https://habrastorage.org/getpro/habr/upload_files/233/a7e/35b/233a7e35bd71e1920ccc4946fd3fc222.png)
Разделяя компоненты на «умные» и не очень, вы:
создаете унифицированный интерфейс;
оптимизируете дизайн и разработку, не выдумывая новые компоненты без необходимости;
оставляете возможность легко вносить изменения в дизайн и код;
делаете поведение компонентов предсказуемым для пользователей.
Больше о проектировании интерфейсов и UX можно почитать в моём телеграм-канале «Поясни за UX».
![](https://habrastorage.org/getpro/habr/upload_files/812/42b/2ee/81242b2ee1c4d58e0b718d69b7d7dd8f.png)