Распространенные ошибки в процессе создания и масштабирования дизайн‑систем

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

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

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

1. Разработка дизайн-системы с нуля, когда в этом нет необходимости

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

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

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

Последствия ошибки:

• Значительные финансовые потери в результате запуска продукта.
• Незапланированные задержки в процессе создания продукта.
• Переход к гибридной модели с использованием UI-кита в процессе разработки продукта. Необходимость переориентировать персонал, задействованный в создании дизайн-системы.

Что можно сделать, чтобы предотвратить это?

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

2. Чрезмерно сложный процесс создания и доработки компонентов

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

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

Что я имею в виду? Давайте проанализируем этапы создания одного компонента в рамках большой и развитой дизайн-системы.

На каждом из этих этапов необходимо провести 1-2 встречи сотрудников разного уровня. Если в какой-то момент возникнут затруднения, возможны дополнительные созвоны или обсуждения. Таким образом, процесс разработки одного компонента может занять несколько недель.

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

Дополнительный тормозящий фактор — чрезмерно сложный процесс учета компонентов и этапов их разработки. Я видел компанию, в которой 3 работающих над системой специалиста должны были отмечать статус в нескольких инструментах сразу. Они создавали базу данных в Excel, таблицу в Notion и отдельное рабочее пространство в Confluence. Такой подход тоже заимствован у более крупных компаний.

Последствия ошибки:

• Крайне медленный процесс разработки новых компонентов.
• Потеря времени в случае создания неподходящего компонента.

Что можно сделать, чтобы предотвратить это?

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

3. Фокус смещается с дизайна продукта на разработку дизайн-системы

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

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

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

После того, как основная часть библиотеки компонентов и паттернов создана, а базовая документация написана, поддержка ее в актуальном состоянии требует не более 10-15% ресурсов.

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

Последствия ошибки:

• Неудачные визуальные решения.
• Пустая трата ресурсов на доработку компонентов.

Что можно сделать, чтобы предотвратить это?

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

4. Неэффективный состав и размер команды

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

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

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

А такой команды хватит для начала работы над дизайн-системой:

Последствия ошибки:

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

Что можно сделать, чтобы предотвратить это?

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

5. Приоритет масштабирования дизайн-системы над ее развитием

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

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

Упомянутый инструмент произвел революцию в дизайне и организации совместной работы, и продолжает быстро развиваться. Появились такие функции, как auto-layout и variants, анонсированы более серьезные обновления. Figma напоминает фронтенд-фреймворки, среди которых React уже давно превзошел по популярности Angular. 

Через 2-3 года все это может утратить свою актуальность. Важно быть в курсе трендов и следить за появлением новых инструментов.

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

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

Последствия ошибки:

• Излишняя трата ресурсов на поддержание дизайн-системы в актуальном состоянии.
• Сложности поиска сотрудников и сохранения их мотивации к работе с устаревшими технологиями.

Что можно сделать, чтобы предотвратить это?

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

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

Заключение

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

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