Контекст
Аналитический центр Нижнего Новгорода создаёт городские интернет-сервисы. Чтобы ускорить и упростить разработку новых продуктов, команда запустила работу над дизайн-системой и искала опытного дизайнера, чтобы провести её аудит. Они обратились ко мне как к продуктовому дизайнеру «Доки» — проекта, направленного на то, чтобы делать знания и экспертизу доступными для коммьюнити.
Задача
Команда обратилась ко мне на самом старте. После короткого интервью-знакомства я поставила перед собой такие задачи:
- получить базовое понимание процессов в команде;
- изучить имеющиеся наработки дизайнеров;
- оценить архитектуру системы;
- выявить проблемные зоны;
- дать эмпатичные рекомендации на основе проведённого анализа и собственного опыта.
Анализ
Первым этапом я провела интервью команды. Мне нужно было разобраться в стоящих перед ними задачами, имеющихся ограничениях и ресурсах.
Команда из трёх дизайнеров работает над дизайн-системой для инфраструктуры городских порталов, объединяющей три направления: горожане, юридические лица и администрация. Задача — разработать единый стиль интерфейсов, при этом сохранив индивидуальность каждого направления. Технологический стек: дизайнеры работают в Figma, разработка использует VueJS, HTML, CSS.
Несмотря на разные конечные аудитории пользователей, все решения принимаются городской администрацией. Это накладывает стилистические ограничения и усложняет согласование.
По результатам интервью у меня появилась гипотеза: ребята хотят оптимизировать процесс разработки новых порталов, но пока не до конца понимают, как именно дизайн-система поможет им в этом и как её правильно строить.
Второй этап аудита включал проверку этой гипотезы — для этого команда предоставила свои наработки. Руководитель отдела разработки при этом задал вопрос: «Не слишком ли мы нагружаем дизайнеров?»
Процесс
Ответ на заданный выше вопрос: да. Дизайнеры начали работу от частного к общему и углубились в разработку одного компонента — поля ввода <input> — пытаясь предусмотреть все возможные варианты. К моменту, когда компонент попал ко мне на ревью, было отрисовано 360 различных вариантов поля ввода, при этом автоматизация через ассеты в Figma не была полностью настроена. Я отметила это как точку роста, которую важно подсветить комманде: использовать такую громоздкую конструкцию как основу для создания трёх визуально разных направлений будет почти невозможно.
Нужен был редизайн и я вооружилась бритвой, чтобы отсечь всё лишнее. Выявила сугубо технические тонкости, например, неоптимальное использование возможностей Figma. Отметила и проблемы, связанные с недостатком экспертизы в смежных областях и/или коммуникации с разработкой, а именно неполное понимание того, как элементы ведут себя в браузере. В итоге мне удалось пересобрать макет, полностью сохранив изначальный дизайн, и сократив количество сущностей в семь раз: с 360 до 50.
Процесс упрощения и пересборки компонента на слайдах:
Выводы
Я проанализировала все предоставленные мне материалы и подтвердила свою гипотезу.
Команда дизайнеров начала работу, двигаясь от частного к общему — сфокусировалась на том, чтобы сделать как можно больше опций для одного компонента, но не рассматривая его в контексте всей веб-страницы и дизайн-системы в целом.
Кроме того, стало понятно, что для многих в команде это первая работа с дизайн-системой. Вместо того чтобы выстраивать процессы, они копировали подходы крупных корпораций, что усложняло задачу.
Мой опыт подсказывал, что такой подход съедает много времени, создаёт ощущение, что дизайн-система мешает, а не помогает, и рискует привести к выгоранию команды.
Результат
Результатом моего аудита стал технический редизайн предоставленных макетов и рекомендации по выстраиванию флоу.
В рекомендациях я:
- предупредила о рисках выбранного командой подхода к работе;
- предложила системный подход к управлению разработкой дизайн-системы, сформулировала вопросы, на которые нужно ответить, чтобы найти идентичность проекта целиком, потом понять, чем отличаются друг от друга его направления, и только затем уже переходить к разработке молекул и атомов дизайн-системы;
- подсказала аргументы, которые лидер команды дизайнеров сможет использовать, чтобы защитить интересы своей команды перед разработчиками и менеджментом.