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

Ещё перед началом исследования важно понять, что вы будете делать с результатами. От этого зависит, какие инструменты выбрать для составления отчёта, и сколько на него тратить времени.

Выбор зависит:
— От запроса команды. Какую потребность исследование должно закрыть?
— Отношения к исследованиям. Надо ли убедить команду в надёжности выводов?
— Особенностей продукта. Это прототип или готовый продукт?
— Связи исследователя с командой. Продолжите ли вы работать вместе после окончания исследования?

Юлия рассмотрела плюсы и минусы 4 основных инструментов и сделала выводы, для каких исследований они подходят:

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

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

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

4. Word или Google Документы. Подходит, когда не нужны рекомендации по изменениям, а нужны только факты по результатам исследования (например, перечень проблем, с которыми столкнулись пользователи). Отчёт в таком формате легко оформить.

https://medium.com/julie.kozhukhova/284673aa2b6e

Безусловная и непонятная директива

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

Это — безусловная и непонятная директива. Такими директивами обычно общаются непродуктивные ребята, когда приходят с решениями вместо проблем (см. Фичреквесты, которые не стоит выполнять (https://t.me/pmdaily/98)).

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

Будьте подробными: рассказывайте о том, почему пришли к тем или иным решениям. Не «давай перенесём кнопку наверх», а «Эта кнопка — ключевой call-to-action на странице, а я боюсь, что новые пользователи сразу её не увидят» Так вы не только уменьшите количество переписки в трекере, но ещё и опытом с коллегами поделитесь.

Кратко про решение

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

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

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

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

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

Идеальное решение, когда инструмент сделает всю работу сам: сфотографирует, укажет геопозицию, поможет определиться с классификацией проблемы, чтобы пользователю осталось только добавить краткий комментарий.
Как сделать все эти шаги минимальными усилиями... конечно же при помощи дополненной реальности!
Наводим камеру на неправильно припаркованный автомобиль, ставим виртуальный пин, тем самым указываем точное местоположение проблемы, камера телефона угадывает, что это автомобиль, предполагает доступные варианты ошибок: при этом пользователь не видит огромный чеклист всех возможных вариантов, а лишь один или парочку близких по смыслу категорий; пользователь выбирает подходящую ошибку тапая по экрану.
Таким образом, после выбора нужной категории ошибки, телефон уже знает её геопозицию, автоматически делает фотографию и помогает определиться с категорией, то есть 3 из 4 обязательных шагов заполняются автоматически. Пользователю остается только написать комментарий к ошибке, а ещё лучше, сказать его голосом.
За счет того, что большую часть нагрузки берет на себя телефон, всё внимание наблюдателя может быть сосредоточено на исследуемой улице.

Но что делать с проблемами, которые не укажешь одной только точкой? Например, отсутствие тротуара на протяжении всей улицы, или область с повышенным трафиком пешеходов?

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

Хорошая проектная практика

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

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

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

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

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

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

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

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

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

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

Денис Бесков написал о Customer Development (в том виде, в котором подход разработал Стив Бланк).

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

  1. Поиск клиентов. Разработка и проверка гипотез о своих клиентах и их проблемах.
  2. Верификация. Проверка, что клиенты готовы платить за избавление от найденых проблем и что команда способна предложить решение.
  3. Масштабирование.
  4. Построение компании.

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

Product-market fit — ситуация, когда нашлась значимая проблема, за избавление от которой клиент готов платить, и есть решение, как это сделать. После этого решение можно масштабировать.

Если появилась идея продукта:

  1. Предварительно оцените объём рынка. Он должен быть достаточно большим для будущей компании.
  2. Сформируйте гипотезы о целевой аудитории продукта, в ходе какой деятельности у людей возникают проблемы, которые может решить продукт, что это за проблемы.
  3. Проведите глубинные интервью с представителями целевой аудитории, чтобы подтвердить гипотезы.
  4. По результатам интервью уточните гипотезы.
  5. Проведите количественные исследования, чтобы уточнить объём рынка для каждого сочетания проблемы и сегмента целевой аудитории.
  6. Выберите проблему с самым большим рынком.
  7. Создайте ценностное предложение и проверьте его «решенческим интервью» и последующей продажей.
  8. Создайте решение, с помощью которого вы в ручном или полуавтоматическом режиме сдержите данное клиенту обещание. На этом шаге оказание услуги может быть нерентабельным, это нормально.
  9. Окажите некоторый объём услуг в ручном режиме, чтобы проверить, получается ли сделать клиентов довольными, и заодно узнать о сложностях и подводных камнях.
  10. Если клиенты недовольны, ищите другие решения. Если попробовали все возможные решения, возвращайтесь к ценностному предложению и выбору проблемы.
  11. Если клиенты довольны, проанализируйте алгоритм выполнения услуги и определите, что можно автоматизировать.
  12. Оцените затраты на оказание услуги с учётом будущей автоматизации и стоимость привлечения клиентов в разных рекламных каналах. Поймите, получается ли зарабатывать на отдельной услуге. Это сейчас называют юнит-экономикой.
  13. Если экономика не сходится, ищите способ изменить проблемный показатель. Если не получается, пересматривайте решение или возвращайтесь на более ранние этапы.
  14. Если экономика сходится, можно разрабатывать первую версию продукта и далее переходить к построению компании.

На основе Customer Development Эрик Рис придумал Lean Startup — упрощённый подход к созданию стартапов.

Core Protocols 2

На прошлой неделе я начал писать про Core Protocols и мы посмотрели на список Core Commitments. Если вы пропустили пост и не понимаете, о чем вообще речь, можете вернуться вот к этому посту — https://t.me/designgest/377.

Сегодня хочется перейти к самим протоколам. Но не хочется пересказывать 100% того, что вы и сами можете прочитать в статьях и книжках, а хочется подсветить части протоколов, которые кажутся наиболее интересными.

И первый протокол, о котором хочется поговорить — Check In.

Чек-ин чаще всего используется в начале встречи рабочей группы. Цель чек-ина — в заранее определенной форме поделиться мыслями и эмоциями по поводу ситуации, проекта, задачи с другими членами команды.

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

Чек-ин протокол предлагает простую схему для изложения чувств, он предлагает использовать всего 4 основные эмоции (напишу их на английском, чтобы у вас потом не было путаницы, если пойдете читать книгу):

GLAD (радость)
SAD (грусть)
MAD (бешенство)
AFRAID (испуг).

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

Плюс комбинацией этих базовых эмоций можно получать описание более сложных эмоций. Так например, EXCITEMENT = GLAD + AFRAID.

Стандартные правила для чек-ина следующие:
1) высказывать свои чувства без оценки и цензуры. Можно объяснить причину, по которой вы испытываете конкретные эмоции. Нельзя преуменьшать свои эмоции, говоря, например: «немного грустно».
2) нужно говорить только о своих эмоциях
3) с уважением слушать чек-ины других
4) не обсуждать и не ссылаться на чек-ины других, если нет явного приглашения для этого.

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

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