Схемы для небольших быстрых задач

Привет-привет! Давно не писал про повседневную работу с фичами. И вот вам немного финтеха.

Задача 1. Интеграция внешнего продукта

В начале года к нам в dsx.uk пришел основатель продукта Nordic Crypto. Это торговый робот, которому можно дать денежку и он будет работать на бирже за тебя. Ребятам из этого продукта хотелось интегрироваться с dsx.

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

В чем сложность?

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

Как разрисовать логику этого продукта и построить интеграцию с ним, чтобы мне, разработчикам и пользователям было все понятно?

У меня есть мой мутировавший CJM, он тут не подходит, слишком громоздкий.

Про него можно почитать здесь.

Рисуем схему

Выбираем главные задачи

Наверху я показал основные наши задачи:

1. Известить пользователя. Это часто упускают в фичах и пользователи потом их могут игнорировать.
2. Убедить пользователя использовать робота. Никто просто так не доверит свои деньги софту. Нужно показать, что это безопасно и прибыльно, получить доверие.
3. Помочь настроить робота. Задать валютные пары, указать что делать с прибылью (реинвестировать или выводить), показать нормальный читаемый дисклеймер, а не с простыню мелкого текста.
4. Помочь использовать и "подкручивать" робота. Проверять, все ли в порядке, менять настройки вслед за меняющимся рынком, выводить/реинвестировать прибыль.

Детализируем

Я хочу понять, что нужно для решения каждой задачи. И перечисляю истории/контексты

Разделяем на экраны

Что потом? Нужно определиться, какие экраны потребуются для этих историй.

Некоторые сложные экраны (или те, у которых нужно ТЗ для написания контента) я немного детализирую, указываю их основные блоки.

Что делать после такой схемы?

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

Что дает такая схема?

• Мы постоянно держим перед глазами желаемый опыт пользователя (шаги наверху)
• Мы четко разложили по каждому шагу, какие сценарии, какие отдельные контексты и пр. в нем нужны
• Мы понимаем, какие экраны нам потребуются
• Можно отойти от этой задачи хоть на два месяца и к ней будет легко вернуться
• Можно делать эту задачу хоть по 10 минут в день и она будет двигать, не будет долго вникания в контекст задачи каждый раз
• Задачу можно легче делегировать (но без общения обойтись все равно не получится, на схеме недостаточно данных для чисто письменной передачи)
• Твое решение будет очень понятным для разработчиков, при условии, что они в курсе задачи в целом и понимают, какую проблему мы пытаемся решить
• В любой момент можно свериться "не фигню ли я делаю" и понять, что осталось сделать
• Можно легко "нырять" в любую мелкую деталь, не надо держать в голове всю инфу про фичу, она есть на схеме
• Схемка делается быстро и легко, отлично подходит для сравнительно мелких, но не очень простых фичей
• Легче работать с несколькими фичами, легче получать фидбек от команды/менеджмента/заказчика и пр.

Что еще можно почитать про подобные схемы:

• Хороший и ёмкий мануал от издательства "Питер". (Правда они, зачем-то потрудились перевести userstory mapping как "визуализацию функционала" =)
• Переводное введение в сторимэппинг;
• Статья о том, как построить сторимэп, если проект уже в работе;

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Задача 2. Светлая сторона браузерных пуш-уведомлений

Все ненавидят новостные сайты за попап "включите уведомления". Но есть и хорошие кейсы, где уведомления оправданы. У нас как раз тот случай :)

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

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

В итоге мы нашли много сценариев, в которых пользователю пригодятся пуш-уведомления от браузера. Экран с запросом "можно мы тебе сообщим?" — простейший. Но в каждом сценарии нужен свой текст, для нормальной конверсии. Сценариев много. Как объяснить разработчикам и копирайтерам, где какой текст нужен?

Рисуем схему каждого сценария

Чеклист:

1. Пишем список сценариев, в которых будем просить пользователя включить пуши. Их получилось семь.
2. В каждом сценарии показываем основные ветки (когда просим включить, что делаем если соглашается, что делаем при отказе)
3. Пишем подробный текст приглашений для каждого сценария
4. Бинго, можно рисовать экраны, а разработчикам понятно, как в целом все устроено и они уже могут кодить.

- - - - - - - - - - - - - - -

Хочется научиться в схемы? Приходи в мой индивидуальный менторинг:)

• Задать вопросы и записаться на менторинг: @ivanuxboost (телеграм)
• Записаться на бесплатный вебинар о навыках продуктового дизайнера