В Usethics написали о том, как объединить подход персонажей и Jobs to be done

JTBD описывает потребности пользователя по формуле: когда X, я хочу Y, чтобы Z. «Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z).

Во подходе персонажей первое место занимает персонаж: как Х, я хочу Y, чтобы Z. «Как турист (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z)». Персонажи рассказывают о пользователях продукта, а «работы» сообщают об их ключевых целях.

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

У приложения-будильника ключевая работа — проснуться и встать вовремя. Используя JTBD, при редизайне мы не фиксируемся на конкретном решении в виде будильника. Человек может попросить другого человека разбудить или лечь спать заранее, чтобы проснуться самостоятельно и т.п.

Объединённый подход:

1. Выделяем типы пользователей. Думаем, какие индивидуальные особенности могут повлиять на их опыт выполнения работы (базовые шкалы свойств персонажей). Например: соседство с другими в спальне. Выдвигаем гипотезы о персонажах, но не наделяем их социально-демографическими характеристиками.

2. Проводим интервью, где оцениваем участников с точки зрения выделенных свойств, узнаём контекст, делим работу на составляющие («подработы»). Например: Подготовка ко сну → Планирование подъёма утром → Засыпание → Сон → Пробуждение → Подъём. Это не обязательно должна быть последовательность.

3. На интервью выясняем ключевые потребности и цели участника на каждом этапе. Важно, почему человек совершает те или иные действия.

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

5. Составляем карту пользовательского опыта для каждого персонажа. В ней могут быть слои опыта: цели/потребности, опасения, действия, барьеры, инструменты, эмоции.

6. Profit (выявляем инсайты о проектируемом продукте).

https://medium.com/usethics-doc/b35d4174cea3

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

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

Вылезаю, озираюсь по сторонам и понимаю, что забыла про то, что у меня есть я, а значит что-то кроме работы и профразвития.

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

А ещё знаете, вот это, когда у тебя в жизни (да какой там жизни, я про работу конечно) все изменилось до неузнаваемости, а ты ещё полгода рассказать ничего не можешь.
Ибо ну как же рассказать — а вдруг ничего в результате не получится? Или то что ты рассказываешь «как делаю», окажется ошибкой?
Надо историю сложить, осознать и отрефлексировать опыт, а потом рассказывать.


6 лет назад я начала свою карьеру как UX-исследователь. Саня называл это вагиней глубокой UX-аналитики.

С тех пор всё изменилось несколько раз. И всё имеет цикличность.
Только сейчас, спустя 6 лет, пришло осознание, почему роль одинокого(!) начинающего UX-исследователя в большой айтишной компании так сложна и часто обречена на провал.
Об этом подробно расскажу в следующий раз 😉

Инсайты + конкуренты

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

С юду действительно много пересечений, в частности они уже давно перешли на модель обратного аукциона, о которой я писал в самом начале (https://t.me/bukhtiyar/88). Поэтому многие процессы связанные с автоматизацией у них уже обкатаны и налажены.

Было интересно погружаться в процессы конкурентов, не один раз я восклицал — блин, это то что нам нужно! Поражался насколько схожи кейсы.
Да, правда говорят, что все уже придумано до нас. Но главное, это решить бизнес задачу, не так ли? А вот по бизнес метрикам все может быть не так однозначно, и в дальнейшем наши гениальные идеи не раз отвергались ребятами из профиру.

Давайте сравним юду и профиру.

Итак, я решил зарегистрироваться в профиру и юду в качестве дизайнера-фрилансера, давайте посмотрим, что из этого получилось (и не получилось).

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

И что бы вы думали?
У меня не получилось зарегистрироваться! Так как для регистрации в роли дизайнера необходим диплом о высшем образовании, карл! Я на свою работу устроился без диплома, потому что дизайнеру не нужен диплом! А знаете почему в профиру он нужен? Потому что по иерархии дизайн относится к IT сфере, куда в том числе входят и программисты, которым действительно важно иметь высшее образование, а правила для всей категории вакансий в сфере IT одинаковые, вот и получается, что дизайнеру нужен диплом.

Что же в случае с регистрацией в юду, то там совершенно противоположная ситуация — пускают всех подряд, можно войти просто через соцсети, сразу есть доступ ко всем заказам. Ко всему прочему тебе дают безлимит заявок на сутки. В итоге отозваться на заказ можно спустя 5 минут после того как ты решил стать спецом (при том, что даже не нужно скачивать отдельное приложение — все собрано в одном месте).

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

Очевидно, что истина где-то посередине.

У меня получалось быть молодым фрилансером. Как быть старым фрилансером?

У меня получалось быть молодым фрилансером. Как быть старым фрилансером?

Молодой фрилансер постоянно фигачит, учится, весь такой на подрыве.

Я всегда думал, что взросление обязательно связано с переключением в роль управленца — стать арт-директором или CTO, растить команду, учить, брать больше ответственности. «Солдат, что не мечтает стать генералом» казался мне неправильным. Ребят, которые попробовали руководить и откатились до исполнителей, я считал слабаками и дауншифтерами.

Но теперь я думаю, что это необязательно именно так. Ну то есть да, кто-то действительно тупо не затаскивает, но есть и другая штука.

Есть эффективность-продуктивность, а есть удовольствие от работы. Эти две ценности иногда конфликтуют. Не всегда — тут от человека зависит, от того, в каком личном мифе он живёт, какую он себе про себя рассказывает историю. Иногда продуктивность и удовольствие связываются в комплекс, но иногда нет.

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

А удовольствие от работы — это когда ты в потоке. Это когда сииидишь себе и делаешь штукенцию. И так её повернёшь, и эдак, и никто тебя не трогает, и не спрашивает, сколько процентов уже готово, и главное ты сам у себя это не спрашиваешь. Ты просто знаешь, кому она нужна и зачем, и ты её делаешь как-то, как ты сам хочешь.

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

Не знаю, об этом ли ты спрашивал — я как-то на себя больше спроецировал, ну и ладно.

Андрей Шапиро написал серию статей о методологии сбора требований и планирования релизов программного продукта User Story Mapping

Часть 1. Пользовательская история: https://medium.com/xraizor/b0b0d724d77e

Карта историй создаётся для нового продукта или когда существующий продукт надо частично или полностью переделать, и требуется описать объём имеющейся функциональности.

На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Хорошо, если есть картирование процессов в форматах Customer Journey Map или Service Blueprint.

На выходе: набор задач на проектирование и разработку, привязанных к пользовательским историям.

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

Любая пользовательская истории записывается для действующего лица: персоны или функциональной роли в системе. Близкая методика Use Cases лишена эмпатии к человеку, для которого создаётся программа.

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

Часть 2. Алгоритм проведения и рекомендации для ведущего: https://medium.com/xraizor/9a90beb2ff57

Часть 3. Чистка историй от ложных требований. Критика метода: https://medium.com/xraizor/2f7bd967a54a

Контекст пользователя

Контекст пользователя

Меня часто подкалывают, что я постоянно топлю за фокус на задаче, когда проектирую интерфейс. "Надоел ты, Леха со своими задачами. Поняли уже!", - говорят мне. А я то и рад, что у народа это на подкорку записалось. Но...

Помимо задачи пользователя, важен еще и контекст, с которым он к вам приходит. Выдерживает ли интерфейс этот контекст? Способны ли мы правильно "встретить" человека и провести по сценарию?

Пример

- Собираем карточку товара. Кладем сюда фото, сюда описание, а сюда кнопку "Купить". - Представим, что запущена реклама с коммуникацей про скидку.
- Предусмотрели ли мы состояние карточки под это? Заложили ли состояние, когда на фотках появляется бейдж с жирным скидоном? Можем ли этим гибко управлять? Или каждый раз делаем релиз под очередную акцию?

Понимание полного контекста пользователя коммуникациидают крепкое решение на выходе.

Рекомендации

Интернет маркетологи хорошо разбираются в аудитории, которую пригоняют в продукт. Ваша же задача - понять что эта за аудитория и что ей "пообещали" на шаге до. Засинхроньтесь с коллегами, узнайте кого именно и с какой коммуникацией привлекают. Учитывайте это в интерфейсе при проектировании. Так опыт пользователя будет бесшовным:

Увидел рекламу - считал сообщение/решение задачи - пришел с сообщением в интерфейс - решил задачу.

Практика

В своей работе мы часто используем сценарии пользователей. Вот реклама с такой коммуникацией, вот пользователь переходит на карточку товара, вот жмет кнопку "Купить". На первом этапе можно хоть из квадратов собрать, а потом уже дизайн под это рисовать.

Эта штука позволяет увидеть всю картину. Каждый шаг, мотивацию и целевое действие в конце. По итогу сборки сценариев всплывают штуки, про которые забыли. Думаете, шлифуете, выкатываете.

Итого

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