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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник