Страница 12 из 14
• Сфера охвата: Для скольких пользователей мы разрабатываем дизайн? В каком окружении они находятся? Сколько существует проблем для работы?
• Приоритеты: Сколько времени мы должны выделить на каждый этап дизайн-процесса? Насколько «злой» должна быть проблема?
• Гибкость: Наращивание интенсивности определенного этапа задачи или процесса для того, чтобы участники приобрели углубленное понимание или навыки в данной области. Например, это может означать выделение большого количества времени на проведение интервью, чтобы подчеркнуть важность эмпатии, или вы можете потребовать определенное число итераций, чтобы сделать акцент на этапе прототипирования.
• Циклы: Хорошо будет провести несколько циклов эмпатии, постепенно увеличивая их продолжительность (то есть, начать с часового упражнения, потом отвести на это часть дня, целый день и т. д.)
• Команда: Поощряйте разнообразие в составе команды и планируйте, кого стоит добавить и на каком этапе (например, кого привлечь к мозговому штурму).
• Рабочая обстановка: Насколько комфортно окружение для участников? Всем ли хватает места, чтобы быть продуктивными? Есть ли материалы для записи и фиксирования идей? (стикеры, прототипы и т. д.)
• Доступ: У вас есть доступ к задаче? Как именно участники будут взаимодействовать с пользователями?
Понимание контекста процесса эмпатии
«Если вы что-то не можете объяснить шестилетнему ребенку, вы сами этого не понимаете».
Задача
Формулировка точки зрения на проблему – один из самых важных шагов в процессе дизайн-мышления, поскольку задает тон всему проекту и влияет на все последующие действия. Когда проект только представлен, проблема, которую предстоит решить, часто неочевидна или сформулирована слишком широко, чтобы с ней можно было справиться в отведенное на проект время. Хорошей идеей будет собрать как внутреннюю, так и внешнюю информацию, имеющую отношение к проблеме, которую команда пытается решить, чтобы прийти к собственным заключениям по поводу направленности проекта. Имея достаточно информации, можно заложить надежную основу для формулировки вашей ключевой точки зрения на проблему и приобрести глубокое понимание именно ваших пользователей, их характеристик и потребностей. Точка зрения должна быть убедительной и служить призывом к действию. Она также должна быть понятной и конкретной, чтобы можно было получить четкое представление о проблеме, требующей решения. Если точка зрения оформлена достаточно ясно и точно, найти подходящее решение для пользователя становится намного проще.
Часто много энергии тратится, чтобы скорее начать проект и двигаться в сторону поиска решения, вместо того, чтобы сконцентрироваться на самой ситуации. Точка зрения никогда не должна включать в себя ни конкретное решение, ни любые указания, как именно удовлетворить потребности пользователей. Вместо этого точка зрения должна давать вам и вашей команде простор для размышлений касательно возможных решений, которые выходят за рамки стандартных и меняют статус-кво. Вместо того, чтобы тратить энергию, спеша как можно скорее решить предполагаемую проблему, выделите время в самом начале, чтобы поместить проблему в контекст. В ходе проекта разумным будет рассмотреть ситуацию под разными углами зрения, прежде чем переходить к планированию и вносить ясность в вопрос, какую именно проблему команда пытается решить, а какие проблемы находятся вне зоны интересов. Вот что мы называем Точкой Зрения или POV. Это наш особый (и точный) взгляд на ситуацию или проблему. Хорошая точка зрения позволит генерировать идеи и решить поставленную проблему, не отклоняясь от главной цели и держа в фокусе внимания ваших пользователей, их потребности и найденные инсайты.
Решение
Начав с понимания контекста проблемы в рамках всей организации, команда должна совместно смоделировать ключевые факторы влияния (включая людей, товары, проекты, правила и процедуры и т. д.), связанные с их деятельностью. Составив карту взаимосвязей всех факторов с проектом и отметив, что каждый приобретает или теряет в результате их действий, команда получит представление об организационной среде проблемы и проекта. На этом этапе следует провести анализ угроз со стороны конкурентов (как внутри организации, так и за пределами), новых игроков на рынке и факторов влияния.
Если команда работает над продуктом или приложением, портфельный анализ может стать хорошим способом получить начальное представление, какие элементы составляют портфель продуктов, относящихся к определенной области. Это не только поможет избежать дублирования, но и выявит профильных экспертов или команды, которые могут пролить свет на проблемы и возможности, относящиеся к этой сфере. После того, как будут найдены профильные эксперты, проведите с ними интервью, чтобы перенять опыт и знание рынка. Узнайте, какие исследования они читали, к каким внешним экспертам обращались, определите и другие возможные источники информации, которые могут помочь команде.
Уже на этой ранней стадии полезно «включить голову». Создайте приблизительный прототип, чтобы поделиться знаниями и инсайтами, приобретенными в ходе сбора информации, со стейкхолдерами и членами команды. Это поможет определить сферу охвата проекта и сформировать единое понимание цели.
После выполнения этих действий команда должна получить приблизительный, но достоверный первоначальный анализ проблемы и уверенно начать движение к целям проекта. Возвращение на шаг назад и открытое обсуждение вопроса, а правильная ли проблема решается, – простое, но необходимое действие для помещения проблемы в контекст. Если данный процесс выполняется совместно всей командой, включая стейкхолдеров и главных спонсоров, вы сможете получить конструктивный результат, в отличие от случаев, когда только один человек ставит под сомнение направленность проекта.
Если у вас горят сроки, и вы не можете себе позволить поэтапное выполнение вышеописанных действий в течение длительного времени, вы можете создать воркшоп, посвященный определению проблемы. В таком случае команда получит возможность разрабатывать дизайн совместно со стейкхолдерами, чтобы завершить серию действий за несколько дней или неделю. Это поможет добавить новую информацию или избавиться от ненужной и приобрести лучшее понимание проблемы.
Выводы
• Команда придет к единому пониманию степени серьезности/незначительности проблемы.
• Будут определены внешние факторы, которые могут повлиять на оформление решения.
• Будут выявлены профильные эксперты и основные носители знаний.
• Будут вовлечены стейкхолдеры и определены их ожидания.
Стейкхолдеры
Проще говоря, стейкхлдеры – это группы людей или отдельные личности, которые либо могут оказать влияние на проект, либо сами подвержены влиянию с его стороны. Стейкхолдеры могут определить судьбу проекта, поэтому, вне зависимости от типа проекта, именно с ними вы должны считаться в первую очередь. Вы можете разделить стейкхолдеров на две группы – на заинтересованных в проекте и на имеющих возможность на него повлиять. Во многих случаях стейкхолдеры будут входить в обе группы, а в некоторых – ни в одну.
Существуют три основных группы стейкхолдеров: внутренние, связанные и внешние стейкхолдеры. Обычно внутренние стейкхолдеры уже являются частью организации, например, руководители или сотрудники. Связанные стейкхолдеры, которых также называют основными стейкхолдерами, – те, кто имеет эконмические или договорные отношения с организацией. Это клиенты, поставщики, ритейлеры, и т. д. Внешние стейкхолдеры не связаны напрямую с организацией, но могут быть в ней заинтересованы или подвержены ее влиянию. Например, правительство, медиа, общество и т. д.