Как плохой UX убивает прибыльность сайтов и приложений
10.09.2018
В далеких 90-х годах Стенфордский университет провел занимательный эксперимент, в рамках которого участников разделили на две группы и попросили одну из них настучать пальцами по столу любой из популярных на то время хитов, а вторую — угадать эту мелодию. Решительно все «барабанщики» были свято уверены в том, что распознать «наигранную» ими песню будет легко и просто, но результаты показали обратное. Правильно угаданы было лишь не многим более 2% загаданных композиций.
Этот эффект сейчас называют «Проклятием знания». Его суть заключается в том, что «барабанщики» знали мелодию и им казалось, что по их «виртуозной игре» угадать её не составит никакого труда. Но в это же время те, кто занимались разгадыванием этих мотивов, слышали только неразборчивый набор звуков. То же самое происходит с человеком и в любом другом виде деятельности. Тут нет ничего сверхъестественного, так как это обычная особенность человеческого восприятия и не более того.
И если недопонимание в разговоре может повредить только Вашему чувству собственного достоинства, то недопонимание пользователей запросто может похоронить Ваш сайт или мобильное приложение. В данной статье Вы найдете небольшую подборку практических советов, составленных на личном опыте и опыте моих коллег, которые помогут выявить существующие недоработки в UX Вашей разработки и вовремя внести необходимые правки.
Если вы не в курсе, что означает UX, то сначала предлагаю Вам ознакомиться с моей статьей «UI/UX дизайн: что это такое?».
Сложное делаем простым.
Современные подходы к интерфейсу выставляют высокие требования к экономии времени и усилий пользователя. В связи с чем сложные многоуровневые вложенные меню давно ушли в прошлое. Всё, что ранее было сложным, сейчас нужно делать максимально простым и понятным. И это требование касается абсолютно всего, от процесса регистрации на сайте, до процесса вывода денег из мобильного банкинга. Всё должно быть компактным, удобным и интуитивно понятным.
В качестве примера необходимого упрощения можно привести инструкции, которые все мы часто можем видеть при первом запуске того или иного мобильного приложения. Давно ли Вы видели длинные инструкции из больших массивов текста? Очень сомневаюсь, что за последние несколько лет Вам на глаза попадался хотя бы один подобный пример. А всё потому, что такие огромные инструкции прежде всего раздражали людей, теряя свою эффективность. В наше время такие инструкции выглядят как короткая последовательность из красивых и информативных картинок с небольшими текстовыми описаниями, которые нужно пролистать перед тем, как начать пользоваться мобильным приложением и называются онбордингом.
Еще одним слабым местом в этом плане всегда были формы регистрации. На многих архаичных сайтах и в первых мобильных приложениях они были сложными и довольно длительными, так как с пользователя старались собрать как можно больше данных для дальнейшего их использования. В наше время формы регистрации сократились до минимума (обычно это просто выбор логина и пароля), а всю остальную информацию собирают уже другими способами.
Лаконичность и логичность дизайна.
Частой ошибкой разработчиков, особенно свойственной для малобюджетных проектов, является привлечение неопытных дизайнеров по причине их дешевизны. Иногда во время процесса разработки подобных «дизайнеров» даже начинают менять на других, когда видят, что они не справляются с поставленными задачами. В итоге финальный дизайн сайта или мобильного приложения выглядит как недорогое лоскутное одеяло, что совсем не прибавляет очков доверия к продукту в глазах будущих пользователей.
Дабы уровень вовлеченности юзера не падал, стоит всегда учитывать следующие правила при разработке дизайна:
- Графика должна быть качественной.
- Контент должен быть лаконичным и понятным.
- Не должно быть очень мелких кликабельных элементов UI
Всегда нужно задаваться вопросом: способен ли Ваш пользователь предвидеть свой следующий шаг, пользуясь Вашей разработкой, и не брызнет ли фонтан крови из его глаз во время первого взгляда на тот или иной элемент. В противном случае Ваш веб-ресурс или приложение будет стремительно терять свою аудиторию.
Всему своё время и своё место.
Каждый блок информации, который Вы демонстрируете пользователю, должен быть к месту и ко времени. Это, например, означает, что не нужно показывать подсказку по работе определенного элемента на сайте или в мобильном приложении, если на текущем экране этого элемента нет. Такую подсказку нужно активировать только тогда, когда у юзера в первый раз понадобится необходимость воспользоваться этим функционалом.
Другим примером несоблюдения этого принципа является частая ошибка в реализации push-уведомлений мобильных приложений. До сих пор можно встретить пуши, содержащие большое количество текста или нормальные, но бомбящие юзера с частотой один раз в пять минут. Подобную картину я нередко встречаю и на сайтах, которые запрашивают разрешение на отправку мне различных уведомлений, от которых потом приходится срочно отписываться или вообще блокировать любую активность с этого ресурса. Да, в итоге я не получу информации о какой-то акции, но мне, как пользователю, это кажется вполне приемлемой жертвой. В итоге единственным, кто пострадает, останется владелец ресурса, от уведомлений которых пользователь отказался.
А ведь чтобы подобного не происходило, достаточно придерживаться простых правил хорошего тона:
- Нельзя частить. Каждое уведомление должно казаться важным для юзера, иначе он его просто не прочитает.
- Нельзя рассылать уведомления всем пользователям на мобильном устройстве или компьютере. Подписывался один юзер — вот ему и нужно отправлять информацию.
- Текст в уведомлениях должен быть кратким и побуждающим к конкретному действию.
Проси минимум — получишь по максимуму.
Пользователи приложений и сайтов крайне неохотно делятся своей информацией и дают какие бы то ни было разрешения от своего имени. Особенно это чувствительно для мобильных приложений, которые то и дело начинают запрашивать доступ к контактам, фотографиям и прочим местам во время своей установки на смартфон потенциального юзера. Многим легче плюнуть и отказаться от установки, чем решиться на выдачу глобальных прав доступа ко всему и сразу на своем устройстве.
Об этом даже написано в официальном гайде по разработке для Android, где советуется запрашивать только минимум прав, которые реально нужны для работы приложений. А если прав нужно больше, то пользователю необходимо грамотно это объяснить.
Грамотная монетизация — залог успеха.
Даже самый хороший сайт или удачное мобильное приложение можно легко загубить неудачными решениями в вопросе монетизации. Особенно это остро ощущается в вопросах интеграции в существующий UX различных рекламных баннеров, игнорируя логику и мешая концентрации внимания пользователя на контенте. Вследствие чего уродливые и навязчивые баннерные картинки начинают бестолково встраиваться между текстовыми блоками везде, где это только возможно, придавая своему ресурсу вид мусорной кучи. Пользователи не будут терпеть это долго и уйдут, сводя Ваши поступления от рекламы к позорному минимуму.
Особенно часто такая ошибка встречается у сайтов и приложений, которые уже были выпущены на рынок, после чего их владельцы начали сломя голову внедрять на них монетизацию, правдами и неправдами запихивая что не попадя в разработанный ранее UX.
Всё должно быть продумано заранее, еще на этапе разработки. В противном случае с внедрением новшеств не стоит спешить и особенно не стоит на этом моменте экономить. Добавляете элементы монетизации — раскошельтесь на грамотную переработку UX, иначе все Ваши предыдущие усилия могут разом пойти прахом.
Постоянно улучшайте «прилипчивость» своего сайта или мобильного приложения.
По современной статистике около 30% пользователей не возвращаются в приложения после первого его запуска. А если его открывают менее одного раза в неделю, что с почти 70% вероятностью его очень скоро забросят и сотрут с устройства. Примерно та же картина наблюдается и на сайтах, которые также должны бороться за удержание своего клиента всеми правдами и неправдами. Уж больно велика сейчас конкуренция на этих рынках. А это напрямую влияет на их доходность.
Посему, разрабатывая сайт или приложение, всегда стоит думать над тем, как «приклеить» к будущему ресурсу своего пользователя. Нужна какая-то фишка, которой можно будет его зацепить, надежно привязав к себе. Эту роль чаще всего выполняют дизайн и определенные нюансы юзабилити, западающие в душу юзера.
Исходя из вышеприведенного можно сформулировать следующие правила, позволяющие обнаружить слабые места в UX на ранних стадиях разработки или проанализировать на предмет нахождения слабых мест в юзабилити уже готового сайта или приложения:
- Никогда не тестируйте свои разработки самостоятельно. Привлекайте к тестам как можно больше сторонних людей и вдумчиво анализируйте их отклики.
- Не брезгуйте созданием прототипов. Перед тем, как начинать разработку чего-то сложного, создайте черновой макет будущего продукта (всех его страниц и экранов), после чего соберите из этих наработок кликабельный прототип. Ресурсов для этого сейчас очень много в интернете. Так Вы получите работающую модель будущего сайта или приложения еще до этапа создания чистового дизайна. Выявлять ошибки в UX гораздо выгоднее и дешевле на этом этапе.
- Минимизируйте всё, что возможно. Любой элемент управления или функциональный блок должен рассматриваться сначала через призму того, а можно ли сделать его еще проще. Поверьте, иногда выгоднее немного дольше разрабатывать продукт, продумывая эти детали, чем потом страдать от постоянного оттока пользователей.
- Не грузите пользователя лишней информацией. Работая с вашим ресурсом, юзер не должен долго размышлять над своими действиями. UX должен быть продуман до мелочей, и Вы буквально должны вести пользователя за ручку, не давая ему осознать этот факт. Особенно это важно, если Вы планируете зарабатывать на своих цифровых продуктах.
- Нанимайте только опытных исполнителей. Всё, что Вы хорошо можете сделать сами — делайте. Для всего остального наймите профессионалов. Экономия на опыте разработчиков скажется для будущей монетизации боком.
- Грамотный UI/UX дизайн — Ваше всё. Тут, я думаю, какие-то комментарии будут излишними.
