«5 почему?»

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

Рассмотрим на вымышленной задаче.
Формируем проблему, которая у нас есть: «Люди оставляют мало чаевых доставщику пиццы в приложении после получения заказа».

«Почему люди не оставляют чаевые в приложении?»
Они не видят опцию.

«Почему они не видят опцию?»
Она плохо заметна.

«Почему она плохо заметна?» Находится в неудобном месте.

«Почему находится в неудобном месте?» Потому что не протестировали прототип, перед реализацией.

«Почему не проводилось тестирование?» Потому что у команды было ограниченно время.

Корневая причина: недостаточное внимание к UX из-за нехватки времени.

Как вам такой метод?

Серия постов «Инструменты проектирования».
Double Diamond ➡️

❤️ — полезно
⭐️ — сомнительно
🔥 — буду пробовать

Double Diamond

На прошлом месте работы прям нравилась эта методология нашему лиду и мы старались выстраивать процесс по Double Diamond (двойной алмаз). У нас не было UX-исследователей в командах и дизайнеры проводили исследования вместе с продактами.

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

Каждый алмаз делится на две части, в итоге получаем четыре этапа:

💎 Понимание проблемы

Discover — исследование, сбор информации. Здесь мы собираем все возможные инсайты и идеи (грани алмаза расширяются).

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

💎 Поиск решения

Develop — поиск различных решений, создание дизайнов (грани снова расширяются).

Deliver — выбор наилучшего решения и его реализация (грани снова сужаются).

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

Схему методологии в комменты кидаю 🖼️

❤️ — полезно

⬅️ 5 почему?
CJM (Customer Journey Map) ➡️

CJM

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

Это глобальная карта с точками контакта и эмоциями клиента от взаимодействия с продуктом. Рассмотрим на примере аренды авто.

Эмоции
😃 — хорошо
😐 — нормально
😟 — плохо
😡 — ужасно

У пользователя возникает задача: он хочет съездить в путешествие на выходные и ему нужно авто в каршеринг.

Точки контакта:

1-я. Он натыкается на рекламу сдачи авто в каршеринг в интернете. (эмоция 😃)

2-я. Скачивает приложение. Всё прошло отлично, быстро нашёл. (эмоция 😃)

3-я. Регистрируется: добавляет документы, фото и паспорт. Документы проверялись больше 2 часов. (эмоция 😐)

4-я. Привязывает карту для оплаты, привязалась быстро. (эмоция 😃)

5-я. Ищет авто. Долго не может найти подходящее рядом для брони. (эмоция 😟)

6-я. Проверяет авто на наличие царапин и забытых вещей после предыдущего арендатора. Минуты проверки не входят в стоимость аренды даются бесплатно. (эмоция 😃)

7-я. После путешествия нужно сфоткать машину и отправить фотки, чтобы подтвердить, что всё в порядке. Приложение тупило, фото не загрузились. (эмоция 😡)

8-я. Завершает аренду. (эмоция 😐)

Отсюда мы видим, что нужно улучшить на пути клиента: расширить количество авто для аренды и починить загрузку фото.

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

❤️ — полезно
⭐️ — не делал(а) CJM
🔥 — делал(а) CJM

⬅️ Double Diamond
Blueprint ➡️

Service Blueprint

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

Например, возьмём Озон, мы хотим сделать для него Service Blueprint. Рассмотрим, что важно нанести на чертёж:

Действия клиента — что делает клиент на каждом этапе: заходит на сайт, оформляет заказ и т.д.

Действия сотрудников — те, кто взаимодействуют с клиентом напрямую: продавец консультант выдаёт заказ; оператор колл-центра помогает, если есть вопросы.

Процессы — то, что клиент не видит, но это происходит: процесс сбора заказа на складе; процесс его доставки; процесс отгрузки товара в пункт выдачи.

Технические штуки — обработка заказа в системе; уведомление о том, что заказ пришёл.

Физические моменты — всё, что клиент видит: упаковка товар; внешний вид пункта выдачи; удобство примерочной.

Service Blueprint помогает найти слабые места внутри в процессах работы компании и в командах. Такой чертёж можно составить и когда только создаётся компания, чтобы понимать что и как будет работать в ней в будущем.

Пример чертежа кидаю в комменты

❤️ — полезно
⭐️ — не делал(а) Blueprint
🔥 — делал(а) Blueprint

⬅️ CJM
Jobs to Be Done ➡️

Jobs to Be Done

Завершаем серию постов и конец этой недели методологией Jobs to Be Done (JTBD).

У каждого из нас есть разные задачи, которые мы решаем каждый день от маленьких до больших. Методология JTBD называет их «работами» и каждый продукт, который мы используем, мы не просто используем, а как бы нанимает на выполнение этих «работ».

Дизайнеру как раз такой метод помогает понять, глубинную мотивацию пользователя и предложить хорошее решение. Шаблон по которому описывают «работу»(задачу пользователя) называют job story. Звучит он так: когда я [ситуация], я хочу [мотивация], чтобы [ожидаемый результат].

Ну и по классике рассмотрим на примерах «работ» для приложения Авито, например:

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

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

Попробуйте все из перечисленных в этой серии постов инструменты и продолжайте делать интерфейсы ориентированные на ваших пользователей 🖼️

❤️ — полезно
⭐️ — было интересно
🔥 — давай ещё какую-нибудь серию постов

⬅️ Service Blueprint

Книжный клуб

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

Я обычно прослушиваю аудиокниги во время других дел, поскольку читать физическую времени не хватает. Выбрали книгу «Мгновение ока» про путешествие во времени, мне понравилась. В 3-й главе, когда один герой рассказывал другому логику работы машины времени я прям почувствовала аналогию, как будто разработчик рассказывает про логику работы сделанной задачи, а тестировщик накидывает ему уточняющие кейсы, как это будет работать в определённой ситуации 😂
Ещё я вспомнила книгу Стивена Кинга «11/22/63», тоже о путешествии во времени и решила ее переслушать. Обычно в его книгах хоррор, но в этой прям приключение с невероятно крутым описанием Америки 1960-х годов.

Кто ещё состоит или состоял в подобном клубе делитесь? И вообще какие книги вы любите?)

❤️ — люблю слушать книги
🔥 — люблю читать книги
⭐️ — люблю, но нет времени на книги
🤚 — книги не моё

Пятничный словарь айтишника, давно его не было!

Синк

Нет, «синк» это не когда вы стали звездой на свадьбе друга, потому что к концу вечера успели хорошенько на синкаться 😄

Синк (от англ. sync — синхронизировать) — регулярная небольшая встреча с коллегами, на которой обсуждают текущие задачи. Обычно говорят так: «давай устроим синк!». Я, когда услышала впервые, решила, что будет какая-то вечеринка)

⬅️ Четвёртое слово

❤️ — знаю слово
🤚 — не знаю слово