19 сентября 2017

Комплексная дизайн-система

UI-методологии вроде Atomic Design привносят логику и структуру в отдельные экраны. Пришло время распространить аналогичный подход на все аспекты вашего продукта.

UI-методологии вроде Atomic Design привносят логику и структуру в отдельные экраны. Пришло время распространить аналогичный подход на все аспекты вашего продукта.

Вот небольшая загадка. Почему — почти как похмелье и попса  — продукты с годами становятся все хуже?
Вы подумаете — должно быть наоборот: крутая команда потратила годы на многочисленные итерации, что в конечном счете должно привести к некоему безупречно совершенному продукту. А вместо этого десять лет спустя вы вдруг не можете разблокировать телефон. Какого черта?
Длинный, да и болезненный ответ – плохая дисциплина. Продукты развиваются долго. Присоединяется больше новых людей, некоторые старички-инициаторы уходят,  и — ясность дизайнерского видения ухудшается. Бизнес решает, что нужно захватывать новые рынки, и новые функции и фичи прикрепляют одну за другой, как рождественские украшения. Внутреннее взаимодействие команды усложняется, а подгруппы разрабатывают свои собственные концепции дизайна и философию. Команду атакуют бесконечные запросы от неоднородной аудитории. Конкурентов же нужно держать в страхе, добавляя еще больше всяких штучек. Сущности множатся. Вскоре чувствуешь, что небезопасно заходить на некоторые экраны после наступления темноты в одиночку. Хорошие продукты ухудшаются.  И это случается с лучшими из нас.
Ответ покороче — большинство продуктовых команд не придерживается четкой дизайн-системы, которая объединяет и направляет все аспекты пользовательского опыта, начиная с концептуальных строительных блоков продукта и заканчивая мельчайшими деталями пользовательского интерфейса и тем, как называются элементы.
Поэтому, если вы страдаете от достойной проблемы – желания создать успешный, развивающийся продукт, здесь описано, как восприятие всех аспектов вашего дизайна в качестве единой системы, может спасти вас от тенденции постепенного ухудшения.

150500 слов, чтобы объяснить

Учитывая, что это интернет, и вы, возможно, хотите посмотреть смешные ролики с животными, я буду краток:

  1. 50 лет назад графические дизайнеры пришли к мысли, что разрабатывая некоторую совокупность взаимосвязанных вещей,  неплохо бы  иметь базовые основополагающие правила.
  2. Дизайнеры цифровых продуктов осознали, что это также хороший способ, чтобы убедиться, что все ваши кнопки всегда выглядят одинаково. Дизайн-системы возникли как способ создания согласованных пользовательских интерфейсов.
  3. Но большинство дизайн-систем — это всего лишь библиотеки шаблонов: большая коробка Lego с элементами пользовательского интерфейса, которые могут быть собраны почти бесчисленными способами. Все части системы могут быть согласованными, но это вовсе не означает, что результат сборки тоже.
  4. Ваш продукт  больше, чем просто куча многократно используемых элементов пользовательского интерфейса. Он имеет структуру и значение. Это не просто общая веб-страница, но воплощение системы понятий.
  5. Опираясь на концепцию продукта, описанную в системе, дизайнеры могут выйти за рамки просто создания единообразных интерфейсных решений в пользу создания согласованных продуктов.

Это в двух словах. Если вы уже все поняли, вы бог скорости.

ПО со структурной целостностью

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

Манхэттенский мост в процессе строительства, 1909. © Ирвинг Андерхилл / Библиотека Конгресса

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

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

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

Добро пожаловать в мир дизайн-систем.

Краткая история дизайн-систем

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

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

Руководство по графическим стандартам для транзитных дорог Нью-Йорка. Массимо Виньелли и Боба Ноорда, 1970 год

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

Руководство по стандартам графических редакторов NASA, Ричард Данн и Брюс Блэкберн, 1975 г.

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

Twitter Bootstrap, первоначально созданный Марком Отто и Джейкобом Торнтоном, 2011

Влиятельная методология Atomic Design Брэда Фроста предложила более структурный подход. Вместо того, чтобы смешивать атомартные элементы, разбросанные по экрану (например, метку, ввод, кнопку), Atomic Design предполагает, что небольшую коллекцию элементов пользовательского интерфейса следует рассматривать как единый компонент (например, нижний колонтитул страницы, форму для входа). Запомните эту идею, мы вернемся к ней немного позже.

Методика Atomic Design Брэда Фроста, 2013 г.

Наконец, принципы Material Design от Google продвинули концепцию еще дальше, привнеся глубокую формальную рациональность, смелую эстетику, а также ресурсы и рекомендации по созданию элементов пользовательского интерфейса на разных платформах. (Я работал в Google и написал гайдлайн для платформы Android Wear.)

Google Material Design, 2014

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

Ограничения библиотеки паттернов

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

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

Конечно. И да, разница есть.

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

Старая, ныне отставная библиотека шаблонов Intercom. Нужны кнопки? Мы получили их.

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

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

Впечатляющий, хоть и не слишком согласованный дизайн — и это только цветочки.

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

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

От Atomic Design к комплексным дизайн-системам

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

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

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

Вот что такая система может включать:

  • Общая концептуальная модель вашего продукта. Это та самая диаграмма, которую вы бы нарисовали на доске, чтобы объяснить, как ваш продукт работает на системном уровне. Каковы основные компоненты вашего продукта? Как они взаимодействуют?
  • Общий язык, который все в вашей команде используют для названия компонентов продукта. Помните, слова важны. Если дизайнеры, инженеры и люди из службы поддержки используют одни и те же слова, то организационная туманность рассеивается.
  • Общие ресурсы для проектирования и дизайна позволяют быстро создавать макеты, которые точно отражают нашу дизайн-систему. Зачастую это один файл в Sketch, к которому у всех есть доступ. Файл содержит Символ каждого объекта и часто несколько вариантов отображения одного и того же объекта в разных размерах или в разных контекстах.
  • Общие компоненты кода, которые позволяют инженерам создавать все элементы и их вариации часто лишь одной строкой кода. Соответствие объектов  в Sketch и в нашей кодовой базе должно быть 1: 1.

И самое главное — сшивающая нить проходит через все эти уровни. «Разговор» в Интерком — один из наших основных объектов — всегда это одна и та же, очень конкретная вещь, будь то набросок, описание, дизайн или код. Если мы хотим каким-то образом изменить этот объект, то должны последовательно изменять его на всех уровнях. Вся команда возьмется за это сообща, и любая двусмысленность исчезнет. Таким образом, мощь системы много больше, чем отдельных частей.

Вот примеры возможных объектов в известных вам продуктах:

  • Facebook: друг, пост в ленте, сообщение, событие, страница, группа.
  • Airbnb: список, хозяин, гость, поездка, опыт.
  • Slack: команда, участник, канал, сообщение, реакция, поток.
  • Intercom: клиент, коллега, сообщение, беседа, статья.

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

Пример из реальной жизни

Чтобы проиллюстрировать мысль,  давайте посмотрим, как мы используем объект “Диалог”  в создании Intercom.

Во-первых, у нас есть обзор объекта “Диалог” в Build’е, внутреннем веб-сайте, который объясняет, чем является каждый объект и как он взаимодействует в контексте системы:

Каждый объект, представленный в Build, имеет модную ссылку, которая открывает его непосредственно в общем файле Sketch наших дизайнеров:

И еще одну, которая открывает фрагмент кода, используемый разработчиками для реализации объекта:

А вот как мы описываем «Разговор» в нашем общедоступном «Глоссарии»:

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

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

Почему это работает для Intercom

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

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

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

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

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

Система работает

Так как предотвратить усложнение вашего продукта с течением времени? Подумайте о том, что вы проектируете, не как о серии экранов, а как о системе объектов, а затем реализуете эти объекты на всех уровнях: концепция, дизайн, реализация, маркетинг, поддержка.
Я буду честен: я не уверен, будет ли это работать на 100%. Я пробовал, и честно говоря, я не могу представить продукт, обладающий функциональной гибкостью и мощностью, но при этом до элегантности простой. Ваши предложения приветствуются! Возможно, так не получится, и «Яма Сложности» ждет нас всех. Но эта не та мысль, которой следует заканчивать пост в блоге.

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

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

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

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

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

Кристофер Александр, автор книги по проектированию систем, писал:

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

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

Дальше — большe

Идеи, которые нас вдохновляют, видео-интервью и переводы исследований, которые были нам полезны в процессе работы.

14 сентября 2016

Дуплекс в веб-дизайне: обзор цветового тренда, который захватывает мир

10 октября 2016

«Мемфис» в веб-дизайне: как «яркий» тренд из 80-х возвращается в 2016 году

11 октября 2017

Доступность — золотое дно для бизнеса

28 августа 2017

Смерть от гамбургера

20 сентября 2016

Эволюция сайтов российских компаний: от зари рунета до наших дней

28 марта 2016

Веб-дизайн в прошлом. Знакомьтесь, Zero UI