Создание успешного SaaS-продукта часто описывается как навигация по «нечеткому интерфейсу» инноваций — хаотичному пространству, где основатели, инженеры и дизайнеры имеют разные мнения о том, что создавать дальше. Традиционно для преодоления этого разрыва команды полагались на Персоны и Пользовательские истории, но эти инструменты часто терпят неудачу, поскольку фокусируются на атрибутах, а не на причинно-следственных связях. Advanced Jobs-to-be-Done (JTBD) предлагает более строгую альтернативу: инновационную архитектуру, которая рассматривает борьбу клиента как структурированный процесс.
Почему персонажи и пользовательские истории не проходят тест SaaS
Большинство SaaS-команд попадают в ловушку проектирования для «воображаемых клиентов», определяемых демографическими данными. Знание того, что пользователем является 37-летний менеджер по маркетингу с двумя собаками, не объясняет, почему он вдруг решил «уволить» свою текущую таблицу и «нанять» ваше программное обеспечение.
Более того, традиционные Истории пользователей («Как пользователь, я хочу…») часто терпят неудачу, потому что они напрямую связывают реализацию с мотивацией. Это делает практически невозможным определить, произошла ли ошибка функции из-за плохой реализации или из-за неверного основного предположения о мотивации пользователя.
История работы: Проектирование с учетом контекста и тревоги
Чтобы решить эту проблему, опытные специалисты используют Истории вакансий, чтобы составить детальную карту причинно-следственных связей. Вместо общей «роли пользователя» история работы фокусируется на событии и эмоциональном контексте:
“Когда [Ситуация], я хочу [Мотивация], чтобы я мог [Ожидаемый результат]”.
Например, когда продавец автомобилей помогает клиенту оформить заявку на кредит, ему не нужен просто «просмотр профиля». Им нужен специальный пользовательский интерфейс, который обеспечивает доверие и социальную защиту во время деликатного финансового взаимодействия, чтобы клиент чувствовал себя в безопасности, вводя личные данные. Оформив функции таким образом, каждый элемент вашего SaaS UX — от изображения профиля до кнопки «Свяжитесь со мной» — можно отследить до решения конкретной проблемы клиента.
Картирование должностей: универсальный процесс прогресса
Advanced JTBD выходит за рамки мозгового штурма, признавая, что каждая «работа» — это процесс, который разворачивается во времени. Универсальная карта должностей позволяет командам SaaS разбить любую функциональную цель на восемь предсказуемых этапов:
- Определение. Определение целей и планирование.
- Найти: Сбор необходимой информации или материалов.
- Подготовка: Настройка и организация среды.
- Подтверждение. Проверка готовности исполнителя к продолжению.
- Выполнить: Выполнение основной задачи.
- Монитор: Отслеживание хода выполнения и проверка на наличие ошибок.
- Изменить: Корректируем, чтобы не сбиться с пути.
- Заключение. Завершение и сохранение результатов.
Для основателя SaaS эта карта — инструмент диагностики. Зачастую команды создают функции только для этапа «Выполнение», пренебрегая этапами «Найти» или «Подготовка», где клиенты действительно испытывают наибольшие трудности.
Адаптация к работе, а не к инструменту
Распространенной ошибкой SaaS является адаптация пользователей к продукту (обучение их расположению кнопок), а не к работе (помогая им достичь первой победы). Когда вы понимаете, что клиент «нанимает» ваше приложение для прогресса, ваша адаптация должна быть сосредоточена на понимании работы.
Вместо сообщений, ориентированных на инструменты («Нажмите здесь, чтобы создать отчет»), используйте сообщения, ориентированные на работу, которые подчеркивают результат («Составьте свой первый бюджет и посмотрите, где вы можете сэкономить сегодня»). Это смещает акцент с технологий на «нового себя», которым стремится стать клиент.
Сделайте исследования предсказуемыми с помощью реестра вакансий
Расширенные исследования, подлежащие исполнению (в частности, инновации, ориентированные на результат), показывают, что для любой основной функциональной работы существует от 50 до 150 уникальных показателей (желаемых результатов), которые клиенты используют для измерения успеха. Управление этим уровнем сложности — вот почему необходим специальный исследовательский SaaS.
Специализированная платформа позволяет:
- Зафиксируйте «первую мысль». Задокументируйте конкретные настройки и образ мышления, которые побудили клиента начать искать новое решение.
- Стандартизируйте формулировки потребностей. Используйте строгий синтаксис (направление + показатель + объект + контекст), чтобы потребности были измеримыми и стабильными во времени.
- Оцените возможности: рассчитайте Показатель возможностей $[Важность + Макс(Важность – Удовлетворенность, 0)]$, чтобы математически доказать, какие функции будут способствовать наибольшему росту рынка.
Инновации — это не игра идей; это процесс открытия. Создавая архитектуру SaaS на основе стабильной, независимой от решения «работы», вы гарантируете, что, несмотря на развитие технологий, ваш продукт останется незаменимым для прогресса клиента.