3 полезности для дизайнера, упрощающие коммуникацию в команде или с заказчиком

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

Кстати, меня зовут Даша, я продуктовый дизайнер в Авито. Работа. А ещё я занимаюсь проектами в строительной/промышленной сферах.
Если коротко, тут про:

Это маршрут пользователя на пути к главной цели. А если еще короче – схема проекта. К моему удивлению, в большом количестве команд, к которым я присоединялась, отсутствовала такая схема. Рассмотрим, зачем тратить на это время и чем полезен путь пользователя для разных ролей в продуктовой команде.

Продуктовые менеджеры:

- Начинают лучше понимать ВЕСЬ процесс, а не кусок, который улучшается.

- Легче придумываются новые фичи/улучшения или наоборот помогает урезать функционал.

- Сохранение консистентности функционала (и визуала) за счёт того, что виден весь продукт.

Разработчики:

- Ребята могут оценить всю архитектуру проекта и распланировать работу.
- Помогает расписать все возможные технические ошибки (обычно их забывают фиксировать или пропускают специфичные).

Дизайн команда:

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

Как делаю я

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

Если дизайн еще не готов, то можно применить готовые Wireframe. Вот пример из Figma Community. А еще, можно использовать схему как индикатор готового UI, постоянно заменяя wireframe.

Как делают другие

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

В офигенской книге Скотта Херфа "Как создать продукт, который полюбят" описаны процессы составления flow в разных командах. За пример взят опыт продуктовых дизайнеров Basecamp, Canary, Care, LinkedIn и других.

Некоторые команды используют обычные текстовые редакторы - IA Writter, TextEdit. Ребята относятся к процессу проектирования как к рассказу друзьям о сценарии. Ограничение схемы только словами помогает не углубляться в UI и уделять внимание именно процессу.

Джон Траутман (сооснователь и главный креативный директор Canary) рекомендует TextEdit. Там он подробно описывает, какой функционал должен быть на конкретном экране. А далее команда превращает набросок в постраничную HTML-схему (наиболее банальный и актуальный способ сейчас - создание прототипов в Figma). Кликая по страницам, команда понимает какие действия помогают пользователям добиться своей цели и можно ли сократить их количество.

Менеджер продуктов Care Кейтин Фридсон рассказывает об использовании блочной карты сценариев. Такие блоки с заголовками и стрелками особенно хорошо помогают, когда предстоят интеграции с другими сервисами.
Я использовала такую, когда рисовала продукт для юридических лиц в Сбере.

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

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

Чем круто:

- У заказчика остается видео, которое он может посмотреть в любой момент.

- Можно смотреть с любого устройства.

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

- Для этого не требуется отдельное ПО (На MacOS сочетание клавиш Shift, Command и 5. И не забудьте выбрать в параметрах использование звука микрофона).

А ещё

Так можно записывать короткие туториалы разработчикам (например, по использованию функционала Figma).

Нюанс

Вы не сможете активно защитить своё решение. Этот способ подходит для мелких фич или уже утвержденного ранее функционала.

Представим, что вам написал новый заказчик. Возможно, у него даже есть ТЗ. Но скорее всего нет. Референсов точно нет или они не подходят под контент и уровень графики, который есть у заказчика.

Недавно я привела в порядок свои доски на Pinterest. Теперь их названия отражают тот элемент, который я хочу использовать. Например, "Landing page" или "Карточки" размещены на отдельных досках. Это выглядит удобно и структурировано.

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

Чем круто:

- Заказчик выбирает из UI, который отобрала я сама, а значит не будет неадекватных вариантов.

- У него появится понимание какие концепты ждать от дизайнера.

- Сразу определяемся со стилистикой и можем взять ее за основу.

- Формируем хороший вкус у клиента, если его нет, естественно (хотя бы на время нашего проекта 🙂).

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

Благодаря таким обсуждениям, я быстро поняла что хочет клиент и сделала большое количество набросков.

Нюанс

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

Познакомиться со мной можно тут 🌝
Telega: DashaVd