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

Мы считали всё очевидным: анимация же явно показывала, что страница загружается, так в чём же проблема? Не хватало явного объяснения, что сейчас происходит.

Загружаем Канбан. Подождите, подготавливаем колонки и задачи.

После этого поведение изменилось. Мы больше не увидели дёрганых действий, вместо этого — терпеливое ожидание, пока страница загрузится. И тут у нас возникла одна из первых трещин.

Если даже такую простую вещь мы не смогли до конца предсказать, что ещё в продукте существует только в нашей голове?

Мы не придумали продукт из головы.

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

При этом мы не бросились сразу делать MVP. До разработки мы изучили рынок и конкурентов, собрали паспорт продукта, посмотрели спрос через wordstat. Сформировали проблему и попытались понять, тратят ли люди время и деньги из-за нее.

Так в чём же мы ошиблись?

Мы ошиблись не в исследовании, а в ожиданиях от него

Изначально мы верили в простую вещь:

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

Исследование оказалось полезным, но оно не смогло ответить на главный вопрос. Что произойдет, когда реальный человек столкнется с продуктом?

MVP — это лишь начало

Только после запуска мы увидели как люди пользуются продуктом. Мы знали, как устроен продукт. Какие функции есть. Почему в канбане устроен так. Почему мы не добавили персонализацию, оставив только возможность менять цвет колонок.

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

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

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

И здесь важно не просто замечать такие сценарии, а попытаться понять, почему человек ведет себя именно так.

Функция существует для команды, но может не существовать для пользователя

Какими бы хорошими ни были идея и реализация, функция остаётся бесполезным куском кода, пока пользователь не добрался до её ценности. Будет ли человек пользоваться канбаном, если он даже не знает, что тот существует, или не понимает, зачем он ему нужен? А заметками, файлами или другими инструментами в проекте?

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

Конкретно в этом случае нам помогла более наглядная модалка создания. Вместо длинного объяснения, что такое заметка, мы прямо в модалке показали, как она выглядит и из чего состоит.

И, конечно же, никто нам не прислал готовое ТЗ — Пользователи просто показали, что часть функций для них просто не существует.

Иногда пользователь ожидает то, чего в продукте вообще нет

Другой сценарий у нас повторялся пару месяцев. В WorkHub вся работа разделена по проектам. И изначально мы намеренно запретили перенос канбанов между ними. Для нас проект всегда означал отдельный слой жизни. Разработка, личная жизнь, хобби — они все были разделены, и, как мы думали, люди поймут.

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

Честно признаться, когда только проектировал IDE-дерево, я запретил такие перемещения без задней мысли. Но реальный юзер вёл себя так, будто эта функция уже существует, и на протяжении пяти минут пытался перенести канбан в другой проект. (У него не получилось.)

Это не был единичный случай: на протяжении месяца мы наблюдали ещё людей, которые хотели это сделать. В итоге мы всё-таки добавили возможность переноса — но не после первого такого случая. Сначала мы продолжили наблюдать и проверять, повторяется ли этот сценарий у других пользователей.

Одно странное действие ещё ничего не значит

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

Но тут, как и в других аспектах жизни, принятие одной из крайностей не ведёт ни к чему хорошему. Игнорируешь такие случаи — по сути, разрабатываешь продукт отдельно от пользователей со всеми вытекающими рисками. Бросаешься исправлять продукт после каждого такого случая — и в итоге у тебя получается нечто. Баланс опять где-то посередине.

Поэтому мы стали воспринимать эти сигналы как гипотезы. Гипотеза на то и гипотеза, что её ещё нужно подтвердить или опровергнуть.

Как мы проверяем такие сигналы

Мы решили создать собственную схему:

Наблюдение → повторение → гипотеза о причине → небольшое изменение → повторная проверка.

Наблюдение: что человек пытается сделать? С какими трудностями он сталкивается и как это влияет на него?

Повторение: тот же сценарий появляется у других людей.. Разные люди делают одно и то же. Здесь нет фиксированного N случаев, после которых наблюдение сразу становиться рабочей гипотезой.

Гипотеза: Нас интересует не то, что человек делает на экране, а какую задачу он пытается решить.

Изменение: что можно минимально поменять, чтобы проверить наше предположение?

Повторная проверка: изменилось ли поведение или мы неправильно поняли причину. Добавили надпись на скелетон — пользователь перестал дёргать мышкой, а выходов из приложения стало меньше.

Такая логика не всегда приведёт к следующей функции, иногда она покажет обратное, и это нормально.

Почему мы остановили добавление функций

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

Особенно заметными стали две группы проблем.

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

Вторая — интерфейс не всегда даёт человеку понять, что сейчас происходит: началась ли загрузка, сработало ли действие, сохранились ли изменения».

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

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

Раньше развитие продукта для меня в первую очередь означало новые возможности. Сейчас для меня важнее другое: может ли человек самостоятельно разобраться в продукте и добраться до его ценности».

Если человек не может нормально пользоваться тем, что есть, какой смысл в количестве новых функций?

Хороший продукт нельзя придумать заранее

Мой тезис не в том, что исследование рынка и предварительное планирование бесполезны. И не в том, что только пользователь способен подсказать, каким должен быть продукт.

Предварительная работа помогает выбрать точку старта. Анализ рынка, аудитории и конкурентов, формулировка проблемы помогают ответить на вопрос: „С чего начать?“

Хороший продукт почти никогда нельзя придумать заранее. Но можно научиться замечать, каким он должен стать.