Намеренность и осознанность
Осознанность — вы знаете почему сделали именно так и можете это объяснить простыми словами.
Намеренность — каждое слово в презентации сказано с целью и наполнено смыслом.
Когда вы начнете тренироваться презентовать и будете слушать других кандидатов, вы довольно быстро поймете этот принцип. Удивительно, как часто кандидаты говорят что-то непонятное, просто ради того чтобы что-то сказать! Очень странное ощущение.
Решение и результат должны соответствовать сформулированной проблеме.
Звучит очень просто, но на презентациях с этим самые большие проблемы.
Сложности возникают уже на этапе формулирования проблемы — что же надо было решить?
Проблема должна быть сформулирована одним простым предложением.
Если хочется перечислить много задач/проблем, то это негативный сигнал — слушателю будет сложно вникнуть в суть. Каждая проблема может быть достойна детального разбора. Выберите одну и сфокусируйтесь на ней.
Самая распространенная ошибка — дизайнеры без прелюдий бросаются в пучину комментариев к макетам вместо того чтобы ввести в контекст и забывают обозначить проблему пользователей.
Комментарии без озвученного контекста понятны только самим кандидатам, но вызывают массу вопросов и непонимания у неподготовленного слушателя. Очень важно сформулировать проблему пользователя или бизнеса максимально простыми словами.
«Как пройти от дома до парка?» — простая и понятная формулировка проблемы. Например, это может быть проблема, которую решает дизайнер картографического сервиса.
«Слишком много ошибок в адресах при регистрации приводят к издержкам при доставке физического товара» — понятная проблема и бизнеса и пользователей.
Я надеюсь, что вам не придется сочинять задачу под готовое решение (к сожалению, такое встречается довольно часто). Опытный дизайнер скорее всего быстро рассмотрит такое искусственное подтягивание задачи под «то, что получилось». Если такое происходит — подумайте о причинах, может быть что-то из них можно указать среди ограничений проекта?
Если решение не соответствует задаче, то можно сделать вывод что осознанность отсутствует. Намеренности тоже нет — непонятно, как из макетов без задачи сделать вывод о работе дизайнера.
Если в презентации четко сформулирована проблема, были определены критерии успеха и решение наглядно показывает способ, который вы внедрили и проверили — скорее всего, это сильный индикатор осознанного подхода к дизайну.
Критерии успеха задачи
В примере с ошибочными адресами доставки критерием успеха будет снижение количества ошибок в указании адресов, и, как следствие — снижение издержек на неправильные доставки и может быть рост удовлетворения пользователей. Здесь эффект успешного изменения можно проверить массой способов — прямых и косвенных (начиная с количества неправильных доставок и заканчивая замерами NPS).
Если вы отчетливо понимаете задачу, у вас уже до начала работы над дизайном есть понимание критериев успеха задачи. Вы делаете набор действий и ожидаете что они приведут к изменениям там-то и там-то.
Например, после исследования пользователей или анализа данных у вас появляется гипотеза — если убрать два шага на форме, то конверсия в заполнения вырастет.
Критерием успеха будет считаться увеличение количества заполненных анкет.
Казалось бы, можно попробовать схитрить и сказать — вот, мы убрали количество шагов, задачей было сократить количество шагов, значит задача решена! Во-первых, это странная задача. Если у неё нет измеримого эффекта, то может быть это было напрасно потраченное время? Разработка денег стоит. Во-вторых, такая хитрость показывает либо непонимание замеров задач, либо отсутствие осознанности — вы что-то делали, но не знали зачем.
Критерием успеха или результатом не может быть наличие макетов или прототипов.
Макеты или прототипы так же не могут быть результатами. В продуктовой работе подразумевается, что результат — успешный или провальный — был как-то протестирован на пользователях.
Исключение, которое могу придумать, это когда макет сам по себе является продуктом — например, шаблон сайта. Если шаблон покупают и используют другие дизайнеры, то тогда макет может быть продуктом и результатом будет его использование на сайтах/приложениях.
Если задача пользователя, например — банковский перевод, то критерием успеха может быть ускорение перевода, увеличение количества переводов, снижение количества ошибок и т.п., которые были достигнуты благодаря, в том числе, вашей дизайнерской работе над макетами.
Простой способ проверить себя:
- Если хочется в формулировке критериев успеха что-то рассказать про макеты, то это ошибка.
- Если про метрики или изменение поведения пользователей — вы на верном пути.
Успехом может быть изменение в метриках или поведении пользователей (его тоже можно измерить).
В редких задачах отсутствие изменения в метриках может считаться успехом. Стратегические редизайны, которые не нарушили привычки пользователей и не обрушили метрики. Такие редизайны обычно решают технические задачи. Например, стоимость разработки из-за устаревшей кодовой базы занимает в три раза больше времени, чем пилот на новом фреймворке. А он требует другого подхода к организации компонентов. Переделали, метрики остались на прежнем уровне — отлично. Если вы принимали участие в таких проектах, то, во-первых, хочу вас обнять, во-вторых, вы и сами хорошо понимаете разницу, поздравляю!
Негативные результаты могут быть хорошими кейсами на презентации!
Например, количество проверенных гипотез (даже провальных) может работать в плюс. Для некоторых компаний дешевизна и скорость проверки гипотез будет преимуществом (стартапы на ранней стадии или компании с культурой тестирования).
Отличное видео (на английском) о культуре тестирования: Wyatt Jenkins, Seriously Advanced A/B Testing