Осознанные дизайн-системы: что это и как их создавать

Когда речь заходит о преимуществах дизайн-систем, мы чаще всего слышим 3 основных обещаниях:

• эффективность: дизайн-система сократит количество “мусора” в процессе дизайна и разработки и поможет вам работать быстрее
• единообразие: дизайн-система поможет вам стандартизировать ваш цифровой опыт
• масштабирование: дизайн-система поможет вам масштабировать ваши дизайнерские решения на весь продукт

Но вот о чем мы говорим редко: все это не имеет никакой самоценности.

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

Единообразие — только в том случае, если все результаты будут одинаково высокого качества.

А масштабирование — только, если элементы достаточно хороши, чтобы их воспроизводить.

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

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

Ценность дизайн-систем

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

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

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

Но это создает проблему.

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

Дизайн-системы также могут способствовать:

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

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

Риски дизайн-систем

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

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

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

А что если это не так?

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

Пример 1: Выпадающие списки

Давайте начнем с довольно распространенного компонента. Он называется “select” — вы также можете знать его как выпадающий список. Обычно его используют для того, чтобы дать людям возможность выбрать нужную опцию из списка.

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

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

Снова и снова она видела, что пользователи:

• не могут закрыть список
• пытаются ввести текст
• путают элементы в фокусе с выбранными элементами
• пытаются масштабировать опции на планшетах двумя пальцами

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

• радиокнопки
• простого текстового поля
• текстового поля с автозаполнением

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

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

Потому что есть существенная разница между дизайн-системой, которая говорит: "Вот выпадающий список — делай что хочешь", и той, которая:

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

Хорошая дизайн-система помогает своим пользователям сделать осознанный выбор — когда использовать компоненты, а когда нет.

Пример 2: Просим людей оставить свое имя

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

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

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

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

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

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

Дизайн-системы — это не просто безобидные инструменты масштабирования

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

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

Что произойдет, если наши компоненты окажутся недоступными? Что, если наши шаблоны дискриминируют кого-то, или наш контент исключает людей?

В подобных случаях мы создаем вредные системы.

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

Дизайн-системы нельзя винить во всем и они не могут предотвратить весь вред. Но...

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

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

Что мы точно можем сделать, так это признать и снизить риски и начать работать над созданием осознанных дизайн-систем.

Так как же это сделать?

Как создавать осознанные дизайн-системы

1. Общепринятая практика ≠ хорошая практика

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

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

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

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

Я также хочу отметить, что если так делает Google, это еще не значит, что это хорошо.

Показательный пример: текстовые поля, которые были закреплены в Material UI, дизайн-системе Google с открытым исходным кодом, до 2017 года. Компания заменила традиционные поля ввода, в которые пользователи привыкли вводить текст, на линии.

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

В статье моего коллеги Хейдона Пикеринга "Слушайте меня, а не Google" он описывает разочарование, вызванное безуспешной попыткой убедить клиента отказаться от подхода Google и использовать вместо него более традиционное поле ввода.

К сожалению, клиент был уверен, что источник этого подхода “узаконил” его. (Не стоит недооценивать эффект авторитета).

Затем, в 2017 году, Google объявил о редизайне текстовых полей. Решив провести юзабилити-тестирование своего оригинального дизайна, компания обнаружила те проблемы, о которых говорили все остальные.

Они написали: "Доступность линии была неочевидна для некоторых пользователей, при этом некоторые из них путали ее с разделителем".

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

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

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

2. Приоритет инклюзивности на каждом уровне

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

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

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

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

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

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

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

Так почему же это важно? Как те из нас, кто создает дизайн-системы, могут повлиять на людей, которые используют наши продукты и услуги?

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

Ким Крейтон, экономист-антирасист, говорит о двух типах знаний:

• Явные знания, которые легко сформулировать, кодифицировать, сохранить и передать другому человеку.
• Неявные знания, которые трудно передать другому человеку письменно или устно.

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

А если мы никогда не сталкивались с “исключением”, предотвратить его очень трудно, поскольку мы, скорее всего, не заметим эту проблему, пока не станет слишком поздно.

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

3. Эффективные петли обратной связи

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

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

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

4. Худшие / стрессовые сценарии

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

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

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

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

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

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

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

И если вы думаете, что все это звучит так, будто вам предстоит ужасно много работы, вы правы 😀

Создание осознанной дизайн-системы затормозит вашу работу — все равно сделайте это

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

Здесь нет быстрых решений. Все, о чем я говорила в статье, — лишь направление движения.

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

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

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

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

Мы можем принять такое решение, несмотря ни на что.