Как мы карту фокусов рисовали

Перед тем как рассказать, что такое карта фокусов и зачем она нужна, представим две ситуации.

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

2. Обычная ситуация в студии. Погружаем проектировщика в новый проект и на выходе получаем макеты. Он очень старался и думает, что нарисовал единственно возможный вариант. Но проверить жизнеспособность этих картинок проблематично.

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

Проблема в том, что каждый участник процесса видит продукт по-своему. Заказчика волнует выполнение бизнес-требований, маркетологам подавай поп-апы на весь экран со скидкой, разработчикам важно удобство реализации.

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

Если описать сервис в фокусах и в сценариях, любой новый человек сможет увидеть картину в целом, не погружаясь глубоко в детали.

В первом примере с почтой таким фокусом будет список сообщений, в гугл-поиске — сам поиск.

Перечисляя основные фокусы, можно уяснить суть продукта в целом, понять сценарии взаимодействия. Это касается и простых, и сложных продуктов.

Именно поэтому в «Собаке Павловой» начинают работу с карты фокусов, где отражены основные требования бизнеса и пользователя.

Фокус появляется из требований бизнеса или «хотелок» пользователя.
Например, при разработке банковского приложения сформулировано требование:

Через какие фокусы можно решить этот запрос? Можно сделать дашборд или страницу с правилами работы — или дать ссылку на документы.

Этот список фокусов уже дает общую картину продукта, хотя четкой структуры здесь пока нет.

Нарисуем карту фокусов для банковского приложения, которое может делать транзакции и с фиатом, и с криптовалютой. Обычное такое банковское приложение, которое может еще биткойны менять.

С безопасностью в этом приложении все серьезно. Процесс верификации пользователя очень долгий (более 20 вопросов) и сопровождается видеоидентификацией. Процесс верификации обязательно должен происходить в вебе (такие вот требования): человек заходит на посадочную страницу приложения, кликает на кнопку «Зарегистрироваться» и проходит долгий процесс верификации и видеоидентификации. В случае успеха ему присылают пароли для входа в мобильное приложение. Да, стать клиентом банка может не каждый.

У нас уже есть три фокуса: посадочная страница, верификация и видеоидентификация. Пока не смотрим в таблицы в Airtable — там зафиксированы не все требования, а только основные. Не забываем, что у нас две среды: веб и мобильник. Причем веб включает в себя ограниченную функциональность мобайла.

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

Если у вас перед глазами было иерархическое дерево, это нормально. Можно и так рисовать, но иерархическое представление информации — это лишь один из способов. Иерархия сразу задает жесткую структуру, а нам надо пробуждать воображение!

Также продукт должны переводить на немецкий. Глянем в документацию — там описаны крупными мазками интерфейсные элементы (спасибо менеджерам). Добавляем и их.

Интерфейсные элементы обозначены, но связи между ними непонятны. Глянем, как построены связи у конкурентов. Смотрим и банковские приложения, и криптовые.

Про поддержку чатом совсем забыла.

Подшлифовываем внешний вид — розовый никому не нравится. Редактируем связи: дашборд явно важнее, чем история.

Теперь картина вырисовывается. Сразу понятно: с главной (дашборда) можно зайти в историю, в поддержку и в настройки, а также посмотреть свой баланс, в один клик перейти на вывод средств и т. д.

Показала результат коллегам — и обнаружила, что неправильно понимала продукт. Хе-хе. В вебе только процессы регистрации. Сам продукт — это просто мобильное приложение.

Все переделываем в связи с просветлением. И вот здесь-то карта фокусов оказывается очень кстати.

Фокусом могут стать также постоянные контролы, например смена языка или уведомления.

Карте для ясности не хватает легенды. Добавим сценарии — так разработчикам будет лучше понятна логика.

Даже если никто потом на карту не посмотрит, ее составитель получит более целостное представление о продукте. Когда я делала банковское приложение, карта фокусов всегда была у меня в Sketch’е перед глазами.

Карта никак вас не ограничивает, она лишь помогает начать проектировать с нуля, описывая картину в целом.