Вайбкодинг на практике - бесплатный курс. Урок 3. Продумываем user flow

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

Первую часть и описание идеи продукта можно найти здесь:

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

Поэтому в этом уроке мы продумаем user flow — путь пользователя от регистрации до готового договора — и доведём прототип до состояния, когда его можно прокликать как настоящее приложение.

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

Сначала прогнал текст через /prompt-master, затем запустил результат в режиме Plan и, посмотрев план, попросил его выполнить:

Обратите внимание на последний абзац. Если не попросить моковые данные явно, агент сделает пустые экраны с заглушками, и прокликать сценарий целиком не получится. А нам важно именно «пожить» в продукте до того, как писать код.

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

Сначала про книгу. Агент описал новый путь пользователя на странице «Как устроен продукт сейчас», составил список экранов и добавил семь новых открытых вопросов: что можно делать до подтверждения почты, что считать визитом для блока «новое», видит ли контрагент имя пользователя, какой точный набор полей у реквизитов и другие. Часть старых вопросов закрылась сама — ответы были в моём промпте.

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

Реквизиты сделаны так, как я и хотел: сначала выбираешь форму — ООО, ИП или физлицо, — и форма показывает только нужные поля. Хотя тут есть несколько нюансов которые мы исправим позже

Шаблоны собираются в конструкторе: разделы, пункты, порядок меняется кнопками и с клавиатуры. Импорт файла пока имитация — выбираешь Word, PDF или текст, и конструктор заполняется готовым примером.

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

Ссылку контрагенту можно выдать, отозвать и выдать снова. А по ссылке контрагент видит только сам договор — без дашборда, шаблонов и наших реквизитов.

И проверяем адаптивность на телефоне:

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

Я сел и прошёл весь путь руками: "зарегистрировался", завёл реквизиты, собрал шаблон, создал проект, сделал ссылку, посмотрел на договор глазами контрагента и распечатал. Вот что нашлось.

Ошибки. Самая неприятная — печать. На бумагу уходит исходный текст шаблона, а принятые редакции теряются. А это ровно то, ради чего вообще делается продукт. Ещё в конструкторе кнопка «Вниз» у первого пункта стирает соседний раздел, а если удалить все реквизиты, проект перестаёт открываться.

Дыры в логике. В книге написано: итог ставится, когда спорных пунктов нет. Но что такое спорный пункт — нигде не сказано. Прототип решил за нас: спор — это когда обе стороны написали свои редакции. А если контрагент предложил правку, а мы молчим, — это согласовано? И как контрагенту сказать «согласен» с нашей редакцией, если у него нет такой кнопки? Кнопки «Утвердить итог» тоже нет. Это ровно то, о чём я писал в первом уроке: пропустили вопросы — нейросеть додумала.

Неудобства. Комментарий и редакция выглядят одинаково — цветная плашка с мелкой подписью. Создать проект с дашборда нельзя, только из конструктора. Конструктор на 15 пунктов превращается в 45 кнопок «Вверх / Вниз / Удалить». На большом мониторе договор стоит узкой колонкой, а по бокам пусто.

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

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

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

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

Давайте в рамках данного урока постараемся исправить часть описанных проблем
Начинаем с правил:

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

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

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

Отдельно обратите внимание на строку «Что считать спорным пунктом пока не трогай». Без неё агент, скорее всего, решил бы этот вопрос сам — а это продуктовое решение, его принимаем мы.

Результат: все одиннадцать пунктов исправлены. Агент сам прошёл сценарии в браузере, как я и просил.

Печать теперь выводит итоговый текст без комментариев:

Есть момент, на которые стоит посмотреть внимательнее.

Агент принял продуктовое решение сам. Чтобы исправить печать, ему нужно было решить, какой текст считать итоговым. Он решил: принятая редакция или наша редакция, если она есть. И записал это в книгу как факт. Получается, что в печать попадает наша формулировка, с которой контрагент ещё не согласился.

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

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

Как и во втором уроке, просто пишу ответы на вопросы своими словами. Прототип в этом шаге не трогаем — сначала книга. Заодно исправляю то, что агент сам решил про печать в прошлом шаге:

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

Что получилось. В книге появилась отдельная страница «Статусы»: какие статусы бывают у пункта и у документа, когда они наступают и что при этом видит каждая сторона.

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

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

Сейчас книга и прототип расходятся: в книге печать только после утверждения и кнопка «Согласен», в прототипе — нет. По нашим правилам это дефект, и чиним его следующим шагом.

Описываю, что хочу увидеть, и прошу агента самому пройти весь сценарий:

Изменения затрагивают почти все экраны проекта, поэтому снова режим Plan, а затем выполнение плана.

Результат — первый раз за курс в прототипе можно пройти весь путь от начала до конца.

Дашборд показывает статус каждого проекта: на согласовании, готов к утверждению или утверждён.

В проекте над договором появилась строка: сколько пунктов согласовано, сколько ждут нас, сколько ждут другую сторону и есть ли спор. Рядом кнопка перехода к следующему открытому пункту и «Утвердить итог». Пока есть открытые пункты, кнопка неактивна и объясняет почему.

У каждого пункта свой статус, а кнопка «Согласен» теперь есть у обеих сторон. Подписи тоже поменялись: вместо «своя сторона» и «контрагент» — «Вы» и название другой стороны.

Проходим сценарий. Контрагент соглашается с нашими редакциями в двух пунктах. Мы соглашаемся с его редакциями в остальных. Статус меняется на «готов к утверждению», кнопка становится активной.

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

Нашлась одна мелочь: контрагенту после утверждения пишется «доступна версия для печати», а кнопки печати у него нет. Исправим позже

Получившуюся книгу я скопировал в lessons/lesson-3/ и сделал коммит.

В следующем уроке займёмся улучшением дизайна

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

Версия документации по результатам данного урока здесь:

Также напомню про мой телеграм-канал «Своими словами», где я:

— разбираю решение реальных задач управленца с помощью ИИ;— помогаю людям без IT-бэкграунда разобраться в технических инструментах (те же ssh, cron, docker, git и прочие);— рассказываю об интересных кейсах и важных темах в M&A.

Предыдущие уроки:

Урок 0
Урок 1. Первые шаги и разочарование в результате
Урок 2. Исправляем ошибки
Следующий урок:

Скоро