​​Нашла тут артефакт с ретроспективы, которую я проводила когда-то давно.

UX-писатель — это даже не про T-shaping, а про Щ-shaping. Желательно уметь делать всё (но не обязательно потом это делать). Проводить эксперименты, мозгоштурмить, сделать макет, протестировать, залить мерж-реквест, залезть в код и смочь хотя бы прочитать что-то в нём, менеджерить проекты, работать с командой и пользоваться продуктом.
Когда всё это умеешь, легче поставить себя на место другого человека и подобрать такие аргументы, которые будут ему хотя бы понятны (а лучше — полезны). А таких коммуникаций в нашей работе много каждый день, в отличие от ретроспектив.

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

​​Кто вы? Идите нафиг, я вас не знаю.

Приложение «Rutaxi» присылает уведомление о том, что некие «Везёт» объединяются с «Яндекс Go». Спасибо, но мне это ни о чём не говорит.

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

Говорите с пользователем на языке пользователя, пожалуйста.

Да, спасибо, Outlook, так действительно гораздо удоб

Спустя год работы в MS Teams я всё-таки нашла, где настраивать статус пользователя дольше, чем на неделю!

Настрой на обосраться

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

У тебя есть гипотеза? Обозначь критерии успеха и тестируй. Прошло успешно — хорошо, неуспешно — тоже хорошо, мы теперь знаем, что прошлый вариант был лучше.

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

Мы договорились, что во время моего отсутствия переводить никто ничего не будет. Что может получиться:

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

Главное — один раз понять, что это очень полезно. И больше не будет так страшно ошибаться:)

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

Находите свою аудиторию, смотрите, как живут эти люди, и делайте им хорошо ❤

​​Продолжение истории про такси.

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

На этот раз «приложение выключится». Но оно же у меня не включено!
Попытались донести ценность («чтобы такси можно было заказать, когда понадобится»), но не смогли.

​Тем временем Рокет обработал мою заявку и закрыл счёт 😭

И даже про это они написали понятно. Быть классными — так уж до самого конца.

​​Напомнило задачки по химии про выход вещества

Как отличить «руки» от «головы»

В комментариях на Фб вчера спросили — как отличить исполнителя-«голову» от «рук» на этапе найма. Тут есть несколько нюансов:

🔥1. Опыт все равно важен. Это не значит, что новичок не может быть «головой». Но чтобы полноценно решать задачи, брать на себя ответственность, выдавать результат — исполнителю нужны знания и опыт. Если вы нанимаете «голову», чтобы полностью и сразу передать какой-то процесс, ищите опытного человека. А если есть возможность обучать и выращивать людей, тогда думающие новички с подходящими навыками тоже подойдут.

🔥 2. «Головы» задают вопросы по задаче. Их может быть разное количество: если задача человеку не знакома, то больше, если он специализируется на таких задачах, то меньше. «Головы» задают вопросы не только, чтобы выяснить детали задачи, но и для сверки ожиданий — убедиться, что у клиента и исполнителя совпадает видение результата. Конечно, когда автор давно с вами работает, вопросов становится меньше — он уже понимает, что спрашивать не у вас, а у эксперта, где ему дали полную информацию, а где что-то не учли, какая на проекте аудитория, какой нужен результат и так далее. Но в начале сотрудничества автор этого не знает, а значит, должен искать ответы. Отсутствие вопросов на старте сотрудничества — обычно признак «рук». Они получили задачу и уверены, что им все прописали, это ТЗ — бери и делай в рамках того, что написано. «Руки» задают вопросы, только если совсем чего-то не понимают.

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

*
Так, однажды я давала в тестовом задание задачу составить вопросы для кейса, чтобы получить недостающую информацию. Кейс был технический, специфический, нужны были не те вопросы, которые обычно задают, чтобы сделать кейс для какого-нибудь интернет-агентства. Но многие присылали стандартный бриф, а один автор написал около 50 вопросов, из которых 90% никак не помогли бы решить задачу — например, спрашивал про годовой оборот нашей компании.
*

🔥 4. «Головы» интересуются целью работы. Они уточняют такие детали: зачем нужен текст, почему в таком формате, почему вы считаете, что это важно, а это стоит убрать. Это не значит, что они будут спрашивать такое про каждый текст — подобных вопросов может не быть, если вы сами четко обозначили цель и исполнитель с ней согласен, понимает, что здесь так и нужно. Но если «голова» видит несоответствие между целью и тем, что просят сделать, то всегда спросит. «Руки» чаще всего не будут: сделают ровно то, что попросили.

🔥 5. «Головы» могут предлагать варианты решения задачи. Более того — обычно им это интересно. Если вы ищете таких людей, то в вакансии и тестовом задании надо показать, что ваш проект требует умения думать. Именно поэтому на старте лучше давать тестовое задание, близкое к реальной работе. Нужны люди, пишущие по четкому ТЗ — возьмите настоящее ТЗ на текст, пусть они пишут. Нужны те, кто умеет/пытается думать — сделайте тестовое таким, чтобы человек по максимуму включился в поиск решения.

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

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

Очень классный подход, чтобы уточнить цель задачи. Часто использую, когда нужно дописать что-то для уже существующего сценария.
По ходу разговора из формата часто выясняется либо размер текста, либо «ну, такое мы делать пока не умеем, хотим отъехать так-то». Сразу куча вариантов снимается.

​​Вот ты общаешься с заказчиком, или стейкхолдером (не люблю это слово), или ТЗ читаешь. В целом понял, но общая картинка задачи/цели/боли пока не сложилась. Или ты думаешь, что сложилась, но остались вопросы.

Разумная реакция: сформулировать вопросы, чтобы ответами закрыть свои белые пятна. Но что, если ты концептуально неверно понял задачу? В работе такие ситуации случаются сплошь и рядом. Иначе не было бы кучи мемов на тему: как написал аналитик, как запрограммировали, а вот что на самом деле хотел заказчик.

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

Когда проговариваешь своё понимание задачи, то оголяется сразу два момента:
1. Если не можешь связать задачу в нормальный рассказ — значит слабо понимаешь. Это будет видно сразу.
2. Если ты концептуально понял неверно, то вторая сторона тебя поправит и вы синхронизируетесь.

Вот например (весьма упрощённо):

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

Если я ставлю задачу (плюс-минус сложную или новую для человека), то всегда прошу: "Расскажи, как ты понял, что нужно сделать".

В общем, для понимания задачи лучше не вопросы формулировать, а для начала рассказать, как ты в целом её понял.

#совет

Двойной пробел! Запятая!
Доктор, кажется, у меня профдеформация. Даже в отпуске не отпускает.

В очередной раз рассказывала кому-то про User memory design, поняла, что и тут полезно было бы поделиться.

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

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

Когда-то давно я переводила с английского классную статью про эту тему. Рекомендую:)

А, ну и да, нужно добавить пиков в пост.
Пик-пик 🐣

Кто-то недавно спрашивал о ресурсах, где можно поучиться проводить интервью с пользователями. Ресурсы пока под руку не попались, но попался бесплатный вебинар от Михаила Правдина из Авито и Product Mindset. Завтра (18 марта) в 19:00 по Москве.
Сама не знаю, что там будет. Но если под руку попалось, почему бы не сходить?

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

Сходила вчера на вебинар про кастдев. Записала для себя несколько мыслей, делюсь с вами.

На исследование нужно приходить с гипотезой — без этого его проводить бесполезно.

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

Хорошие гипотезы:

- Атомарные
- В формулировке не должно быть ответа
- Не факт, а предположение («Выйду из дома — попаду на улицу» — не гипотеза)

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

Вопросы на исследовании:

- Не должны быть про будущее
- Открытые
- Не сложные и не длинные (респондент может забыть вторую часть, пока отвечает на первую)
- Без подсказок