В мае рассказывала вам про то, что 2ГИС зарелизили фичу «Светофоры на карте», пока только в Москве.

На этом дело не закончилось и в этом месяце коллеги добавили «Разводные мосты» в Питере.

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

Как вам?)

❤️ — красота
🔥 — интересно
🤚 — захотелось в Питер, посмотреть вживую на разводные мосты

Аудит продукта

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

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

План, которого обычно я придерживаюсь:

1. Узнаю, кто пользователи, роли и особенности
2. Какие есть проблемы
3. Выясняю, как решают проблемы сейчас и закрывают ли их
4. Проверяю все основные флоу
5. Выписываю гипотезы, что может негативно влиять на продукт, а что положительно
6. Определяю, какие виды исследований стоит провести
7. Провожу эти исследования
8. Записываю все полученные инсайты и результаты
9. Рисую wireframe с изменениями, что и как должно выглядеть опираясь на результаты исследований
10. Рисую дизайны (если нужно)

Я вообще фанатка метрик и исследований, они помогают проектировать интерфейсы закрывающие потребности пользователей.

❤️ — интересно
🔥 — тоже фанат исследований
⭐️ — без них справляюсь

«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