Мы были собственными первыми пользователями: как не перепутать личную боль с доказанным спросом

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

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

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

Собственная боль даёт направление, но искажает масштаб

У основателя-пользователя есть сильное преимущество: он понимает работу не по интервью. Мы знали, что после урока легко отложить чек, что перенос занятия затрагивает не только дату, а заметки и расчёты, что доска должна пережить один звонок и открыться на следующей неделе.

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

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

Сценарий лучше списка возможностей

Проверять «кабинет репетитора» целиком бессмысленно. Человек открывает много разделов, устаёт, а команда получает отзыв уровня «вроде удобно» или «слишком много всего». Ни то ни другое не говорит, что именно сработало.

Мы стали формулировать проверку как короткую цепочку. Например:

1. Преподаватель регистрируется в своей роли;
2. Добавляет тестового ученика без реальных персональных данных;
3. Назначает один урок;
4. Переносит его или меняет цену;
5. Открывает карточку урока и понимает, что делать дальше;
6. На следующий день находит тот же контекст без подсказки от команды.

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

Текущий экран на демонстрационных данных показывает один узел сценария: занятие связано с учеником, стоимостью и следующими действиями. Сам скриншот не доказывает, что этот порядок понятен новому преподавателю.

Внешняя попытка должна быть достаточно самостоятельной

Когда продукт знаком до последней кнопки, хочется сопровождать тестировщика голосом: объяснить термин, показать путь, заранее предупредить об исключении. Так можно успешно провести демонстрацию и ничего не узнать о самостоятельной работе.

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

Одна из внешних попыток хорошо показала эту разницу. Человек спросил, где взять внутренний ключ. Для обычной регистрации преподавателя такой ключ не нужен. Значит, проблема возникла до проверки учебных функций: формулировка или маршрут входа создали ложное обязательное действие. Ответом должно быть не «пользователь не разобрался», а проверка экрана регистрации и инструкции, после которой этот вопрос не возникает.

Наблюдаемая остановка ценнее общего впечатления

Мы получили и более общее замечание: кабинет кажется перегруженным. Это важный сигнал, но ещё не задача для разработки. Нельзя просто убрать половину интерфейса, не выяснив, что человек собирался сделать.

Общее впечатление нужно разложить на наблюдения:

• на каком экране человек находился;
• какое действие искал;
• что принял за главное;
• какая подпись или блок отвлекли;
• смог ли продолжить без объяснения;
• вернулся ли к сценарию позже самостоятельно.

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

Текущая версия дашборда строится вокруг ближайших уроков и блока «Требуют внимания», а остальные разделы остаются в навигации. Это продуктовая гипотеза: сначала показать перенос, сданное домашнее задание или платёж, а не просить человека просмотреть весь кабинет.

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

Из остановки должно следовать решение

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

собственная боль → рабочий сценарий → попытка другого преподавателя → наблюдаемая остановка → решение.

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

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

1. Исправить язык. Функция есть, но человек не понимает термин или следующий шаг.
2. Исправить интерфейс. Действие понятно, но его трудно выполнить на нужном устройстве или в обычной последовательности.
3. Пересмотреть модель процесса. Продукт предполагает один порядок работы, а практика преподавателя устроена иначе.
4. Оставить честную границу. Пожелание полезно, но находится за пределами продукта. Тогда важнее ясно сказать, чего кабинет не делает.
5. Остановить гипотезу. Если сценарий не повторяется за пределами нашей собственной работы, не нужно расширять его только потому, что уже потрачено время на разработку.

Эта классификация дисциплинирует. Просьба «добавьте ещё один раздел» не автоматически становится задачей. Сначала нужно понять, какое действие без него невозможно и нельзя ли решить проблему понятнее.

Вежливый интерес — ещё не спрос

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

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

Поэтому мы разделяем сигналы:

• согласие посмотреть;
• начало сценария;
• точку остановки;
• завершение без помощи;
• повторное использование по собственной инициативе.

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

Как провести такую проверку в маленьком продукте

Метод не привязан к репетиторам. Его можно использовать в сервисном бизнесе, внутреннем инструменте или узком B2B-продукте.

1. Сначала запишите личную боль как действие. Не «всё разбросано», а «после переноса встречи я меняю дату в календаре, ищу сообщение клиенту и отдельно исправляю расчёт».
2. Выберите один сценарий. В нём должны быть понятны начало, завершение и обычное исключение. Если проверяется всё сразу, невозможно понять причину остановки.
3. Позовите человека с похожей работой, но не объясняйте интерфейс заранее. Дайте цель и безопасные тестовые данные. Помогите после остановки, а не вместо попытки.
4. Фиксируйте экран, действие и ожидание. «Неудобно» — сигнал. «Искал перенос в карточке ученика, а нашёл только в календаре» — материал для решения.
5. Закрывайте цикл решением и повторной проверкой. После изменения тот же шаг должен пройти другой человек или тот же человек без старой подсказки. Иначе команда улучшила макет, но не проверила поведение.

Личная боль остаётся полезной — если ей не давать лишних полномочий

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

Собственная боль отвечает на вопрос «с чего начать». Попытка другого человека показывает, где наша логика перестаёт быть очевидной. Наблюдаемая остановка превращает впечатление в материал. Решение и повторная проверка показывают, научилась ли команда чему-то, кроме умения объяснять свой интерфейс.

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