JTBD-метод на практике для решения тестового задания
Привет! Меня зовут Николай, я дизайнер в билайне. Как-то раз для устройства на одну из работ на своем жизненном пути мне нужно было сделать тестовое задание. И в отличие от множества других тестовых, это было на самом деле интересным.
В посте я расскажу, как разбирался для решения этой задачи с методом JTBD (Jobs To Be Done), когда его стоит применять, что можно из этого выжать и причем тут вообще дизайн.
Тестовое
Для начала давайте сразу опишу, как именно выглядело тестовое и чего от меня хотели. Итак,
В течение жизни человеку делают множество прививок. Некоторые из них ставятся 1 раз за всю жизнь, некоторые нужно повторять по определённым схемам, с разной периодичностью.
Что нужно сделать
Описать логику своих действий для реализации сервиса.
Описать логику работы сервиса по отслеживанию прививок для пациента.
Подготовить прототип сервиса.
Отрисовать один экран UI
Предложить помимо целевого решения MVP.
Цель задания
Дать свое представление о сервисе: кому полезно, как может развиваться, какие решает проблемы.
Насколько детализированным должен быть прототип
На усмотрение исследователя. Обязательно приложить описательную часть, по которой можно увидеть ход мыслей исследователя и последовательность шагов.
Я обратился к принципам дизайн-мышления и разделил весь процесс на этапы вида:
Идеация (она же генерация идей)
Исследование
Поставка
Давайте подробнее о каждом из них.
Генерация идей
#1 Определим пользователей
Как обычно, сначала нужно (и это критично) понять, кто вообще будет пользоваться твоим приложением. В этом помогает анализ пользователей ближайших конкурентов. Я порылся в аппсторе, нашел, как мне показалось, самое популярное и близкое по теме приложение («Прививки — личный календарь») и пошел читать отзывы в App Store и Google Play.
Прочитав их (тут могла бы быть картинка с «Пятачок, неси ружье», но отзывы в порядке), я выделил несколько групп пользователей.
мамы с детьми (подгруппы — с детьми до двух лет и до 18 лет)
путешественники (нужно ставить прививки перед путешествиями в разные страны)
те, кто просто заботится о своем здоровье и, видимо, не дружит с антипрививочниками
медработники и студенты медицинских учебных заведений
#2 Выделяем боли пользователи
Тут всё просто — сортируем отзывы по рейтингу, находим самые частые проблемы. Это помогает сразу отметить для себя слабые места и при создании прототипа учитывать чужие грабли, а не собирать собственные.
#3 Определяем работы в формате Job Statement
Это классическая схема вида «Глагол, объект, контекст». То есть:
у пользователя есть «работа», которую надо сделать
сам продукт как сущность ему не нужен — ему нужно сделать свою жизнь лучше с помощью продукта
пользователь хочет развиваться
Учитывая все это, я сформировал ряд тезисов с действиями пользователей и контекстом использования.
Исследование
#4 Глубинное интервью
Это уже серьезнее, чем отзывы, тут нужна беседа с человеком, в идеале — личная. Я пригласил на интервью девушку, которая активно следила и за своим здоровьем, и за здоровьем всей семьи (муж и ребенок). Прививки ей были не в новинку, она часто ставила их ребенку, в общем, отличный представитель ЦА. И рассказала она много полезного.
#5 Job Stories
По сути это сценарии использовании в конкретных ситуациях, формата WHEN — WHAT — WHY (когда что-то происходит — я делаю вот так — для достижения вот таких целей).
Вот примеры.
Поставка
#6 Информационная архитектура продукта
Итак, я провел анализ результатов исследований и понял — люди хотят заходить в такую программу как со смартфона, так и с ПК. Так что пригодится и мобильное приложение, и полноценная веб-версия. Здесь можно провести опрос среди ЦА и выяснить — на шаге с MVP или MLVP сделать веб-версия ил приложение.
Можно ещё сначала разработать полноценный веб с мобильной версией сайта, а уже потом подтянуть версии для мобильных платформ, которые будут открывать сайт внутри приложения, это существенно экономит ресурсы.
Как бы то ни было, начать надо с составления требований и информационной архитектуры будущего приложения, не забыв учесть при этом все Job Stories и анализ конкурентов.
Потом уже можно переходить к прототипированию отдельных страниц.
#7 Прототипирование
Для примера я сделал прототип главной страницы приложения для iOS — он основывался на подобранных мною референсах (скрины экранов приложений для здоровья).
#8 Guerrilla testing
Оно же «рандомное тестирование». Я закинул идею приложения в своего знакомого и попросил его не стесняться и высказать мне всё, что он думает на этот счёт. Это помогает узнать, что вы могли пропустить в процессе и не учесть на каком-то из этапов.
#9 Правки и прототип
Что в итоге
Осталось лишь доработать прототип и провести тестирования, чтобы учесть все хотелки и боли пользователей. Если все ваши гипотезы оправдались (или нет, из чего вы сделали выводы), можно смело переходить к самому дизайну.
Главное тут — определить, что именно вы сразу тащите в MVP, а что — чуток полежит в беклоге, и вы вернетесь к этому позже. Так получится быстро стартовать, потому что иначе можно слишком сильно заиграться в перфекционизм, пытаться сразу выпустить идеальную версию продукта, а в итоге — не выпустить ее вообще. А вот потом уже, после старта, можно поэтапно улучшать работающую версию.
Если вы решали подобные задачи, напишите в комментах, пожалуйста — чтобы вы ещё добавили в процесс? Спасибо!
