Анализ и определение проблемы
Анализ и формулировка проблемы – это момент, когда все данные, собранные на предыдущих стадиях эмпатии, self-SWOT-анализа и диаграмм, превращаются в четкие цели и задачи. Представьте, что вы собрали сотни комментариев о процессе оплаты в приложении: кто-то жалуется на медленную загрузку, кто-то – на сложность ввода промокода, а некоторые отмечают, что дизайн кнопки «оплатить» слишком неприметный. Теперь ваша задача – не просто собрать эти идеи, а выделить главное.
Первым шагом становится совместная работа с бизнес-партнерами. Вы приглашаете руководителей, маркетологов и разработчиков, чтобы обсудить, какие проблемы важны не только для пользователей, но и для компании. Например, пользователи хотят быстрее оформлять заказы, а бизнес стремится сократить abandon rate – процент пользователей, которые не доходят до конца флоу. Это похоже на поездку в командировку: пассажиры хотят быстрее доехать, а водитель – сэкономить топливо. Обе цели могут совпадать, если выбрать оптимальный маршрут.
Затем вы проводите аудит конкурентов. Это не значит копировать их решения, а анализировать, как они решают аналогичные задачи. Например, вы можете заметить, что Ozon использует промокоды в верхнем меню, а Wildberries – в шаге оплаты. Это дает вам идеи, но не ответы: возможно, ваша аудитория привыкла к другому расположению, и придется тестировать варианты.
После этого формулируется проблема. Она должна быть конкретной, как гвоздь, который нужно забить, а не молоток, которым это делается. Например, не «улучшить оплату», а «сократить время завершения заказа на 30% за счет упрощения этапа ввода промокода». Это важно, потому что размытые цели приводят к размытым решениям.
Далее создается план исследований. Он может включать A/B-тесты (например, показать разным группам пользователей разные варианты кнопки оплаты), дополнительные интервью с теми, кто бросил процесс, или анализ метрик вроде «время на шаге». Инструменты вроде Hotjar или Google Analytics помогут отслеживать поведение пользователей, но без предыдущего анализа вы рискуете собирать данные без цели.
Важно, чтобы анализ не останавливался на поверхности. Если пользователи жалуются на дизайн кнопки, это может быть следствием более глубокой проблемы: например, кнопка слишком мала из-за общего дизайна страницы. Нужно искать связь между деталями. Это похоже на поиск причины, почему машина не заводится: может быть не только аккумулятор, но и провода, и датчики.
Теперь вы готовы переходить к генерации идей. Но перед этим нужно убедиться, что проблема сформулирована так, чтобы ее решение не нарушало другие части системы. Например, упрощение ввода промокода может увеличить нагрузку на серверы – здесь бизнес и разработчики должны согласовать компромисс.
Этот этап также помогает понять, какие идеи можно реализовать быстро, а какие требуют долгосрочных изменений. Например, изменение цвета кнопки – это час работы, а переписывание кода флоу – месяцы. Это важно для планирования ресурсов.
