Про интерфейсные тексты, психологию, UX-ляпы и развитие
Собрал дайджест самых популярных UX-заметок 2019 года.
Весь 2019 год я делал заметки про UX, продуктоводство и командную работу в телеграм-канале Про удобство telegram.im/proudobstvo. По итогам года собрал дайджест самых популярных заметок по теме UX.
Про текст в интерфейсе
Менторский тон интерфейсного текста
Текст в интерфейсе сделал большой шаг вперёд. Если раньше даже в топовых продуктах было много текстовых проблем, то сейчас чаще всего чистенько, понятно и аккуратно.
Но текст шагает дальше и порой не в ту сторону — вместо общения с пользователем на равных, продукты начинают общаться в менторском тоне (высокомерно-поучительно).
Прям подбешивают порой рубленые поучительные фразы. Понятно, что “Пиши, сокращай” и всё такое, но продукт не должен общаться с пользователем в режиме робота — их, итак, слишком много. Капелька чувст в текст не повредит.
Например,
Запрос получен, ответим через 7 дней. Проверяйте почту mail@mail.ru
Всё ок, ничего лишнего. Но так “говорят” бесчувственные роботы.
Мне как пользователю приятнее, когда текст человечный, а не рубленый до минимума. Например, так:
Мы получили ваш запрос и точно ответим на него в течение 7 дней. Ответ придёт на почту mail@mail.ru.
В общем, продукты с душевным и понятным текстом приятнее использовать, чем продукты с рублеными фразами в менторском тоне.
Про изучение пользователей
Понятие нулевого UX
Об этом мало кто скажет, но когда рождается новый продукт его реальный UX всегда равен нyлю.
Пригибаясь от помидоров, которые в меня кинут примерно все, кто пишет “мы сделали продукт с крутым UX”, “мы делали передовой UX/UI” и т.п., поясню.
Если у продукта примерно 0 пользователей, то и пользовательского опыта по общению с продуктом (того самого UX) примерно столько же.
При создании продукта можно было учесть внешний опыт, советы по созданию удобных продуктов и всё иное, т.е. UX других продуктов. Но собственный пользовательский опыт появится только с первыми пользователями — вот тут и надо быть начеку и изучать его.
Нет реального использования продукта — фантазийный UX.
Есть реальное использование — реальный UX.
На деле же, после запуска продукта с крутым фантазийным UX можно настолько быть в этом уверенным, что изучение реального UX будет далеко не первостепенной задачей. В общем, изучайте чужой опыт до и во время запуска, а после запуска обязательно изучайте своих пользователей.
Про динозавров
230 млн лет назад (230! млн. лет назад) по Земле ходили Герреразавры.
Это были относительно легкие двуногие хищные динозавры. У них был длинный хвост и довольно маленькая голова. Длина тела примерно 6 метров, а весили порядка 650 кг.
Строение их тела говорит о том, что они довольно быстро бегали. Стопа герреразавров имела пять пальцев, однако полностью развиты были только три средних (II, III и IV). Два остальных (I и V) не несли на себе нагрузку от тела — они были сбоку и имели только коготь. Хвост был укреплен отростками позвонков и играл роль балансира при ходьбе и беге. На первых трёх пальцах передних лап были крупные загнутые когти ими герреразавры хватали и удерживали добычу. Догнал, схватил и съел.
О зверюге, которая жила на Земле 230 миллионов лет назад (аж в голове не укладывается цифра), известно больше, чем многим известно о пользователях, для которых создаётся продукт. Если вы не знаете досконально проблемы или мотивации пользователя, то создать классный продукт меньше шансов. Зачастую команда фокусируется на дизайне и функциях, которые в дальнейшем оказываются абсолютно бесполезными.
Если делать продукты для физлиц, то там вероятность “попасть” в потребность выше, так как команда ближе к проблемам физлиц — сами же люди.
Если делать продукты для бизнеса или государства — то лучшие продукты получаются, как правило, у тех, кто либо сам в этом же бизнесе поработал, либо много времени провёл внутри бизнеса, изучая процессы.
В 2015 году, работая в заказной разработке, я был в составе большой группы, которая делала продукт регионального уровня: муниципальные услуги, сервисы для жителей, мониторинг инвестиционных проектов.
И вот мы пошли на приём к мэру одного из региональных городов — приветливый и умный дядька.
Начали обсуждать сервисы для жителей. Один из сервисов был про активных горожан — отметил место на карте, приложил фотку и отписал, что не так. Все видят, голосуют за самые острые дела, а власть расторопно всё исправляет. У жителей, вероятно спрос был бы, если бы власть реагировала на запросы. Но на деле схема оказалась неработоспособной для небогатых городов (а это почти все). Приветливый и умный дядька нам сказал: “Мы уже знаем о таком количестве проблем, на которые не хватает городского бюджета. Зачем же мы будем давать людям ложную надежду и собирать их ещё больше — мы можем реагировать только на самые острые проблемы”. Сервис не зашёл.
В общем, как можно больше и как можно раньше общайтесь с теми, для кого создаёте продукт — можно избежать кучу лишней работы или избежать никому не нужный продукт.
Про слона
На картинке слон. Таким его рисовали средневековые художники, основываясь только на рассказах путешественников.
Это к вопросу о необходимости качественно изучать пользователей — можно нафантазировать что-то нереальное.
Про хитрожопых пользователей
В мае 2019 года вышла новость о хищении денег в Сбере. Вот пишет Коммерсантъ:
Участились жалобы клиентов Сбербанка на хищение денег с помощью платежных терминалов. Алгоритм мошенничества прост: злоумышленник начинает на терминале операцию, не вставляя карту, не завершает ее и отходит. Терминал дает на завершение операции 90 секунд, и если в этот период свою карту вставит следующий клиент, то с нее и будут списаны средства по запросу предыдущего.
Такой вот чёрный UX.
Мошенничества с помощью “дырок” в продукте — высший пилотаж хитрожопости.
Но и без прицела на мошенничество пользователи хитрожопые.
Если продукт ограничивает пользователя, то у многих автоматически включается режим хитрожопости — как будто водой на гремлина накапали.
Некоторые продукты своими ограничениями рождают индустрию хитрожопости: например, радар/антирадар.
Продукт может ограничивать пользователя по-разному:
👊 Денежное ограничение — разные продуктовые версии. Триал/Старт/Профи. Хитрожопый захочет пользоваться Профи по цене Триала.
👊 Ролевое ограничение — Пользователь/Модератор/Админ. Хитрожопый захочет быть админом.
👊 Контроль — некоторые продукты созданы, чтобы контролировать пользователей (тот же скоростной радар, который контролирует скорость пользователей дороги). Хитрожопый захочет выйти из-под контроля.
Так вот, хитрожопые пользователи — настоящий вызов для продуктовой команды.
Они, по понятным причинам, не рассказывают про свой пользовательский опыт 🙂
Вы можете и не знать, что в продукте есть логическая или программная дырка, а хитрожопые пользователи уже к ней дверь приставили.
Пример одной логической дырки
Когда-то давно я был менеджером продукта, который автоматизирует деятельность торговых представителей и их руководителей.
Торговый представитель — это человек со смартфоном, который ездит по магазинам, фиксирует остатки и получает в магазине новый заказ на доставку товаров, попутно он вносит данные по конкурентам и красиво поправляет свои товары на полках. В целом — милейшие люди.
Наш продукт автоматизировал и контролировал торговых представителей. Контроль заключался в том, что при визите в магазин торговый должен снять GPS координаты — его руководитель видел: был ли он в магазине или нет.
Цель хитрожопых торговых — не ездить в магазин, а звонить и брать заказ по телефону, а остальные данные вбивать наобум.
И вот, спустя время, мы узнаём о хитрожопости:
торговый представитель с утра ехал по маршруту, в каждом магазине начинал визит, снимал координаты и, не завершая визит, ехал дальше. За 1 час он объезжал весь маршрут, в каждом магазине снимая только координаты.
После этого он возвращался домой или ехал на шашлык и звонил в магазин, чтобы взять заказ по телефону (это быстро). Визиты он завершал в нужное время.
Для бизнеса это плохо — вместо активных продаж ленивые обзвоны.
Внешне продукт показывал, что всё хорошо — ездят по точкам, берут заказы. Но в продукте жили хитрожопые пользователи.
А выяснилось всё благодаря карьерному росту — хитрожопый торговый стал руководителем и всех заложил.
Закрылась дырка тоже легко — добавили отображение времени визита, которое краснело при отклонении от нормативов.
Про UX и психологию
Эксперимент добрый самаритянин и UX
В 1973 году психологи Джон Дарли и Дэниел Батсон провели эксперимент “Добрый самаритянин”.
В основе эксперимента притча о добром самаритянине: одного мужика (иудея) по дороге из Иерусалима в Иерихон ограбили и избили разбойники, а после оставили помирать на дороге. Лежал он и помирал, а мимо прошли священник и левит — не помогли. А самаритянин, проходивший мимо, помог и даже отвёз в гостиницу. Иудеи и самаритяне при этом враждовали.
Так вот, эксперимент о добром самаритянине следующий: студентам богословской семинарии сначала дали задание пообщаться и обсудить предание о добром самаритянине. Так все погрузились в притчу и её суть — оказание помощи любому нуждающемуся. После этого студентов попросили перейти в другой корпус и провести там лекцию о добром самаритянине (преподаватель заболел и надо подменить). При этом, одним студентам сказали, что до начала лекции времени достаточно, даже с запасом, а другим сказали — надо торопиться, уже ждут.
По дороге в другой корпус разместили актёра, который изображал эпилептический припадок, когда мимо шёл испытуемый студент. Т.е. студент должен был принять на себя роль самаритянина и помочь бедолаге.
В итоге:
Из тех, кто не торопился: 63% студентов помогли.
Из тех, кто торопился: только 10% студентов помогли.
Получается, что внешние обстоятельства для большинства оказываются сильнее внутренних убеждений и ценностей.
Причём здесь UX?
Создавая в продуктах сильные внешние обстоятельства можно управлять поведением пользователей.
Например, booking. Заходишь на него весь уверенный в своём умении рационально выбирать, а тебе тут: скидка, последний номер и смотрят его вместе с тобой 5 человек. Надо брать!
Эксперимент над гарвардскими студентками
Два социальных психолога из Гарварда — Дж. Вейсс и П. Браун — попросили студенток Гарварда оценить факторы, которые влияют на их настроение.
Факторы были достаточно простые: ситуация на работе; продолжительность сна; физическое самочувствие; погода на улице и так далее.
Казалось бы, получены данные, на основе которых можно строить гипотезы.
Но исследователи не успокоились и в течение нескольких месяцев проверяли ответы. Например, на улице плохая погода — звонят студенткам и уточняют, что там у них с настроением. В общем, всё перепроверили.
И что же оказалось!? Оказалось, что в анкетах полнейшая чушь:
1. все студентки пребывали в тотальной иллюзии — никакой корреляции между их ответами и реальным положением дел обнаружено не было.
2. все женщины, заполняя свои анкеты, отвечали примерно одно и то же. То есть у гарвардских студенток есть некая единая (и предельно неадекватная) концепция того, что влияет на их женское настроение.
Что нам делать с этим знанием?
1. Надо понять, что только эксперимент даёт наиболее полную картину реальности.
2. Надо критически относиться ко всему, что получено не экспериментальным путём: люди склонны придумывать себя.
Про UX-ляпы
Не сбрасывать — мощная добавка к удобству
Система не должна выкидывать пользователя из контекста — это всех бесит.
🤦♂️ Листаешь автоподгружаемый список с записями и перешёл к просмотру конкретной записи. Вернулся назад — попал снова в начало списка.
🤦♂️ Смотришь постраничный список, дошёл до 10 страницы. Открыл запись. Вернулся назад — снова первая страница.
🤦♂️ Выполнил многокритериальный поиск и получил список записей. Перешёл к конкретной, вернулся — поиск сброшен.
🤦♂️Настроил под себя дашборд (графики). Ушёл на другую страницу. Вернулся — снова умолчательный режим.
👉 Пользователя надо оградить от повторных бессмысленных телодвижений.
Мой ТОП UX-мракобесия
Бесит, когда:
🤬 Ты нажимаешь на кнопку, а она не реагирует. Ты жмёшь ещё пару раз. А потом оказывается, что с первого раза всё пошло и твои последующие нажатия применились к другим записям.
🤬 Не говорят, что функции платные. Ты что-то сделал в приложении, пытаешься завершить, а тебе — плати.
🤬 Нельзя войти через соцсети. Нужна сильная мотивация, чтобы пользоваться чем-то, куда нельзя входить через гугл, яндекс или facebook.
🤬 Нельзя отписаться от рассылки, не входя в личный кабинет.
🤬 Что-то само всплывает. Разрешите уведомления, Подпишитесь на рассылку, Я Ваш консультант, Акция-распродажа — мракобесы.
🤬 Тупой юмор в серьёзных приложениях. “Ой, кажется, что-то пошло не так. Дышите глубже” — это не смешно, когда ты деньги переводишь.
🤬 Отсутствие реакции на обратную связь. Напишешь в обратную связь, а тебе в ответ никакого подтверждения: получили или нет, когда ответите?
🤬 Когда только зарегался или поставит приложение, а тебя просят отзыв. Я могу только двойку сходу поставить. Дайте понять, куда попал.
🤬 Интерфейсные тексты написаны с ошибками. Что же там внутри тогда, если копнуть. Персональные и платёжные данные доверять не хочется.
Забыть про наведение
Есть в UI один приём, который должен был умереть после распространения тач-экранов (пальцем тыкать), но его постоянно пытаются воскрешать.
Я про показывание чего-либо при наведении курсором.
Наведение даже и без тач-экрана всегда было какой-то дизайн слабостью.
🤦♂️ Не могу придумать, как нормально показать подсказку к полю — О! Покажу при наведении.
🤦♂️ Не могу сделать приличные подписи к иконкам — О! Покажу названия иконок при наведении.
🤦♂️ Скрываю названия полей после ввода в них значений — О! Выведу названия у заполненных полей при наведении.
🤦♂️ Обрезаю текст в ячейках таблицы — О! Полный текст выведу при наведении.
При распространении тач-экранов скрытие информации за наведение стало не просто слабостью, а дизайн-отсталостью.
Это всё равно что делать два слоя интерфейса, но при этом до второго слоя не всем легко добраться.
Тач-экраном, кстати, может быть не только мобильник или планшет.
Надо просто забыть про наведение, как единственный способ показать какую-либо информацию.
UI должен работать без наведения — это хорошо для всех устройств.
Про убогие MVP
MVP, а если по отечественному, то МЖП — это минимальный жизнеспособный продукт.
МЖП делают быстро для тестирования гипотезы востребованности.
Так вот “быстро” не значит, что всё должно быть из говна и палок.
Если хочется проверить гипотезу востребованности, то дизайн и эргономика должны привлекать.
Внутри могут быть заплатки на заплатках и говнокод, но внешне должно быть привлекательно.
Ходить к пользователям с хреновым дизайном и UX — тратить и их, и своё время. Только в учебных целях можно делать прототипы из картона или серых блоков, чтобы мышление прокачать на тему, что можно делать не всё сразу.
Я, как пользователь, уважаю приятные и удобные продукты. Продукт должен быть ооочень уникальным, чтобы ему можно было простить убогость.
В общем, второго шанса произвести первое впечатление не будет.
Про развитие
Насмотренность → Напользованность
Если хочешь делать продукты с хорошим пользовательским опытом — развивай свой личный пользовательский опыт.
Очень часто пиарят важность насмотренности: ходи на Бехансы и смотри, что крутые рисуют.
Это, конечно, лучше чем не ходить, но в бою с хреновым UX пригодится слабо. Смотреть как штангу тягают или самому потягать — разные ощущения и опыт.
В бою с хреновым UX пригодится твоя напользованность: чем с большим количеством разных продуктов ты поработал, тем шире у тебя пользовательский кругозор.
Когда ты сам пользуешься продуктом, то видишь не только продукт в виде интерфейса. Тебя вовлекают в продукт, дожимают до покупки, с тобой общаются — это всё складывается в пользовательский опыт. Со временем накапливается больше личного опыта и удачных практик, которые ты будешь транслировать в свою работу.
В общем, хватит только смотреть — больше пользуйся.
Кто отвечает за UX?
Кто должен отвечать за то, чтобы пользователь пришёл в продукт и получил положительный пользовательский опыт?
Если команда думает, что наняв UX-дизайнера всё станет хорошо, то это ошибочно.
В поведении продукта, в его работе с пользователем, да и в самой стабильности работы очень многое зависит не от дизайнера.
На острие UX-атаки находятся фронтэнд программисты, QA (тестировщики), а также все остальные: кто-то больше, кто-то меньше.
Задача дизайн-команды (или дизайнера, или того, кто за него) — доносить знания о UX до коллег: рассказывать о важности заботы о пользователях, собирать и транслировать лучшие практики, можно даже тесты проводить на знание основ UX.
В общем, чтобы команда делала крутые решения — команду надо качать. Организовывать внутренние митапы, рассказывать про удобство, не замыкать UX на ком-то конкретном. Каждый должен думать о пользователях и их потребностях.
Для убедительности — несколько примеров UX-ляпов, которые от дизайнера почти не зависят:
🤦♂️ Когда ссылка написана внутри блока (похожа на кнопку), но чтобы перейти надо кликнуть именно по тексту, а не по всему блоку.
🤦♂️ Когда надо попасть именно в квадратик, чтобы чекнуть чек-бокс, а по названию нажать нельзя.
🤦♂️ Когда код страны уже вписан в поле с телефонным номером и убрать его нельзя. Из-за этого просто скопировать/вставить номер нельзя — обрезается последняя цифра.
🤦♂️ Когда твой город даже не пытаются определить, а сразу предлагают выбрать из длинного списка.
🤦♂️ Когда на форме входа при неверном вводе стирают и логин, и пароль.
Книги для прокачки
Собрал подборку 25 ТОПовых книг — каждая книга в списке не случайна и имеет рекомендации от крутых отраслевых специалистов.
В подборке про UX, дизайн, продуктоводство и всякую потребительскую психологию.
Чтобы ничего не пропустить, подписывайтесь на мой Telegram-канал @proudobstvo — про UX, продуктовую разработку и саморазвитие.
