Дизайн-системы основаны на отношениях

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

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

Однако дизайн-системы никуда не делись. Согласно одному опросу, в 2018 году всего 15% организаций не имели системы дизайна. Это меньше, чем 28% годом ранее. Некоторые команды используют большие системы проектирования общего назначения, такие как Google Material Design, в то время как другие используют более мелкие, более специализированные системы, такие как Cedar REI и Mozilla Protocol.

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

Большая картинка

В статье 1960 года под названием «Социо-технические системы» исследовалось взаимодействие между технологиями, людьми и более широкой средой, в которой они существуют. Энид Мамфорд объяснила, что исследователи начали с изучения того, как улучшить отношения между менеджерами и сотрудниками, но к 1980-м годам они сосредоточились на том, чтобы сделать работу более эффективной и рентабельной. В 2011 году Гордон Бакстер и Ян Соммервилл написали, что это исследование помогло вдохновить дизайн, ориентированный на пользователя, и что предстоит еще много работы.

Бакстер и Соммервиль утверждали, что сегодня все еще существует противоречие между «гуманитарными» исследованиями, которые сосредоточены на качестве жизни сотрудников, и «управленческими» исследованиями, которые сосредоточены на их производительности. Они также объяснили, что важно учитывать как технологии, так и взаимодействие людей: «производительность системы зависит от совместной оптимизации технических и социальных подсистем».

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

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

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

Ответ на эти вопросы, конечно же, «это зависит!» Кто будет проектировать, строить и использовать систему? Каковы их потребности? В каких условиях они работают? Какие инструменты и технологии им удобны? Чему они хотят научиться?

Чтобы ответить на такого рода вопросы, Бакстер и Соммервиль рекомендуют два типа деятельности:

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

копаться

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

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

Эти взаимодействия помогли командам создавать более качественные продукты, но, что не менее важно, они установили доверие между командами. Команда blue узнала, что люди используют систему продуманно и строят на ее основе новые умные идеи. Зеленая команда узнала, что система действительно адаптирована к их потребностям, поэтому они могут работать с ней, а не против нее. Бакстер и Соммервиль могли бы назвать эту работу «конструктивной вовлеченностью».

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

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

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

• Google Material Design имеет несколько реализаций на разных платформах и языках. Его используют самые разные люди внутри и вне Google, поэтому он содержит исчерпывающую документацию и множество наборов инструментов для разработки приложений.
• Fluent Design System от Microsoft нацелена на четыре совершенно разные платформы. Как и Material, он включает наборы инструментов для дизайнеров UX и исчерпывающую документацию.
• Протокол Mozilla реализован на Sass и ванильном JavaScript. Особое внимание уделяется интернационализации. Алекс Гибсон говорит, что эта система помогает Mozilla «создавать фирменные веб-страницы в более быстром темпе с меньшим количеством повторяющейся ручной работы».
• Cedar REI построен с использованием компонентов Vue.js и не может использоваться с другими средами JavaScript. Cedar в основном используется внутренними разработчиками REI и тесно связан с брендом компании. Код дизайн-системы имеет открытый исходный код, но шрифты — нет.
• Система Lightning Design от Salesforce — это CSS-фреймворк, не зависящий от JavaScript. При желании его можно использовать вместе с Lightning Component Framework, который включает две реализации JavaScript: одну с использованием веб-компонентов, а другую с использованием собственной платформы Salesforce Aura.
• PatternFly от Red Hat был создан для обеспечения согласованного взаимодействия с пользователем во всех продуктах облачной платформы компании, поэтому он имеет относительно высокую плотность информации и включает в себя множество компонентов визуализации данных. Команда PatternFly недавно перешла с Angular на React после некоторых экспериментов с веб-компонентами. PatternFly также включает реализацию, не зависящую от JavaScript, с использованием HTML и CSS. (Полное раскрытие: я бывший Red Hatter.)
• IBM Carbon Design System предлагает реализации в React, Vue, Angular и vanilla JavaScript, а также набор инструментов для проектирования для Sketch. Команда Carbon экспериментирует с веб-компонентами. (Спасибо Джонатану Спику за то, что он отследил этот репозиторий.)

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

Джош Матео и Брендон Мэнваринг объясняют, что дизайнеры Spotify «видят свою роль в качестве основных участников и соавторов общей системы, которой они владеют». Мина Маркхэм описывает себя как «переводчика между проектированием и дизайном» в системе дизайна Pantsuit. Джина Энн подробно рассказывает о командной динамике и исследованиях пользователей, стоящих за дизайн-системами: «Осторожно, спойлер! Вам понадобится больше, чем просто дизайнеры».

Давайте построим некоторые вещи!

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

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

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

Цель здесь состоит в том, чтобы установить быструю обратную связь с людьми, которые используют дизайн-систему. Более быстрая обратная связь и меньшие итерации могут помочь избежать слишком далекого захода в неправильном направлении и необходимости резко менять курс. PJ Onori называет эти внезапные большие изменения «трэшем». Он говорит, что немного трэша — это хорошо — это признак того, что вы учитесь и реагируете на изменения, — но слишком много может быть разрушительным. «Вы не должны бояться трэша, — говорит он, — но вам нужно знать, когда он полезен и как смягчить его недостатки. Один из лучших [способов] смягчить недостатки трэша — начать с малого — со всего ».

Попробуйте начать с малого, настроив несколько основных элементов:

• Система контроля версий для хранения вашего кода. GitHub, GitLab и Bitbucket — отличные варианты. Убедитесь, что каждый, кто использует систему, может получить доступ к коду и предложить изменения. Если возможно, рассмотрите возможность сделать код открытым, чтобы охватить как можно более широкую аудиторию.
• Код CSS для реализации системы. Используйте переменные Sass или пользовательские свойства CSS для хранения «маркеров дизайна» — общих значений, таких как ширина и цвет.
• Файл package.json, который определяет, как приложения могут создавать и устанавливать дизайн-систему.
• Документация в формате HTML, демонстрирующая, как использовать систему дизайна, в идеале с использованием собственного CSS системы.

Документация node-sass для CSS-фреймворка Bulma описывает эти шаги более подробно. Вы можете пропустить установку и импорт Bulma, если хотите начать с нуля, или вы можете включить его, если хотите начать с некоторых основ.

Вы могли заметить, что я ничего не упомянул здесь о JavaScript. Возможно, в конечном итоге вы захотите добавить этот элемент, но для начала он вам не нужен. Легко зайти в кроличью нору, изучая лучшие и новейшие инструменты JavaScript, и если вы заблудитесь в этом исследовании, вам будет сложнее начать работу. Например, «5 причин, по которым веб-компоненты идеально подходят для систем проектирования» и «Почему я не использую веб-компоненты» содержат веские доводы, но только вы можете решить, какие инструменты подходят для вашей системы. Начав только с CSS и HTML, вы сможете собрать отзывы из реальной жизни, которые помогут вам принять это решение, когда придет время.

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

Наконец, рассмотрите возможность публикации вашей дизайн-системы в виде пакета на npm, чтобы разработчики могли ее использовать, выполнив команду npm install your-design-system . По умолчанию пакеты npm являются общедоступными, но вы также можете опубликовать частный пакет, опубликовать пакет в частном реестре или попросить разработчиков установить пакет непосредственно из системы контроля версий. Использование репозитория пакетов упростит поиск и установку обновлений, но установка непосредственно из системы контроля версий может быть простым краткосрочным решением, которое поможет командам начать работу.

Если вам интересно узнать больше о инженерной стороне вещей, книга Кэти Силор-Миллер «Создание вашей системы проектирования» предлагает фантастическое глубокое погружение. (Полное раскрытие: я работал с Кэти.)

Подведение итогов

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

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

Дальнейшее чтение на SmashingMag:

• Советы по управлению дизайн-системами
• Включение анимации в вашу дизайн-систему
• Помимо инструментов: как создание дизайн-системы может улучшить вашу работу
• Создание крупномасштабной системы проектирования для правительства США (пример из практики)