Почему нельзя делать дизайн-системы проектами: ч.1


26.01.2021 Время чтения - 5 минут 1765

Первая часть статьи
«Почему нельзя делать дизайн-системы проектами»

Когда новые дизайнеры и разработчики объединяют свои усилия для развития вашей дизайн-системы, возникает соблазн сразу же начать работу над проектами. Вы даже можете создать несколько эпиков и спринтов, чтобы переместить фидбек от юзеров из своего бэклога в Scrum. Однако, такой подход неэффективен, когда ваша дизайн-система не требует постоянного усовершенствования.


Читайте нас в Telegram


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

Создание команды дизайн-системы

Зачем же команда вообще нужна дизайн-системе? Обычно команды в компаниях делятся по определенным направлениям: креатив, разработка и маркетинг. Каждую команду возглавляет тимлид, которому при желании помогает менеджер по планированию.

Существуют еще и проектные команды. Каждая из них состоит из нескольких дизайнеров, разработчиков и маркетологов, а возглавляет ее проджект-менеджер. Составы команд могут меняться со временем.

В итоге дизайнеры, разработчики и маркетологи должны отчитываться перед руководителем своей группы и перед руководителем проектов.

Из-за этой модели командам сложно делиться ресурсами. Мы часто не знаем, над чем работают другие люди, если только не спросим их или не услышим об этом на собрании. Это является причиной того, что одна и та же работа выполняется несколько раз.

Поэтому нам нужны более стандартизированные компоненты, чтобы команды работали эффективно. Кроме того, нам нужно иметь в этих командах больше глаз и ушей, чтобы знать, какие компоненты им нужны больше всего.

В среднем компонентов может потребоваться больше, чем то количество, которое один человек мог бы создавать и шерить самостоятельно. Чтобы создать больше компонентов, запускается проект.

Проект дизайн-системы, который мы рассматриваем в этой статье, наследует конвенцию обычных проектных групп. Для создания компонентов требуется управление проектами, исследования, дизайн и код. Итак, проект начали с менеджера, UI-исследователя, дизайнера и разработчика.

Наш первый проект

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

Он понимал, что высшее руководство не позволит нам работать над большей стандартизацией пока этот проект не увенчается успехом. Получается, что мы не будем работать над другими компонентами до завершения этого проекта.

Ресерч

Ресерч заключается в собирании различных паттернов навигации, вхождений на сайтах конкурентов и на наших. Через неделю результаты были предоставлены команде, чтобы мы могли двигаться дальше.

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

Дизайн

К работе приступает визуал-дизайнер. Два месяца спустя он показал отличный интерактивный прототип в Figma.

Эта разработка немного не соответствовала нашей системе. Дизайнер создал компонент навигации в новом файле с дубликатом шаблонов нашей дизайн-системы. Остальные начали задаваться вопросом, какой файл им следует использовать.

Он дал понять, что может прислушиваться ко мнению других дизайнеров, быстро внедрять фидбек и понимать, как работают системы. Было решено архивировать файлы дизайн-системы и позволить ему поддерживать ее визуальную часть. С помощью этого дизайнеры всегда знали, где можно найти нашу дизайн-систему.

Разработка

Мы хотели начать разработку как можно скорее и быстро добавить компонент навигации в нашу кодовую базу. За это время мы также сменили хранилище ассетов на Webpack и оптимизировали скорость загрузки страниц Google, что также заняло некоторое время.

Два месяца спустя, через четыре месяца работы над проектом, мы до сих пор не могли найти время на разработку навигации. В конце концов, я внес свой вклад, взяв эту задачу на себя.

Компонент в Storybook

Компонент навигации был написан в Storybook. Его можно протестировать, пошерить своей команде и прикрутить автоматизированную документацию.

Storybook оказался проблематичным в нашем рабочем процессе. Люди не понимали всех его элементов управления. И эти же люди не привыкли тестировать компоненты изолированно.

Но что еще более важно, Storybook не поместился в наш стек кода. Мы использовали встроенные шаблоны Vue для оптимизации SEO и совместимости с нашей серверной структурой Laravel с нашей CMS. Storybook не поддерживает встроенные шаблоны Vue с Laravel, а просто запрашивает однофайловые компоненты.

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

Восемь месяцев спустя после запуска проекта наш фронтенд разработчик объединил код с основной веткой нашей кодовой базы, что означало – навигация полностью готова.

Проблемы с проектами дизайн-системам

Когда мы запускали наш первый проект дизайн-системы, мы рассчитывали на то, что его релиз произойдет довольно скоро. Но этого не произошло, потому что проект попросту терял приоритет. В результате чего его релиз неоднократно переносился.

Нас это не шокировало. Клиентские заказы всегда были для нас в приоритете. Чтобы оказать свои услуги надлежащим образом, необходимо действовать быстро. Ставить большие внутренние проекты выше по приоритету, чем клиентские чаще всего не вариант.

Реальной проблемой стало то, что наш проект оказался бутылочным горлышком. Мне не позволили ресерчить новые компоненты. И нашему дизайнеру пришлось ждать результатов этих самых поисков, так как нами использовался процесс, известный как Waterfall. Это происходило просто потому, что команда считала, что нам не разрешают работать над новыми компонентами.

В этом году я посетил выступление Сандера Хугендорна, коуча по Agile, спикера и писателя. Он говорил об Agile, Scrum и о том, как они ломаются в современной среде разработки ПО. По его словам, мы должны ПРЕКРАТИТЬ заниматься проектами. Этот тезис привлек мое внимание даже несмотря на то, что я работаю в агентстве, которое зарабатывает деньги, выполняя эти самые проекты.

А о решении, предложенном Сандером, вы можете прочесть во второй, заключительной части этой статьи.

Оригинал статьи.

Читайте также: Кому и зачем нужна Дизайн-система?

UX/UI Designer on «Почему нельзя делать дизайн-система проектами»

Читайте нас в Telegram