Анализ и формулировка проблемы – это момент, когда все данные, собранные на предыдущих стадиях эмпатии, self-SWOT-анализа и диаграмм, превращаются в четкие цели и задачи. Представьте, что вы собрали сотни комментариев о процессе оплаты в приложении: кто-то жалуется на медленную загрузку, кто-то – на сложность ввода промокода, а некоторые отмечают, что дизайн кнопки «оплатить» слишком неприметный. Теперь ваша задача – не просто собрать эти идеи, а выделить главное.
Первым шагом становится совместная работа с бизнес-партнерами. Вы приглашаете руководителей, маркетологов и разработчиков, чтобы обсудить, какие проблемы важны не только для пользователей, но и для компании. Например, пользователи хотят быстрее оформлять заказы, а бизнес стремится сократить abandon rate – процент пользователей, которые не доходят до конца флоу. Это похоже на поездку в командировку: пассажиры хотят быстрее доехать, а водитель – сэкономить топливо. Обе цели могут совпадать, если выбрать оптимальный маршрут.
Затем вы проводите аудит конкурентов. Это не значит копировать их решения, а анализировать, как они решают аналогичные задачи. Например, вы можете заметить, что Ozon использует промокоды в верхнем меню, а Wildberries – в шаге оплаты. Это дает вам идеи, но не ответы: возможно, ваша аудитория привыкла к другому расположению, и придется тестировать варианты.
После этого формулируется проблема. Она должна быть конкретной, как гвоздь, который нужно забить, а не молоток, которым это делается. Например, не «улучшить оплату», а «сократить время завершения заказа на 30% за счет упрощения этапа ввода промокода». Это важно, потому что размытые цели приводят к размытым решениям.
Далее создается план исследований. Он может включать A/B-тесты (например, показать разным группам пользователей разные варианты кнопки оплаты), дополнительные интервью с теми, кто бросил процесс, или анализ метрик вроде «время на шаге». Инструменты вроде Hotjar или Google Analytics помогут отслеживать поведение пользователей, но без предыдущего анализа вы рискуете собирать данные без цели.
Важно, чтобы анализ не останавливался на поверхности. Если пользователи жалуются на дизайн кнопки, это может быть следствием более глубокой проблемы: например, кнопка слишком мала из-за общего дизайна страницы. Нужно искать связь между деталями. Это похоже на поиск причины, почему машина не заводится: может быть не только аккумулятор, но и провода, и датчики.
Теперь вы готовы переходить к генерации идей. Но перед этим нужно убедиться, что проблема сформулирована так, чтобы ее решение не нарушало другие части системы. Например, упрощение ввода промокода может увеличить нагрузку на серверы – здесь бизнес и разработчики должны согласовать компромисс.
Этот этап также помогает понять, какие идеи можно реализовать быстро, а какие требуют долгосрочных изменений. Например, изменение цвета кнопки – это час работы, а переписывание кода флоу – месяцы. Это важно для планирования ресурсов.
Основополагающим шагом является постановка цели – это будто создание якоря, к которому будет привязано каждое решение. Вообразите, что вы разрабатываете приложение для заказа еды. Собранные данные показывают, что пользователи часто бросают процесс оформления заказа. Цель здесь должна быть четкой: например, «сократить abandon rate на 30% за три месяца, увеличив количество завершенных заказов».
Эта цель должна быть SMART – конкретной, измеримой, достижимой, релевантной и ограниченной по времени. Например, «повысить удовлетворенность пользователей» слишком абстрактно, а «сократить время оформления заказа на 20%» – уже планка, которую можно проверить. Это похоже на поход: без карты вы можете идти в любом направлении, но с ней знаете, куда ставить ноги.
Важно, чтобы цель охватывала все пользовательские флоу, а не отдельные этапы. Например, в приложении для еды есть флоу «заказ еды», «изменение заказа», «оплата». Глобальная цель может звучать: «Улучшить опыт пользователей на всех этапах взаимодействия, чтобы к концу года 90% клиентов оценивали приложение на 4.5 звезды». Это помогает команде видеть общую картину, а не фокусироваться на мелочах.
Создание цели требует сотрудничества с бизнес-стейкхолдерами. Например, маркетолог может настаивать на увеличении конверсии, а разработчик – на улучшении технической стабильности. Ваша задача – найти баланс. Если цель «сократить abandon rate», это одновременно повысит конверсию и улучшит технические показатели, если, например, устранить ошибки в оплате.
Цель также служит фильтром для идей. Если команда предлагает добавить социальные сети в профиль пользователя, а цель – ускорить оформление заказа, это предложение можно отложить. Это как в ресторане: если цель – сократить время обслуживания, меню должно быть простым, а не включать сложные блюда.
Теперь вы можете спланировать шаги для достижения цели. Например, если abandon rate высок на этапе оплаты, нужно упростить ввод промокодов или улучшить дизайн кнопки. Цель становится компасом, который показывает, какие изменения приоритетны.
Важно периодически проверять прогресс. Если за месяц abandon rate сократился на 10%, это подтверждает правильность направления. Если нет – нужно пересмотреть стратегию. Это похоже на корабль: если компас показывает, что вы отклоняетесь от курса, корректировка курса спасет от катастрофы.
Ваше путешествие к созданию Problem Statement – это как подготовка карты для экспедиции в незнакомую страну. Представьте, что вы собираетесь в лес, где каждый путь – это этап взаимодействия пользователя с вашим продуктом. Но вместо деревьев и рек вы видите «проблемные участки»: места, где пользователи теряются, разочаровываются или просто уходят. Ваша задача – не просто отметить эти точки на карте, а понять, почему они возникают и как они влияют на вашу главную цель. Например, если ваша цель – увеличить продажи, то повторяющиеся жалобы на сложность оформления заказа (так называемый «проблемный флоу») должны стать вашим приоритетом. Чтобы это сделать, соберите все данные: интервью, отзывы, данные аналитики. Потом, как детектив, просеивайте их, ищите закономерности. Можно даже попросить помощника – например, искусственный интеллект – проанализировать информацию и выделить ключевые боли. Но не останавливайтесь на поверхностных выводах. Спросите себя: «Как эта проблема мешает нам достичь цели?» Если большинство пользователей не могут найти кнопку «Оплатить», это не просто технический сбой – это потеря денег и доверия.
Допустим, вы владелец кафе, и каждый вечер клиенты жалуются на долгие очереди. Проблема на поверхности – медленная работа кассиров. Но если углубиться, вы обнаружите, что клиенты тратят больше времени на выбор блюд из меню, потому что оно слишком запутанное. Вот ваш Problem Statement: «Пользователи (клиенты) сталкиваются с трудностями при выборе блюд (проблема), что увеличивает время ожидания (последствие), и это снижает их удовлетворенность и прибыль заведения (влияние на цель)». Это не просто описание – это компас, который скажет: «Нужно упростить меню, чтобы решить корневую проблему».
Научные исследования подтверждают важность такого подхода. В статье 2021 года, посвященной UX-дизайну, ученые показали, что продукты, где проблемные зоны были выявлены через анализ пользовательских флоу и затем исправлены, на 37% чаще достигали поставленных целей. Например, в мобильном банке, где пользователи часто ошибались при вводе PIN-кода, изменение дизайна поля ввода (например, добавление подсказок) сократило количество ошибок на 40%. Это не случайность – это результат системного подхода к Problem Statement.
Теперь представьте, что ваша цель – сделать приложение для фитнеса. Вы анализируете данные и видите, что многие пользователи не доходят до третьей недели тренировок. Простое решение – добавить больше упражнений. Но если углубиться, вы обнаружите, что проблема в отсутствии мотивации из-за отсутствия обратной связи. Ваш Problem Statement: «Пользователи (новички) не получают четких сигналов успеха (проблема), что приводит к снижению мотивации (последствие), и это мешает нашей цели увеличить длительность использования приложения (влияние)». Теперь ясно: нужно внедрить систему наград или еженедельные отчеты.
Секрет в том, чтобы ваш Problem Statement был как лозунг – кратким, и ясным. Он должен соединять конкретную проблему, ее последствия и вашу глобальную цель. Если вы пишете: «Пользователи не регистрируются», это не проблема – это симптом. А если вы скажете: «Пользователи не могут быстро понять выгоду регистрации (проблема), что снижает количество новых аккаунтов (последствие), и это угрожает нашей цели увеличить базу клиентов (влияние)», – это уже стратегия.
Этот метод работает даже в самых разных сферах. Возьмем образование: школа замечает, что ученики не сдают тесты. Простое решение – дать больше заданий. Но анализ флоу ученика показывает, что они не успевают подготовиться из-за перегруженного расписания. Problem Statement: «Ученики не находят времени для повторения материала (проблема), что ведет к слабым результатам (последствие), и это мешает школе повысить успеваемость (цель)». Теперь решение – не «больше заданий», а пересмотр графика или введение интерактивных уроков.
Важно не бояться идти против интуиции. Часто кажется, что проблема в одном месте, а корень – в другом. Например, в приложении для поиска книг пользователи редко покупают товары. Первое подозрение – низкое качество ассортимента. Но анализ показывает, что они не могут сравнить цены в разных магазинах. Problem Statement: «Пользователи не видят возможности сравнить цены (проблема), что снижает их уверенность в выборе (последствие), и это уменьшает доходы (цель)». Решение – добавить функцию сравнения, и продажи растут.
Аудит конкурентов – это не просто шаблонный список «кто есть кто» в вашей отрасли. Это ключ, который раскрывает дверь в мир, где вы можете не только понять, как ваши клиенты решают проблемы, но и найти свои уникальные «точки роста». Представьте, что вы открываете кафе в районе, где уже есть десяток заведений. Если вы просто копируете меню у соседнего бара, вы не станете лучше, но если проанализируете, что в одном кафе клиенты любят дешевые бургеры, а в другом – эксклюзивные десерты, а третье привлекает студентов с акциями, вы сможете создать меню, сочетающее все три идеи, но с вашим фирменным соусом. Вот что значит аудит: не копирование, а переработка чужого опыта в свой алгоритм успеха.
Методология 70-20-10 – это не просто цифры. Это закон природы бизнеса. Как дерево растет: 70% его энергии тратится на корни, которые уже есть, 20% – на новые ветви, а 10% – на цветы, которые никто не видел. Так и в бизнесе: большинство решений – это проверенные решения, которые «работают», но именно 10% инноваций делают вас неповторимым. Например, Спотифай не изобрел стриминг музыки, но добавил персональные плейлисты и анализ прослушивания, что сделало его лидером. Ваша задача – найти эти 10% в чужом опыте.
Анализ конкурентов – это как собрать пазл из их сильных сторон. Возьмем Яндекс. Еду: ее трафик виден через SimilarWeb, но сколько пользователей в приложении? Ответ лежит в их отчетах. Представьте, что вы хотите запустить аналогичный сервис в Украине. Вы не просто посмотрите, сколько у них заказов в месяц, но и сравниваете: почему в России они дешевле, чем в Казахстане? Возможно, из-за логистики или спроса. Это не просто цифры – это язык, на котором говорит рынок. Иногда данные в открытом доступе: стартапы хвастаются в блогах, публичные компании – в финансовых отчетах. Используйте это, как навигатор в чужом коде.
Иногда анализ конкурентов становится игрой в «кто кого». Google vs. новичок – это не просто сравнение, а тест доверия. Люди верят Google, потому что он «знает все», а новичок – как незнакомец на углу с непонятным продуктом. Но если вы решите копировать Google, вы проиграете. Вместо этого найдите компанию, где доверие сочетается с инновациями. Например, Tesla: они не просто «лучший электромобиль», но и рассказывают о технологиях так, что клиенты становятся их соавторами. Ваша задача – найти такого «середнячка», который уже заработал уважение, но не стал «монстром», и взять у него лучшее.
О проекте
О подписке