Создание визуального языка: за кулисами нашей системы проектирования Airbnb

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

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

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

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

Почему нам нужны системы проектирования

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

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

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

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

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

Начало работы

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

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

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

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

Универсальный: Airbnb используется во всем мире широким мировым сообществом. Наши продукты и визуальный язык должны быть приветливы и доступны.

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

Разговорный: наше использование движения вдыхает жизнь в наши продукты и позволяет нам легко общаться с пользователями.

Укладка фундамента

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

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

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

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

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

Единый язык дизайна не должен быть просто набором статических правил и отдельных атомов; это должна быть развивающаяся экосистема.

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

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

Компиляция библиотеки

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

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

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

Для планшета мы создали несколько простых концепций макетов, таких как Focus Views, которые фокусируют контент на странице, модалы и макеты с двумя столбцами и сеткой.

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

Уроки выучены

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

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

Эскиз. Сначала мы попытались создать эти компоненты в виде символов в Sketch, что привело к путанице. Даже сейчас наши файлы Sketch иногда сложно поддерживать. Двигаясь вперед, мы надеемся найти лучшие способы поддержки и создания новых компонентов. [3]

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

Заключение

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

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

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

Я также ответил на несколько вопросов о Designer News AMA.

Обновление: для получения дополнительной информации и последних разработок, касающихся нашей системы проектирования, смотрите мой доклад на конференции Design Systems 2018, Хельсинки, Финляндия.

Примечания:

[1]: Многие отличные проекты связаны с командами, и всегда нужно поблагодарить слишком много людей, но я хотел бы выделить несколько человек, которые сделали этот проект возможным:

Бек Стоун, Адам Микела, Эмбер Картрайт, Алекс Шлейфер, Майкл Баханд, Пол Компфнер, Шон Абрахам, Салих Абдул-Карим, Майкл Суи + многие другие в командах дизайнеров и инженеров. Спасибо Джошу Леонгу, Сола Бью, Кэтрин Уэйт за то, что они прочитали проекты этого.

[2]: Я оставлю один из наших инженеров написать больше о технической стороне DLS.

[3]: В нашем случае мы хотим, чтобы люди могли изменять размеры символов (например, вам нужно добавить больше содержимого в заголовок). Если вам нужно изменить размер или случайно изменить размер чего-либо, Sketch (2.5) автоматически изменит размер каждого экземпляра этого символа. Это на несколько мгновений убило бы ваш эскиз и, возможно, навсегда испортило ваш файл (иногда отмена не работала). В итоге мы поместили компоненты в группы слоев и позволили людям копировать и вставлять их.

Мы также используем git / github для облегчения процесса обновления файла. Мы вручную создаем и добавляем новые компоненты в файл Sketch главной библиотеки, а также отправляем запросы на извлечение с журналом изменений и сгенерированным png-экспортом, который документирует изменения. После этого файл Sketch попадает в общую папку Box, которая связана с шаблонами Sketch, поэтому каждый может сразу получить доступ к новым компонентам.