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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#совет

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(продолжение)

Последняя тема с подсказками очень богатая. На исследованиях часто грешат вопросами-инструкциями, где нужно совершить целую серию действий. Нажмите на красную кнопку, проскроллите вниз, найдите иконку с шариком — как вам? Это больше похоже на инструкцию для FAQ, чем на вопрос или задачу в исследовании:)

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

Мне очень понравилась история про исследование Икеи, я даже заскринила слайд (в посте выше).

Если кто-то хочет посмотреть, держите запись.

#софтскиллы
Я сейчас полтора часа ржала.

Если вы хотя бы что-то одно из этого:
- много работаете
- очень увлечённо работаете и горите идеей
- перфекционист
- много требуете от себя
- после работы лежите тряпочкой
- давно не были в отпуске
- работаете с больничного и из отпуска
- боитесь за свои задачи или проекты в случае, если заболеете или уйдёте в отпуск
- часто болеете
- много пьёте алкоголь
- много едите

подумайте, не выгораете ли вы?

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

Опубликовала на Хабре статью, куда собрала результаты зарплатного опроса. Берите на заметку, если пойдёте повышаться или устраиваться UX-писателем (UX-редактором, продуктовым редактором или кем-то, кто выполняет схожие задачи).
И перешлите знакомым UX-писателям. Мы должны знать, сколько мы стоим!

#зарплатныйопрос

Закопалась во всяких диссертациях и статьях на тему когнитивной нагрузки. Кажется, нашла несколько интересных исследований с неочевидными выводами 🤓

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

🔸 Когнитивная нагрузка делает нас недоверчивыми
Суть: эксперимент проводили с помощью экономической игры в доверие. Правила сложно объяснить кратко, но суть такая: два человека меняются друг с другом деньгами. Сумму перевода они определяют сами, интуитивно или на основании действий оппонента.
Одну группу игроков просили запомнить сложный пароль, а второй не давали никакой дополнительной нагрузки.
Результат: те, кто не получал дополнительной нагрузки, вели себя рационально — их решения были логичным ответом на ход соперника. На щедрость отвечали щедростью, а если соперник хитрил — начинали меньше ему доверять.
А вот поведение людей, которые держали в голове пароль, было импульсивным и со стратегией соперника не совпадало. И вообще эти люди меньше доверяли оппоненту, жадничали и не хотели делиться деньгами.

🔸 Разметка мешает восприятию текста
Суть: в рамках исследования студентов просили прочитать два текста о глобальном потеплении. Один текст был размечен (в нем было содержание, подзаголовки, списки и т.д.), а другой нет.
Потом участникам давали тест на понимание информации. А еще просили оценить сложность текстов, мотивацию их читать и предположить, насколько успешно они справились с проверочным заданием.
Результат: студенты ожидаемо отметили, что размеченный текст читать проще и приятнее, а результаты теста будут отличными. Со сплошным текстом все наоборот: сложный, читать не хотелось, тест завалили.
Но реальные результаты оказались противоположными. Сплошной текст усвоили хорошо, в заданиях по нему почти не было ошибок. Результаты по тексту с разметкой были намного хуже. То есть разметка создает дополнительную нагрузку и отвлекает от содержания.
Выходит интересный парадокс: сплошной текст воспринимают лучше, но читать его не хотят. Поэтому, при всех недостатках, разметку лучше использовать.

Долго думала, что хотели сказать фразой «А мне парковать». Подозревала отсылку к «А мне наплевать».

К слову о важности пробелов и прочего оформления.

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

#софтскиллы

Про важность обратной связи.

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

Или на работе. Сделаешь фичу, чувствуешь потребность с кем-то посоветоваться, норм ли оно вообще. Кидаешь в чат с командой — а все молчат. И то ли всё хорошо, то ли плохо, то ли все запарились и не видят.

Давайте давать друг другу обратную связь.

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

1. Если вы в запаре, а кто-то от вас хочет что-то лично, скажите ему, когда вы сможете это посмотреть, чтобы не волновался.
2. Если вам от кого-то что-то нужно, кидайте не просто так, а с вводной, на что обратить внимание. Если это срочно — напишите, до какого момента обратная связь будет ещё актуальна.
3. Если вам что-то не нравится, скажите. Если человек пришёл к вам, значит, ваше мнение ему важно. Возможно, вы заметите какие-то детали, которые он пропустил.
4. Если вам всё нравится, говорите об этом. Вас за это никто не съест.
5. Если вам было полезно, говорите и об этом. Долой фрустрацию, давайте удовлетворять друг друга!:)

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

Последнее время в каждой второй (если не первой) статье Максима хоть в каком-то виде присутствует та же мысль, что задача редактора — не написать текст, а решить задачу клиента или читателя. А лучше обоих.
И вот этот подход очень откликается в моей работе UX-писателя. Мы стараемся делать так, чтобы пользователю было понятно, чтобы он выполнил свою задачу максимально быстро и бесшовно. И чтобы он потом вспомнил о нас и вернулся, когда у него будет такая же или похожая задача.

​​Найдёте текст ошибки?

​​#софтскиллы
Сходила на лекцию по психологии. Там была часть про важность выхода за рамки в генерации решений — очень часто самые простые решения оказываются самыми изящными.

Стащила оттуда эксперимент. Давайте потренируемся?

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

​​Первоапрельская (и третьеапрельская) шуточная рассылка от МИФа — лучшее, что побывало в моём инбоксе за последнее время!:)