Формулировка проблемы и проектного вызова

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

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

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

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

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

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

Пользовательская проблема обычно отвечает на четыре вопроса:

1. Кто сталкивается с трудностью?
2. Что именно вызывает затруднение?
3. В какой ситуации это происходит?
4. Почему это важно для пользователя?

Если на поставленные вопросы нет однозначного ответа, то проблема, вероятно, сформулирована слишком обобщенно или недостаточно глубоко.

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

Например, студент жалуется: «Всегда срываю дедлайны». Это может указывать на наличие каких-то проблем. За этим поведением могут скрываться различные трудности, студент не до конца понимает требования задания, получает информацию разрозненно, не умеет планировать и оценивать объем работы, испытывает страх перед началом из-за неуверенности или не видит, как данное задание связано с итоговым проектом.

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

Например:

Симптом: студент забывает о дедлайнах.

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

Возможная потребность: видеть понятную систему задач и сроков в одном месте.

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

К примеру, факт может быть сформулирован как: «студент фиксирует задания в блокноте». Пользователь же может заявить: «Я вроде всё записываю, но все равно забываю о них». А ключевым моментом (инсайтом) может стать то, что студенту необходимо не просто записать задание, а осознать его место в контексте сроков, приоритетов и общей нагрузки.

Хороший инсайт обычно:

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

Инсайт можно формулировать через конструкцию:

Пользователь хочет / пытается / нуждается в…, но ему мешает…, потому что…

Например:

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

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

Слишком обобщённое определение: «Студентам сложно учиться»

Неясно, для каких студентов какие именно сложности возникают, в каких ситуациях и по какой причине.

Формулировка слишком ограничена: «Студентам необходимо приложение, которое будет содержать календарь дедлайнов»

В данном случае проблема решена готовым решением.

Более точный вариант формулировки: «Студентам первого курса бывает трудно организовать учебные задания по срокам, поскольку информация поступает из различных источников и не образует единой системы приоритетов»

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

Можно использовать шаблон:

[Кому] сложно [что сделать] в ситуации [какой], потому что [причина / барьер]. Это приводит к [последствие].

Пример:

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

Если мы поможем пользователю [действие / изменение], то он сможет [ожидаемый результат], потому что [связь с потребностью].

Пример: «Если мы поможем студентам видеть задания, сроки и приоритеты в одном понятном формате, то им будет проще распределять учебную нагрузку в течение недели, потому что они смогут заранее оценивать объём работы и планировать действия»

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

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

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

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

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

Интересный проектный вызов:

— ассоциируется с пользователем — фокусируется на проблеме — не предлагает готового ответа — достаточно точно определен — предоставляет площадку для развития нескольких концепций

Плохой проектный вызов: «Как мы можем сделать приложение для студентов?»

Здесь уже задан формат решения — приложение.

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

Такой вопрос позволяет рассмотреть разные варианты решения.

Оценка за главу 3 = 0,20 × З1 + 0,35 × З2 + 0,45 × З3

Где: Задание 1 — 20% Задание 2 — 35% Задание 3 — 45%