Претензии к дизайн-паттернам

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

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

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

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

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

Кнопки и ссылки с Co-op

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

За последние годы границы понятия дизайн-паттернов расширились, поскольку бизнес-сообщество и компании стремятся работать более эффективно и последовательно — особенно когда речь идёт о группе или семье продуктов или сервисов. Наборы дизайн-паттернов часто используют при создании повторяющихся компонентов для бóльшего объема — таких, как формы регистрации аккаунта, оформления заказа покупки, или поиска. Чаще всего это называется «библиотека компонентов».

Вкладки от BBC Global Experience Language (GEL)

Финальный результат развития всего этого известен как дизайн-система (или дизайн-язык). Она объединяет в себе исчерпывающий набор дизайн-стандартов, документаций и принципов. Также она включает в себя дизайн-паттерны и компоненты, необходимые для достижения этих стандартов и соответствия тем самым принципам. Чаще всего дизайн-системы всё ещё каждодневно используются дизайнерами — из-за дизайн-паттернов или компонентов.

Сервисный дизайн-паттерн

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

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

Паттерн для стартовых страниц GOV.UK

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

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

Так в чём же проблема?

Дизайн-процесс недооценён

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

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

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

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

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

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

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

Создание паттернов начинается не с потребности пользователей

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

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

Потребности пользователей сливаются друг с другом

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

Например, когда мы создаём дизайн-паттерн для регистрации пользователей на сервисе огромной организации, стоящая задача может очень быстро поменяться с «Как проверить состояние моей заявки?»

«Могу ли я обновить или изменить свой адрес доставки?»

«Могу ли я по-быстрому продублировать или обновить свою заявку?»

на:

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

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

Результаты оцениваются выше контекста

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

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

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

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

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

Digital по умолчанию

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

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

К примеру, Канадский иммиграционный сервис в год получает более 5,2 млн запросов (по email или по телефону) от людей, которые ищут информацию об оформлении и подаче заявлений.

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

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

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

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

Сотрудники сервиса не стали определять эффективность дизайна тем, насколько короткими стали новые звонки. И хотя продолжительность обработки каждого звонка увеличилась на 16%, количество повторных звонков снизилось аж на 30% менее чем за 8 недель, высвободив время сотрудников иммиграционного центра, так что они теперь могут качественнее предоставлять информацию звонящим.

Альтернативы паттернам

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

Формулировка проблемы

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

Карты путей пользователя

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

• как пользователь взаимодействует с сервисом;
• как сервис взаимодействует с пользователем;
• средство коммуникации;
• эмоции пользователя;
• и «болевые точки» сервиса.

Потребности пользователя, а не продукта

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

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

Будьте открыты для всех

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

Создание библиотек паттернов типа open-source, как те, что управляются a11yproject.com или WordPress.org —хороший способ сохранять структуру и процесс, при этом позволяя людям вносить в них свой вклад. Прозрачный и прямой процесс отсева паттернов, характерный духу open-source, поможет уменьшить всевозможные трения.

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

В заключение

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