Бриф продуктового дизайнера

Автор: Саша Окунев 1 апреля 2022 Уровень: для начинающих Фото: Martin Wilner

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

Это не просто статья, а рабочий инструмент сбора данных.

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

Эту страницу можно дублировать в твоё пространство в Notion

Оглавление

• Распаковка проекта
• Вопрос 1. Опишите проблему, которую мы решим интерфейсом
• Пример точно пойманной проблемы про список команд
• Плохое описание проблемы
• Вопрос 2. Как проблема влияет на весь бизнес-процесс?
• Хороший ответ
• Плохой ответ
• Вопрос 3. У кого есть эта проблема?
• Хороший ответ
• Плохой ответ
• Вопрос 4. Кто ещё вовлечён в общий процесс?
• Хороший ответ
• Вопрос 5. Есть ли похожие проекты, которые помогут решить задачу аналогично?
• Хороший ответ
• Вопрос 6. Какие сущности вовлечены в процесс?
• Вопрос 7. Как эта проблема решалась раньше?
• Хороший ответ
• Вопрос 8. Станет ли эта проблема более критичной в будущем?
• Хороший ответ из другого проекта
• Вопрос 9. Метрики. Какую количественную аналитику можно привязать к задаче?
• Примеры полезных цифр
• Вопрос 10. Как мы определим, что решили проблему?
• Хороший ответ
• Сойдёт
• Плохой ответ
• Список сценариев и их приоритеты
• Пример списка сценариев
• @UX

Распаковка проекта

Работа над любой крупной интерфейсной задачей начинается с ознакомительной встречи, на которой дизайнер обсуждает проект или задачу с заказчиком. В этой роли обычно ПМ или представитель бизнеса, который нуждается в хорошем дизайне. Цель встречи — выяснить проблему, которую можно решить дизайном.

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

Как фиксировать. Многие дизайнеры способны запоминать детали по ходу разговора, руками записывая их в стильные хипстерские блокнотики, но у меня такое никогда не работало. Бумага кончается, теряется и не имеет функции поиска. Поэтому, я целенаправленно отучил себя использовать бумагу для важных записей и перевёл все записи в Notion. Это позволяет фиксировать мельчайшие детали, которые никогда не теряются, а также постепенно выращивать из брифа целую документацию, меняя типы блоков, из которых состоит текст. Принятый стандартом в крупных компаниях Конфлюенс для этой цели не подходит, поскольку его интерфейс препятствует тому, чтобы фокусироваться на контенте и в нём в принципе нет деления на блоки. В нём вязнешь и постоянно сохраняешь страницы, вместо того, чтобы думать о задаче.

Если ты переживаешь, что Notion будет недоступен в России, переходи на Obsidian, он бесплатен и работает локально. Подробнее о нём — в видео Вити Теплова.

Пиши видео! Очень полезная привычка — вести видеозапись, даже если вы встречаетесь лично. В Zoom и Teams можно зайти во встречу с самим собой, включить запись экрана и аудио. Ну а при встрече онлайн запись это вопрос нажатия на одну кнопку. Позднее это позволит не переспрашивать вещи, которые уже говорили на первой встрече и сэкономит время заказчику.

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

Вопрос 1. Опишите проблему, которую мы решим интерфейсом

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

Пример точно пойманной проблемы про список команд

Мы разрабатываем дизайн-инструмент под названием «Figma». В нём можно создавать корпоративные аккаунты для организаций. В рамках такого аккаунта доступно пространство организации, где можно создавать команды. Приведём в пример организацию «Orange». В пространство можно добавлять сотрудников, которые могут вступать в команды. В командах хранятся проекты, а в проектах дизайн-макеты.

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

Команду может создать любой пользователь, который приглашён в пространство. Это приводит к тому, что кто-нибудь в очередной раз создаёт команду вроде «Алёша». Когда накапливается много таких именных команд, они начинают мешать остальным 300 пользователям в пространстве Orange находить важные команды. В нашем продукте нет возможности дать ссылку на конкретную команду.

Проблема 2 в том, что только оунер команды может удалить её после создания. У администратора Саши нет возможности просто удалить команду Алексея, поскольку Саша не является оунером.

Здесь есть хорошая логическая цепочка:

1. Любой может создавать команды →
2. Алёша и ещё 20 таких же команд раздувают список →
3. Людям приходится искать свою команду, и это сложно →
4. Тратят время, жалуются и злятся

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

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

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

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

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

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

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

Вопрос 2. Как проблема влияет на весь бизнес-процесс?

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

Хороший ответ

Проблема не является блокирующей для бизнеса Orange. Но сотрудники вступают в команды постоянно. Мы провели исследование-наблюдение на 15 респондентах из Orange. Оно выяснило, что на решение проблемы вступления в команду нужно примерно 5 минут во время рабочей встречи.

‣

Подробности: что происходит за это время

Участвуют две роли: тот, кто приглашает в команду, и тот, кто, получает приглашение.

• Сотруднику кидают ссылку на макет в Фигме через мессенджер
• Он понимает, что макет не открывается, но не понимает, почему
• Более опытный собеседник, обычно дизайнер, объясняет, что нужно вступить в команду, и тогда макет откроется. Даёт ссылку на figma.com, чтобы человек зашёл на страницу пространства
• Происходит болезненный поиск команды среди 50 других команд, свёрстанных карточками
• Сотрудник наконец находит команду глазами или через поиск, если название команды короткое и однозначное
• Возвращается в макет, обновляет страницу, макет открывается

Посчитаем, сколько времени потеряют сотрудники на вступление в команды на протяжении года. У нас 300 сотрудников и 50 команд. Предположим, что 1 сотрудник в течение года вступает в 10 проектов и тратит на это усреднённые 5 минут. Поскольку в процессе участвуют двое, удваиваем время. В этом случае только на одну компанию Orange получается 30 000 потраченных минут, что составляет 500 часов.

Можем привязать к этому показателю среднюю часовую зарплату сотрудника в IT-департаменте компании Orange и понять, сколько денег компания теряет на одном только непродуманном UX вступления в команду.

Представим, что средняя зарплата в Orange – 2 000 $. Это 50$ в час. Это значит, что игнорируя эту проблему, Orange будет терять 25 000 $ в год.

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

Плохой ответ

Мы не знаем, просто чувствуем, что надо это решать сейчас. Лично мне как продакту неудобно вступать в команды в этом рыхлом списке с карточками.

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

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

Вопрос 3. У кого есть эта проблема?

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

Вопрос 4. Кто ещё вовлечён в общий процесс?

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

Если ответа на этот вопрос нет, его можно пропустить.

Хороший ответ

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

Вопрос 5. Есть ли похожие проекты, которые помогут решить задачу аналогично?

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

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

Хороший ответ

В конкурирующем с Figma приложении можно сделать ссылку на команду. Это понижает важность списка команд и даёт возможность исключить шаг поиска.

Вопрос 6. Какие сущности вовлечены в процесс?

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

Вот как выглядит вся иерархия сущностей для нашего кейса с Orange:

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

Вопрос 7. Как эта проблема решалась раньше?

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

Хороший ответ

Администратор Саша наводил порядок в командах Orange вручную, делая рассылку всем создавшим мусорные команды, чтобы они удалили их и перенесли свои черновики в личное пространство. Тех, кто не ответил на рассылку, Саша удалял из Figma, сохраняя их файлы вручную. Ручная чистка команд занимает около 2 дней, но через некоторое время люди снова создают пустые команды, потому что могут.

Также можно было в принципе не чистить список и использовать поиск по названию команды.

Вопрос 8. Станет ли эта проблема более критичной в будущем?

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

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

Хороший ответ из другого проекта

Мы — соцсеть и в начале года мы планируем нанять армию модераторов, поскольку текущие не справляются. К концу декабря им нужно выкатить новую панель модерации с минимальным функционалом. Не будет панели — нанятые сотрудники будут работать в старой, которая для работы непригодна. Это приведёт к нашим колоссальным финансовым потерям и не даст осуществить глобальную бизнес-цель по ускорению модерации контента.

Вопрос 9. Метрики. Какую количественную аналитику можно привязать к задаче?

Для новых задач этот шаг можно пропустить, поскольку у нас ещё не может быть данных. Если же процесс уже существует, стремимся собрать полезные цифры о нём: сколько ежедневно, еженедельно и ежемесячно произведено действий по нему. Сколько людей вошли в команды в Orange?

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

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

Примеры полезных цифр

• Метрика 1 — Текущее количество пользователей в системе

— важная базовая метрика. Если у нас не 300, а 3 человека, может и не стоит ничего менять?

• Метрики 2 / 3 / 4 — Количество целевых действий за день / неделю / месяц

— поможет установить общую частоту вхождения людей в команды

• Метрика 5 — Среднее время выполнения действия

— поможет измерить исходное состояние в точке боли

• Метрика 6 — Количество жалоб на невозможность найти команду

— насколько недовольны наши люди?

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

Вопрос 10. Как мы определим, что решили проблему?

Определяем целевые признаки, которые через факты подскажут, что проблема устранена. В идеале ответ затрагивает исправление бизнес-процесса, а не само наличие новой функции. Сверяемся с вопросами 1 и 2.

Хороший ответ

Признаки:

• Факт из метрики: мы сократим время приглашения в команду с 5 до 1 минуты, экономим Orange 20 000 $ в год.
• Ответ от респондента: администратор Саша подтвердит на интервью, что теперь стало гораздо легче держать команды в порядке, поскольку он теперь может их удалять без привлечения создателей. Теперь он тратит на эту задачу не 2 дня, а 1 час.

В проверке решения лучше всего опираться на факты и проверяющие исследования. К сожалению, это не всегда возможно. На этапе становления дизайн-культуры в компании, дизайнер может находиться под давлением руководства, которое не заинтересовано в непонятных активностях вроде исследований.

Сойдёт

Признаки:

• Дадим администраторам возможность удалять любые команды, что ускорит уборку
• Дадим возможность делать ссылки на команды, чтобы их не искали в списке
• Сделаем список команд более компактным, расположим их названия в виде таблицы, чтобы можно было сканировать названия по вертикали

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

Плохой ответ

Нарисуем макет с кнопкой удаления команды.

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

Список сценариев и их приоритеты

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

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

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

Пример списка сценариев

Для решения задачи про список команд я бы выделил следующие сценарии:

1. Получение ссылки на команду зрителем

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

2. Команды в режиме списка

Обновляем дизайн страницы с командами, добавляем отображение списком, как у администраторов.

3. Удаление команды администратором

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

4. Восстановление команды оунером

Отыгрываем сценарий, если админ решил заняться вредительством. Сохраняем удалённые админом команды на протяжении 30 дней, за которые даём оунерам их восстановить.

5. Перенос команды в External teams оунером

Даём оунерам команд возможность переносить их из корпоративного пространства Orange в их личное бесплатное пространство External team, которое доступно каждому по корпоративной почте.

О сценариях будем более подробно говорить в следующих статьях этой серии.

Открыть канал

/designer — образовательный проект о продуктовом дизайне и инструментах для него. Об интерфейсах, карьере дизайнера и эмиграции

Наверх

UX