Frontender Magazine

Дизайн для сервисов не заканчивается на экране # Энди Полейн

Модель «производитель/потребитель» настолько распространена в нашем обществе, что мы зачастую относимся ко всему как к продукту — некоему одноразовому предложению, которое можно выбросить на рынок и забыть.

Работа с онлайн-сервисами редко бывает настолько простой.

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

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

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

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

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

![Одноканальное мышление][multichannel1]

Одноканальное мышление

![Многоканальное восприятие][multichannel2]

Многоканальное восприятие

Сервис — это не продукт с конвейера

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

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

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

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

![Ячейки][silos]

Много предприятий организованы по ячеечному принципу.

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

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

![Экология][ecologies]

Сервис — это экология.

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

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

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

Так или иначе, в восприятии сервиса пользователем появляется трещинка.

На сервис влияют место и время

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

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

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

Например, после недавнего апгрейда автоматических билетных касс на поезда Deutsche Bahn в Германии, графический дизайн экранов стал приятнее, но общий поток взаимодействия сильно замедлился. Интерфейс автоматов стал похож на интерфейс сайта, но в контексте, когда ты опаздываешь на поезд, его медитативный пошаговый интерфейс дико раздражает.

![Deutsche Bahn][deutschebahn]

Из-за пошаговых вкладок работа с новыми билетными автоматами Deutsche Bahn стала очень медленной.

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

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

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

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

Начинайте делать дизайн не с экрана

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

Мы говорим, что у нас отлично получается чувствовать, что думают наши пользователи, но у дизайнеров есть проблема с тем, чтобы повернуть бинокль в сторону своих клиентов. Мы зачастую видим нашу роль в том, чтобы защитить пользователя от корпоративной близорукости. Почему бы нам не спросить: «Да, управлять компанией с 5000 сотрудников, наверное, сложно. Расскажете нам об этом?»

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

Дизайнеры прекрасно умеют делать вещи, которые нельзя потрогать, осязаемыми, и привыкли визуализировать и передавать взаимозависимости одной системы с другими. Мы можем делать это с экосистемами сервиса ровно настолько же, насколько мы можем делать это с архитектурой сайтов. Для этого можно разрабатывать такие вещи, как [схемы сервисов][1], [карты поведения пользователей][2], [раскадровки][3] и [прототипы][4]. Все это помогает тем людям, которые предоставляют сервисы, понять, как будет ощущаться работа с ними — и выделить те ситуации, когда что-то может пойти не так.

Например, норвежская энергетическая компания Haflsund столкнулась с большим количеством запросов в колл-центр. Компания могла бы нанять больше работников, но они выяснили, что проблема начиналась задолго до колл-центра: [30% звонков поступали от пользователей, которые не понимали содержимого присланных им квитанций][5]. Прототип помог сформировать и протестировать решение — и его введение стоило намного дешевле, чем увеличение количества сотрудников.

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

Дизайн ради изменения к лучшему

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

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

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

Многим топ-менеджерам комфортнее обсуждать бизнес по Excel-табличкам, а не по восприятию, потому что числа кажутся объективными. Но что каждый хочет на самом деле — это неких гарантий в том, что проект не провалится. Эти гарантии могут идти и со стороны бизнеса, и со стороны дизайна. [Отвлечься от экрана][6] и показать что-то наглядное и осязаемое, что можно ощутить и протестировать, перекидывает мост между этими двумя сторонами.

[1]: http://www.servicedesigntools.org/tools/35 [2]: http://www.servicedesigntools.org/tools/8 [3]: http://www.servicedesigntools.org/tools/13 [4]: http://www.servicedesigntools.org/tools/24 [5]: http://liveworkstudio.com/client-cases/hafslund/ [6]: http://liveworkstudio.com/the-customer-blah/pilot-or-perish/

[multichannel1]: http://d.alistapart.com/377/multichannel1.jpg [multichannel2]: http://d.alistapart.com/377/multichannel2.jpg [silos]: http://d.alistapart.com/377/silos.jpg [ecologies]: http://d.alistapart.com/377/cx_view.jpg [deutschebahn]: http://d.alistapart.com/377/bahn_ticket_machine_800.jpg

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом редакторам Антону Немцеву в skype ravencry, Константину Гупалову в skype cosmik_soul или в skype matmuchrapna доброму Владимиру Старкову.

Andy Polaine
Автор:
Andy Polaine
Twitter:
@apolaine
Сaйт:
http://www.polaine.com/
Vlad Andersen