- PVSM.RU - https://www.pvsm.ru -

Минимально жизнеспособный UX: дизайн SaaS (приложений-сервисов)

Предлагаю читателям «Хабрахабра» перевод статьи «Minimum Viable UX: A Guide for SaaS Design» [1]. Автор: Benjamin Brandall.

Создавая SaaS-приложение (wiki: англ. software as a service — программное обеспечение как услуга) вы, вероятно, больше думаете о функционале и фичах, целевом рынке, отсутствии багов в конечном продукте. И хотя сегодня признаётся важным пользовательский опыт (UX) – а бывает, он непосредственно определяет успех или поражение, – его разработка всё равно часто упускается из виду.

Помните классические рабочие программы? Эти раздутые базы данных, как в Excel под Windows 95 – сегодня вряд ли можно вести передовой бизнес с их помощью. Почему? Да потому что они не дружественны для использования.

Мы уже привыкаем пользоваться более «гладкими» приложениям. После Gmail мы практически избавились от Outlook. Мы используем прекрасно оптимизированные Trello, Dropbox и Asana. С течением времени инструменты, имеющие больше шероховатостей, чем мы готовы терпеть, заменяются на те, что в большей степени ориентированы на пользовательский опыт. Потому что нет сомнения в том, что плохой UX замедляет рабочие процессы в разы.

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

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

Минимизируйте телодвижения

Новички, желающие войти в сервис, постоянно сталкиваются как минимум со следующим:

  • Заполнить 10500 полей
  • Пройти через обязательное обучение (или всякие подсказки для новичков)
  • Полностью заполнить свой профиль

Люди, приходящие в приложение, хотят сразу получать выгоду от его использования, а когда вы просите от них больше, чем даёте взамен, вы попадаете в Цикл умирания продукта [2], как его назвал Andrew Chen. Выглядит это примерно так: на графике ниже по вертикали – кол-во пользователей и пользовательниц, по горизонтали – сначала первый визит, затем регистрация, возврат в приложение, а затем – дни (первый, седьмой, тридацатый…).

image
(Источник изображения [2])

Этот график отражает воронку, через которую проходит ваша аудитория. Практически 80% увидевших ваш заголовок не совершают заветный клик, а ещё 80% попавших на сайт – не завершают регистрацию. Оставшиеся, после нескольких сессий пользования приложением, практически «вымирают» в раз десять. Почему так происходит?

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

Попробуйте вот что:

  • Сократите число обязательных полей в форме регистрации [3]Process Street [4] на первом шаге мы вообще не просим ничего, кроме email)
  • Учите пользоваться продуктом по ходу реальной работы, а не через обязательные пошаговые инструкции
  • Подавайте информацию постепенно, не забрасывайте людей дюжиной подсказок подряд

Приложение, в котором всё это прекрасно реализовано – Slack. Можете почитать полный разбор [5] (на английском) его процесса пользовательской адаптации, но суть в том, что здесь все шаги проходить приятно и, скажем, весело (регистрация, заполнение профиля, вход, обучение).

Тщательному продумыванию и дизайну таких моментов уделяется значительное время. Вы, например, когда-нибудь предусматривали упрощение ввода пароля с мобильного устройства? А в Slack вместо этого можно получить «волшебную ссылку» [6] на емейл.

image
(Источник изображения [6])

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

Конечно, это очевидно, но видя многие приложения хочется повторять это снова и снова. Я снова возьму за пример Excel, потому что Microsoft принято критиковать :). Ну и, в отличие от Apple, никогда не предполагалось, что их софт будет «просто работать».

Недавно я отменил свою подписку на Office 365. Я пользовался ею только ради Excel, но потом пришёл к тому, что недостатки UX съедают много моего времени. Проблема была в том, что Excel не может адекватно импортировать CVS (англ. comma separated values – значения, разделённые запятыми). Чтобы объяснить программе, что мой CSV-файл именно разделённый запятыми, приходилось или подстраивать файл в текстовом редакторе, или использовать устрашающий wizard-помощник для импорта.

image

Там не было опции, позволявшей бы просто кликом открыть файл и нормально его отобразить. Поэтому я отписался от MS Office и вернулся к таблицам в Google [7], которые, правда, намного менее мощные. Это хороший пример пользовательской текучки [8] из-за плохого UX, а не недостатка функкий.

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

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

Сведите реальность вашего приложения с пользовательскими ожиданиями

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

Есть специальное Правило наименьшего удивления [10] (wiki):

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

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

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

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

Не важно, что у вас за приложение – людям приходится так или иначе учиться им пользоваться. Упростить этот процесс можно используя знакомые дизайн-стимулы. Доказано, что узнаваемые иконки [11], меню и взаимодействия делают интерфейс интуитивно понятным, равно как мы понимаем, что делать с носком или кружкой, поскольку уже знакомы с этими предметами.

В качестве заключения

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

Мы до сих пор находимся в «серой зоне» UX даже спустя 16 лет после выхода хрестоматийной книги Дж. Гарретта «Элементы опыта взаимодействия» (есть на русском языке). Но похоже, что продуманный дизайн всё-таки занимает своё место, и мелкая но инновационная SaaS-разработка всё увереннее потесняет корпорации.

Держите в уме эти простые принципы, и делайте вещи, которые «просто работают» (и «работают просто» – прим. переводчицы).

Автор: azinchanka

Источник [12]


Сайт-источник PVSM.RU: https://www.pvsm.ru

Путь до страницы источника: https://www.pvsm.ru/ux/170308

Ссылки в тексте:

[1] «Minimum Viable UX: A Guide for SaaS Design»: https://www.chargebee.com/blog/saas-ux-guide-benjamin-brandall/

[2] Цикл умирания продукта: http://andrewchen.co/this-is-the-product-death-cycle-why-it-happens-and-how-to-break-out-of-it/

[3] полей в форме регистрации: https://www.chargebee.com/blog/password-rules-to-boost-signups-saas/

[4] Process Street: http://process.st/

[5] полный разбор: https://www.useronboard.com/how-slack-onboards-new-users/

[6] «волшебную ссылку»: https://auth0.com/blog/2015/12/04/how-to-implement-slack-like-login-on-ios-with-auth0/

[7] вернулся к таблицам в Google: https://www.process.st/microsoft-excel-vs-google-sheets/

[8] пользовательской текучки: https://www.chargebee.com/blog/avoid-churn-identify-risk/

[9] хорошо организованную поддержку: http://process.st/customer-support-process

[10] Правило наименьшего удивления: https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B0%D0%B2%D0%B8%D0%BB%D0%BE_%D0%BD%D0%B0%D0%B8%D0%BC%D0%B5%D0%BD%D1%8C%D1%88%D0%B5%D0%B3%D0%BE_%D1%83%D0%B4%D0%B8%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F

[11] узнаваемые иконки: https://bold.pixelapse.com/minming/share-the-icon-no-one-agrees-on

[12] Источник: https://habrahabr.ru/post/307474/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best