Как мы проектируем дизайн-системы на аутсорсе

И почему опыт продуктовой среды для нас не актуален.

Большинство проектов KODE разрабатывает как аутсорс-компания: интегрируется с IT-ландшафтом и бизнес-процессами заказчика, а иногда и управляет командой разработки на его стороне. За несколько лет дизайн-отдел выработал свои правила работы на аутсорсе, которые полирует до сих пор. Подробнее о них рассказывает лид команды Мартин Эрлер.

Несколько лет назад наш дизайн-отдел был совсем небольшим: ребята сидели в Скетче, локально хранили файлы и вели проект от старта до финала. Отдел рос вместе с компанией. Скетч больше не покрывал все потребности, и на смену ему пришла Фигма. Проектов становилось всё больше, и все они были масштабнее, чем предыдущие.

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

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

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

У разработки дизайна на аутсорсе есть свои особенности:

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

• Сжатый срок. Всегда оговаривается заранее, но в среднем на дизайн отводится 3–4 месяца.
• Крутой результат с первой попытки. Когда в короткий срок нужно задизайнить 2000 экранов в 50 сценариях, нет времени на ошибки.
• Регулярное погружение в новый контекст. Нормальная практика — переключение дизайнера на другой проект через 6–12 месяцев.

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

Проблема консистентности возникала по нескольким причинам:

• Дизайнеры делали так, как им было удобно. При переключении на новый проект дизайнеру нужно было погружаться в контекст с нуля: изучать артефакты, разбираться в задачах, целях и сценариях, а после — вести работу по уже созданной структуре. Приходилось постоянно адаптироваться, а это занимало много времени. Дизайнеры не перенимали полностью новые или странные для себя методологии на все 100%.

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

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

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

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

Для этого мы проектируем интерфейсы и систему таким образом, чтобы её можно было легко изменять и масштабировать. У нас нет застоялого легаси на проектах — в большинстве кейсов мы гибкие, как ужи. Мы можем консолидировать и адаптировать навыки, современные практики, знания о платформах и использовать их в новых условиях.

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

Атомарный подход предполагает «переиспользуемость»: всё, из чего состоит приложение, должно быть задействовано по максимуму. Это отличный принцип, но можно ещё лучше. Возможность проектировать UI-киты от проекта к проекту позволяет экспериментировать. За несколько лет таких исследований мы нашли оптимальный способ держать всё под контролем и не обрастать сущностями и вложенностями.

Клиент может поменять своё решение. Сегодня он хочет синюю светлую тему, а под конец проекта — тёмную красную. Можно ему отказать или включить доработку отдельным пунктом после релиза. Но это снова займёт время: переработка библиотеки, макетов, нейминга, новые стили и тонны часов разработки. Поэтому мы закладываем такие кейсы каждый раз, когда есть хоть малейшее подозрение о том, что такое может произойти. Возможно, тёмная тема никогда и не потребуется, но мы больше не наступаем на свои же грабли и проектируем под масштабирование.

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

Сначала мы создаём базис библиотеки и только потом начинаем проектировать чистовые макеты. Затем наполняем её по мере отрисовки, но только теми элементами, которые переиспользуют ранние компоненты и будут работать не один раз.

При проектировании мы также закладываем дополнительные «рудименты» — компоненты, необходимые для какого-то конкретного кейса. Они могут переиспользоваться на следующих этапах, когда будут появляться соответствующие фичи. При этом наибольшая часть интерфейса строится на условных 3–4 компонентах, которые кастомизируются под нужные задачи — так называемые «тупые компоненты».

Концепция организации проекта подразумевает разбивку на более мелкие составляющие по древовидной структуре:

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

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

Есть ли смысл в одной большой дефолтной библиотеке?

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

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

С типографикой тоже всё не так просто: через неё можно транслировать стиль бренда и эмоции. Например, мы не всегда используем фирменные San Francisco и Roboto, потому что какие-то шрифты хорошо работают с одним интерлиньяжем, а некоторые — с другим. А у кого-то и гайдлайн есть. Остаётся набор кнопок и контролов, но они тоже могут быть уникальные, а проектировать одно и то же – путь к конвейеру.

Есть ли смысл в едином сторибуке?

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

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

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

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

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

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

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