Ну, там же всё написано, почему они не понимают?

Подходит ко мне менеджер и говорит: “Как же так? Такие умные люди не могут понять очень простого процесса. Всё время забывают один и тот же шаг. Как же их взяли на такие высокие должности?” Эта мысль не новая, мы часто ловим ощущение, что сделали для пользователя всё, а он тупит. На самом деле нужно исходить из того, что пользователь не готов погружаться в ваш процесс. Представьте себе коллегу после 7 созвонов, общения в 100500 чатах и почтовых веток, который спешит, думая о том, сколько пробок соберёт по дороге домой, и внезапно вспомнил про задачу, которую он должен решить в вашем сервисе (подтвердить заявку или запросить новую ставку). У него есть три минуты и ноль желания разбираться. Именно это ваш типичный пользователь. Ориентируйтесь на него при проектировании процессов и интерфейсов, а не тех умных и красивых, которых привыкли видеть в офисе.

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

Задайте себе вопрос:"Что окружает моих пользователей?"
 
Мы часто говорим про то, что надо знать своих пользователей, проводить интервью и исследования. Но здесь есть возможность избежать длинных и дорогих исследований. Можно для начала посмотреть на ту среду, которая окружает вашу целевую аудиторию. Возьмём для примера разработчиков. Что является для них рабочей средой? Так или иначе - это хорошо структурированный текст: код и документация к нему. В нём мало картинок и много иерархи. Похожи ли так любимые в HR-лендинги, презентации и инфографики на это среду? 
 
Мой опыт в нескольких проектах говорит, что хорошо структурированная страничка  в конфлюенс или вики решает 80% запросов и не вызывает никаких вопросов по поводу красоты). Если у вас разная ЦА, можно даже сделать переключатель вида страницы в режим просмотра "для разработки". Избегайте своих представлений "о прекрасном" и понаблюдайте за своими пользователями.

Всегда ли нужно продуктовыми решениями лечить боль?

Часто в продуктовых кругах можно слышать мантру “найди боль пользователя, предложи продуктовое решение”. Но всегда ли она есть эта боль и всегда ли она нужна, чтобы сделать продукт лучше? Кажется, нет. Можно двигаться не от боли, а от поиска новых возможностей. Например, имеем мы бизнес-процесс оформления отпусков. Понятно, что он как-то работает, люди привыкли и могут даже не жаловаться. Но если разложить этот сценарий на карте пути сотрудника (мы уже писали про employee journey map), задаться вопросом, можно ли его оптимизировать, облегчить, то наверняка найдутся идеи улучшений, о которых никто не просил и даже не догадывался. А главное, можем себе позволить!). Подумайте, какой процесс давно не обновлялся, но достаточно популярен и требует нового взгляда сегодня.

Сколько человек нужно, чтобы вкрутить лампочку организовать поездку на конференцию?

Я сейчас в поиске ответа на этот вопрос на своём опыте оформления командировки. И список точек касания (людей, запросов в джире, задач на мне) всё растёт…

Речь про участие в конференции за границей. В моём идеальном мире процесс согласования поездки выглядит так: шаг 1 — согласование с руководителем на словах; шаг 2 — оформление задачи; (дальше некая магия…); шаг 3 — подача документов на визу; шаг 4 — сама поездка; шаг 5 — презентация инсайтов с конференции коллегам. Но вот на втором шаге реальность разъехалась с ожиданием драматично. Под командировку своя задача, под покупку билетов на конференцию — вторая, под визы — третья. Поскольку на старте для меня это было не очевидным, пришлось предварительно поискать ответственных за каждый стрим в HR и уточнить. Типа “вот для командировки оформляй такую-то задачу, а для визы не ко мне, спроси у…”

В итоге я пытаюсь синхронизировать HR-бизнес-процессы, чтобы в сумме они привели меня к шагам 3-4-5. Ощущается это как если бы в маркетплейсе нашёл вещь, а потом договаривался с продавцом о цене, с банком — о переводе денег, с логистами — о доставке вместо того, чтобы просто нажать кнопки “в корзину”-”оформить”-”оплатить”. Хороший сервис забирает рутину с клиента, плохой — добавляет. Хотел бы я, чтобы все HR-процессы были как отличный сервис!

О важности UX-райтинга и понимание языка аудитории (часть 1)

Недавно решил очередной платёж по кредиту погасить в чуть большем размере, чтобы сократить размер последующих платежей. Зашёл в любимую Альфу и пошёл по пути “погасить досрочно”, где встретил вот такой экран. Ответом на вопрос “сколько хотите внести?” очевидным для меня образом стала сумма “платёж” + “вот та моя добавочка”. Я внёс деньги и был сильно удивлён, когда в день по графику банк снова попросил заплатить. Оказалось, что на тот вопрос надо было отвечать лишь цифрой, которую готов отдать сверх платежа. Не поняв этого, я отдал банку ежемесячный платёж в двойном размере. “Спасибо” теперь уже не любимой Альфе за попытку лёгким, но ничего не поясняющим языком общаться со мной в интерфейсе.

Как думаете, почему так произошло? Где в HR-интерфейсах встречаются такие же ловушки?

О важности UX-райтинга и понимание языка аудитории

Продолжение прошлого поста про обманчивый интерфейс приложения от Альфа. Спасибо, за ваши комменты и идеи. Мы выделим три проблемы:

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

В HR, например, мы часто просим что-то согласовать руководителя и не поясняем, что будет дальше. Это вызывает вопросы: “обучение сотруднику уже согласован или нужно ещё получить “ок” от команды обучения?”

2. Двусмысленность вординга. То, что мы пишем в интерфейсах, должно быть однозначно понято пользователем. Сомневаетесь?  Покажите интерфейс и текстовки в нём десяти случайным людям из офиса. Не сомневаетесь? Всё равно покажите. То, что понятно написано для вас, может оказаться вообще неясным для других. Часто мы как профессионалы HR имеем своё представление, что значат слова “менеджер”, “курс” и пр. 


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

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

Мы тоже удивляемся: “за такой маленькой частью интерфейса, стоит так много работы!”

Создаёт ли ваш сервис культуру самоорганизованности и ответственности?

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

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

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

Таким образом, говоря о сервисной модели HR-процессов, мы должны учитывать не только опыт сотрудника, но и какую культуру он создаёт, чтобы потом к нам не бегали с вопросами про парковку и пропуска)

Поделитесь своим опытом, где с одной стороны вы делали многие вещи сами как клиент, но при этом было ощущение заботы и понятности? Мы вспомнили миниму две компании с таким сервисом, поделимся чуть позже в комментах

Бесит, когда тебя  просят подстроиться под робота!

Жутко злит, когда звонит какой-то непрошенный продавец услуги, ты берёшь трубку с мыслью: “А вдруг что-то полезное, наконец?!” — А там музыка или робот говорит: “Подождите минуту, вам ответит оператор”. — “Что?! Реально!?”

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

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

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

Друзья, мы хотим делать для вас лучший контент! Расскажите о себе
 
Мы очень рады, что нас тут уже так много. Видимо, развитие HR-продуктов и наши размышления на эту тему позволили собраться достаточно большому сообществу.
 
Звучит, как отличный повод “пересчитаться”! Вы получите понимание рынка специалистов, мы познакомимся с вами получше. Вместе будем делать сервис HR не хуже, чем в B2C-продуктах!

“Угловой случай” в вашем продукте: корнер кейс

Сегодня пост — из серии “в клиентских продуктах есть, а в HR пока не очень”(теперь помечаем такие хештегом #старший_брат). Речь про понятие “корнер-кейс” (в оригинале — corner case, как легко догадаться). Термином обозначают редкие и нестандартные примеры использования сервиса, которые создают большие сложности.

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

Чтобы ваш продукт попадал в высшую лигу, собирайтесь с командой и продумывайте такие “несчастные случаи”. Например, что случиться с формой, где сотрудник написал коллеге развернутый фидбек, если он случайно закроет браузер? Данные сохраняется при открытии страницы? А если да, то как пользователю найти эту страницу?

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


#понятие #старший_брат

Корнер кейс: сбор обратной связи на уникальных разработчиков

Мы уже писали о ценности сбора обратной связи от пользователей своего продукта и про понятие “корнер-кейс”. Поделюсь, как мне удалось, общаясь с пользователями, найти такой кейс при запуске платформы для непрерывной обратной связи (continuous feedback).

Изначально этот сервис мы делали с мыслью, что каждому будет полезно анонимно или открыто дать обратную связь коллеге, не дожидаясь ревью. Культура и механики обратной связи не просто так заботят умы примерно всех HR: буквально плюс несколько процентов к шкале “обратная связь” в опросе вовлеченности дают возможность без тренингов и обучения получить организацию, в которой люди сами развивают друг друга. Ну кому такое может не понравиться? Оказывается, есть недовольные.

В разговоре с одним из руководителей разработки я услышал такую фразу об одном из его инженеров: “Во всём СНГ такого уровня специалистов 5 человек, один из них работает у нас. Что мы будем делать, если кто-то из коллег оставит отрицательную обратную связь, а ему это не понравится?”. Хорошего ответа у меня не нашлось, но этот пример натолкнул на мысль, что руководителям (и не только тем, кто боится “дышать” на команду), действительно, будет полезно иметь возможность скрывать или открывать обратную связь самостоятельно.

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