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