Разработка единой дизайн-системы для приложений на всех платформах — опыт Airbnb26.10.2016 17:52

За кулисами новой дизайн-системы

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

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

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

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

Зачем нам нужны дизайн-системы

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

Слишком мало ограничений

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

Множество дизайнеров и заинтересованных лиц

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

Разнообразие платформ

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

Программное обеспечение во времени

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

Приступая к работе

Для работы над этими проблемами и быстрого принятия решений мы собрали небольшую группу дизайнеров и разработчиков. Мы вычистили наши календари, сняли студию неподалеку от главного офиса Airbnb и посвятили себя созданию и разработке Системы дизайн-языка (DLS).

Цель, которую мы поставили, — создание качественного и понятного дизайн-языка. Наши макеты должны быть унифицированы для каждой платформы при помощи определённых компонентов. Для начала мы решили направить максимум усилий на создание нашей системы для нативных платформ (iOS и Android).

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

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

Закладывая основу

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

Создание компонентов

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

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

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

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

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

Сборка библиотеки

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

С ростом библиотеки мы начали создавать рабочие области, содержащие схожие элементы. Затем эти рабочие области были объединены по категориям: навигация, область для выделения объектов, контент, изображения и категории особых элементов.

Мы создали группу таких элементов для смартфонов (iOS и Android) и адаптировали их для планшетов. Компоненты для планшетов, по большому счёту, такие же, как и для мобильных устройств. С технической точки зрения, нужно прописать два разных стиля в коде. С помощью этой системы компоненты могут различаться по внешнему виду и позиционированию, аналогично тому, как работает responsive-дизайн на веб-сайтах. Дизайнеры могут разработать макет один раз, используя общие компоненты, и в дальнейшем легко адаптировать его к различным размерам экрана, так же как и к iOS и Android.

Ниже вы увидите наше решение, созданное для планшетов.

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

Извлеченные уроки

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

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

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

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

Вывод

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

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

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