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


01.02.2021 Время чтения - 6 минут 656

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

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

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

Решением, предложенным Сандером, стало непрерывное выполнение. Это не новая концепция, и в последнее время ей уделяется все больше внимания. Особенно в DevOps, где в настоящее время циклы запуска в основном автоматизированы. При непрерывном выполнении функции разделяются на более мелкие части, которые можно релизить, когда они будут готовы.

Разделение крупных задач на более мелкие при разработке дизайн-системы

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

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

Улучшение процесса создания дизайн-системы

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

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

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

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

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

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

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

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

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

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

Процесс визуализации

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

Второй этап процесса – это релиз. Во время разработки нам нужно выбрать устанавливаемый пакет Composer для каждого компонента. Затем элементы выпускаются в этих пакетах senior developer’ом.

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

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

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

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

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

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

Динамично развивающийся процесс

Перейти к непрерывному и гибкому рабочему процессу не так уж и легко. Особенно, когда твои коллеги привыкли работать в темпе Waterfall. Для клиентских проектов мы используем scrum и kanban в качестве инструментов оценки задач и регистрации проблем, но дизайн и разработка часто теряют друг друга при каскадной модели.

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

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

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

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

Последний пример развития рабочих процессов – смена инструментов. Я начал использовать Storybook для создания и тестирования нескольких вариантов компонентов по отдельности. Позже я обнаружил, что Storybook не подходит для кодового стека и рабочего процесса. Но мне все еще нужно было место, где я мог бы создавать и тестировать различные варианты нашего компонента.

Вот почему я создал Storybase. Это пакет для приложений Laravel, совместимый с любым html-компонентом, включая встроенные шаблоны Vue. Storybase отображает наши компоненты на сервере, чтобы мы могли оптимизировать их для SEO во время тестирования. Это также позволяет нам имитировать данные в Laravel для каждой истории. И, наконец, каждую из них можно добавить в нашу документацию.

Когда я создавал Storybase, наш компонент навигации по сайту был уже на финальной стадии разработки. Но мы начали клиентский проект с некоторых Snowflake-компонентов, которые внесли множество вариаций. Я установил Storybase в проект, задокументировал и протестировал каждый компонент. Это очень помогло убедить моих коллег-разработчиков в ценности таких инструментов. Теперь я планирую использовать Storybase не только для разработки нашей дизайн-системы, но и для каждого клиентского проекта.

Подведем итоги

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

Оригинал.

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

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

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