Хочешь, чтобы тебе поставили корректную дизайн-задачу? Помоги продакту ее поставить

Однажды в деревне мой дядя Слава спросил, чем я занимаюсь. Большой, мол, уже, 25 лет. Должен же чем-то заниматься. Я ответил, что работаю в Москве дизайнером мобильных приложений. Он кивнул и помолчал с полминуты. Потом переспросил: «Так это значит… в телефоне там все… рисуешь?» «Да», — говорю, чтобы не распространяться. Он достает из кармана кнопочную Nokia и протягивает ее мне — мол, давай, показывай, что ты из этого нарисовал. Вот эту иконку «сообщения» или ту, с телефонным справочником?

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

Как же сделать так, чтобы задачи от продакт-менеджеров принимали вид «я хочу увеличить Retention нашего раздела, давай подумаем как это сделать», без «подвинь эту кнопку вправо» и «сделай зеленый зеленее»?

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

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

Первый этап. Пользователь

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

Спросите у продакта:

1. Как пользователь решает эту задачу сейчас?
2. Какой результат для пользователя мы хотим получить?

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

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

Второй этап. Бизнес

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

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

Спросите у продакта:

1. Давай представим, что все сработало идеально. Чего мы тогда достигли? Как это отразилось на бизнесе?
2. Сколько это в цифрах?

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

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

Третий этап. Что происходит с продуктом?

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

Но чаще всего ответы ближе, чем кажутся — у продакта. Спросите его, и он сам всё расскажет:

1. Кто наши конкуренты?
2. Где можно посмотреть продуктовую аналитику? Где можно взять события метрики?
3. Проводились ли какие-то качественные или количественные исследования? Где их можно посмотреть?

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

Четвертый этап. Сроки

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

Спросите у продакта:

1. Когда хотим в продакшен?
2. Когда должен быть готов дизайн?
3. Насколько это жёсткие сроки? Можно ли их двигать?

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

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

Пятый этап. Технические особенности

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

Спросите у продакта:

1. На какие фронты хотим раскатить фичу? Веб, мобилка, другие фронты?
2. Есть ли какие-то технические ограничения, о которых мне стоит знать?
3. Если процесс дорабатывается, то как посмотреть существующий процесс? Есть ли тестовые данные?
4. Если уже есть бэк, то есть ли документация ответов?
5. Можем ли мы менять бэк?

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

Контакты

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

Спросите у продакта:

1. У кого можно узнать специфику продукта? Его продуктовые особенности? Особенности системы?
2. Как достучаться до этих людей? Почта/телеграм/вотсап?
3. С кем внутри команды согласовывать драфты дизайна?
4. Как лучше согласовывать решение? Встреча? Письмо? Другое?

А теперь просто опросник, сохраните себе его и используйте как скрипт разговора, когда вам ставят задачу.

Пользователь

1. Как пользователь решает задачу сейчас?
2. Какой результат мы хотим получить для пользователя?

Продукт

1. Чего мы хотим достичь?
2. Сколько это в цифрах?
3. Кто наши конкуренты?
4. Где можно посмотреть продуктовую аналитику? Где можно взять события?
5. Проводились ли какие то качественные или количественные исследования? Где их можно посмотреть?

Сроки

1. Когда хотим в прод?
2. Когда дизайн должен быть готов?
3. Сроки жёсткие? Есть ли возможность их двигать?

Технические ограничения

1. На какие фронты хотим раскатить фичу? Веб, мобилка?
2. Есть ли какие-то технические ограничения, о которых вам стоит знать?
3. Если процесс дорабатывается, то как посмотреть существующий процесс? Есть ли тестовые данные?
4. Если уже есть бэк, то есть ли документация ответов?
5. Можем ли мы менять бэк?

Коммуникация

1. У кого можно узнать специфику продукта? Его продуктовые особенности? Особенности системы?
2. Как достучаться до этих людей? Почта/телеграм/вотсап?
3. С кем внутри команды согласовывать драфты дизайна?
4. Как лучше согласовывать решение? Встреча? Письмо? Другое?