Привет, я Андрей Сахаров, дизайнер и преподаватель UI/UX дизайна. Работа с компонентами — важная составляющая культуры дизайна. Часто бывает, что новички в профессии имеют абстрактное, неоформленное представление о том, как создается дизайн. Понимание технологии и того, как все устроено, собственный осознанный подход к работе и практические наработки приходят со временем. На мой взгляд, причина кроется в том, что многие начинают с теории, а не с практики. Поэтому в этой статье я хотел бы на конкретных примерах рассказать о собственном методе работы с компонентами.
Работа компонентов
Выше я написал, что речь пойдет о работе с компонентами, но, признаюсь, я слукавил. О том, что такое кнопка, как она работает, как ее описать и т.д. написано немало и до меня. Я бы хотел рассказать, как мы работаем с более сложными элементами. Давайте разберем, в чем именно состоит это подход, на примере сниппета.
Что такое сниппет. Википедия говорит нам, что сниппет — это фрагмент исходного текста или кода программы, который будет использован в поисковых системах, текстовых редакторах и средах разработки. Например, частный случай сниппета — карточка товара в поиске на маркетплейсе.
Как я уже отметил, я предпочитаю начинать с практики и поэтому сразу же покажу вам готовый сниппет, для наглядности, а еще попрошу назвать все дизайн-компоненты, которые вы здесь видите:
![](https://habrastorage.org/getpro/habr/upload_files/4f0/681/83a/4f068183ad017c6422d174a10862374e.png)
Скорее всего, вы назовете:
Фото
Кнопки
Бейджик
Да, это базовые компоненты, но не будем забывать, что и сам сниппет может быть компонентом дизайна, с которым предстоит работать дизайнерам и разработчикам, а именно изменять, наполнять содержимым, добавлять новый функционал для пользователя. Для того, чтобытаким элементом было удобно управлять, необходимо выделить в его структуре не столько компоненты, сколько смысловые группы, которые в дальнейшем помогут масштабировать сниппет новым функционалом. Или порезать его на неочевидные на первый взгляд виджеты.
Попробуем представить сниппет в виде некоей абстрактной модели, выделив в нем смысловые группы-модули. В нашем случае, поскольку мы имеем дело с шаблоном объявления, выглядеть это будет примерно так:
![](https://habrastorage.org/getpro/habr/upload_files/f55/373/285/f553732850cc13f0223ec1ffcf73b48f.png)
У нас получилось выделить три основных модуля. Посмотрим, из каких элементов они состоят:
Модуль “Что сделать?”
Этот модуль рассказывает над чем предстоит работать:
Задача
Название
Настройки
Модуль “Что это?”
Данный модуль содержит основную информацию о товаре, например:
Фото
Бейджик на фото
Три блока информации
Модуль “Уточнение и действие”
Здесь находятся такие элементы, как:
Два блока уточняющей информации
Набор действий пользователя реализованный в виде кнопок
Такой подход действует по принципу “палуб”, он позволяет наращивать новые и новые блоки или интегрировать какие-то новые компоненты в уже существующие. В итоге компонентов становится больше, а управление сниппетом становится более гибким.
Зачем это нужно?
Читатель может задать вполне резонный вопрос, в чем польза такого подхода и зачем его применять. Безусловно, выбор подхода работы с компонентами очень сильно зависит и от самого продукта, и от принципов, которыми руководствуетесь вы и ваша команда. Итак, что же это за принципы в моем случае? Позволю себе здесь немного теории.
Создание единого языка для команды, который даст возможность быстро и легко создавать новые продукты, не забывая прошлый опыт. Кроме того, такой подход упрощает процесс тестирования и внесения изменений в продукт.
Обеспечение единой стилистики в рамках продукта. Работа с компонентами позволяет создавать единый язык дизайна и улучшать восприятие продукта пользователем.
Обеспечение гибкости и масштабируемости процесса. Используя этот метод, мы можем легко добавлять новый функционал и управлять компонентами с точки зрения продукта. Кроме того, этот подход позволяет управлять вниманием пользователя и принимать решения об интеграции нового функционала.
Применяем подход на практике
Разберемся, в чем практическая польза создания таких гибких компонентов, как они работают и как с их помощью можно упростить работу над дизайном.
Процесс создания дизайна в нашей команде можно разбить на 4 этапа:
“Идея — Модель — Компонент — Результат”
Детальнее про весь процесс я расскажу в следующих статьях, а сейчас поговорим о том, какие преимущества подход даёт на протяжении всего цикла.
Презентация дизайн-проекта
Такой подход позволяет раскрыть суть проекта уже на начальных этапах, объяснить, какие именно элементы будут включены в дизайн и почемуКоммуникация внутри команды
Такой подход дает возможность ввести в контекст любого члена команды и задает фреймворк работы с элементами дизайна, что позволяет легко обучать новых дизайнеров.Создание информационной архитектуры
Наличие смысловых блоков позволяет легко принимать решения о том, как организовать компоненты и куда и как интегрировать новый функционал.
Например, используя подобный подход можно легко сформировать условный “минимальный” сниппет:
![](https://habrastorage.org/getpro/habr/upload_files/698/eca/9c7/698eca9c770f136f5c76883085f44c70.png)
Выводы
В качестве заключения, перечислю еще раз преимущества гибких компонентов: возможность легко презентовать проект, интегрировать новый функционал и ввести в контекст любого члена команды.
Безусловно, этот подход к формированию компонентов является одним из множества, которые можно использовать в дизайн-процессе. Решение, какой подход выбрать, очень сильно зависит от целей, которые вы ставите перед дизайн-командой. Как руководитель, я в первую очередь ставлю перед своей командой цель обеспечить гибкость и масштабируемость процесса.
В следующих статьях я подробно опишу, как устроен весь процесс работы над дизайном в нашей команде, от идеи до воплощения. Stay tuned!
vladislav12345
Благодарю за заметку, нашел её крайне полезной. Есть мысль, что подход перекликается с «Синтаксисом элементов интерфейса» Ильи Бирмана, поэтому оставлю ссылку здесь всем интересующимся.
Будет интересно услышать, ответы на следующие вопросы:
1. Как автор и команда включают этот подход непосредственно в работу с дизайн-системой? Где и как они документируют каждый из подобных «сниппетов»? Как они тестируют такие компоненты? Как проводят работу над ошибками?
2. Процесс разработки «Идея — Модель — Компонент — Результат» выглядит понятным, разве что не хватает тестирования или проверки гипотезы. Однако об этом, возможно, автор расскажет в следующей части. Сильно интереснее, что предшествует или, если сказать точнее, что является толчком к созданию компонента? Как автор и команда понимают, что вот, настало время создать компонент и включить его в дизайн систему? Давайте опустим простые случаи вроде чекбокс + иконка, а возьмём сложные, как сниппет в примере выше?
caxapoffs Автор
Привет! Постараюсь ответить на вопросы:
1. Попробую объяснить на примере. Чаще всего, компоненты у нас создаются продуктовыми командами совместно с командой дизайн-системы. Продуктовая команда, если не может использовать готовый компонент или ей нужно улучшить его, сама создает вариативный "мастер" который включает в себя различные кейсы, которые могут быть, при этом сами они, используют только то, что необходимо именно им. Затем они контрибьютят этот компонент в дизайн-систему. Любая другая команда может его переиспользовать или улучшить. Тестирование проводится командой-родителем компонента. Без тестирования компонент не идет дальше по воронке.
2. Основным критерием является распростронненость того или иного компонента на сервисе. Например сниппет — это сквозной элемент, он может быть на разных страницах и разным набором данных. Если есть элемент, который не сквозной, но потенциально, можно просто сделать "оболочку" наполненую базовыми компонентами(типа кнопок, радиобатонов и тд.). Что касается тестирования в процесее, то оно может происходить на любой стадии. Я не писал об этом, но тестирование и проверка гипотез лейтмотив каждого из этапов. Постараюсь расскрыть эту в след. статье, спасибо что натолкнул на это!