Architecture First: как в одиночку с ИИ сделать альтернативу Jira — Часть 2.
Первая статья была о том, зачем мы делаем Laraue Boards и где будет храниться код. Эта — о том, чем мы занялись в первую очередь. И это не написание кода.
До выбора стека, до проектирования схемы базы и до написания первой строки кода необходимо сделать прототип приложения. От него зависит почти каждое последующее решение. Тяжело спроектировать структуру базы под экран, который никогда не видел. Тяжело определить путь пользователя в интерфейсе, которого ещё нет. Прототип превращает расплывчатую идею продукта в некоторое видение, от которого можно отталкиваться в дальнейшей разработке.
Как бэкенд-разработчику прототипировать интерфейсы
В Laraue нет инженеров с коммерческим опытом написания фронтенда, все мы специализируемся на бэкенде. Проектирование интерфейсов долгое время было основной проблемой для нашей команды. Figma требует серьезного погружения в компоновку, чтобы начало получаться что-то стоящее. Кроме того, результат еще нужно было перенести в HTML.
ИИ это изменил. Мы можем описать экран предложениями и получить рабочий HTML-прототип, который можно пощупать в браузере. Это не изображение, а реальный интерактивный интерфейс. Для бэкенд-инженера это лучшая отправная точка, которую только можно себе представить.
О том, для чего мы используем ИИ, а где стараемся избегать — мы упоминали в статье как мы пишем софт. Здесь — о реальном использовании при создании Laraue Boards.
Вайб-кодинг интерфейса
Мы использовали модель от Claude, и просили сгенерировать HTML таск-трекера, в котором будет реализована нужная нам функциональность. Затем пробуем реальные сценарии — создание задачи, перемещение ее между колонками и т.д. Если функциональности не хватает — просим добавить. Что-то не работает — просим починить. Никакой rocket science, только вайб.
Мок-данные здесь очень важны. Прототип с тремя аккуратными плейсхолдерами выглядит отлично. Но про пограничные кейсы: длинные заголовки, пустые состояния, большое количество элементов — ИИ часто забывает. Поэтому на этапе создания прототипа мы пытаемся сломать макет как только можем, просим генерировать достаточное количество мок-данных. Исправление ошибки, пойманной на этом этапе, почти ничего не стоит — в отличие от той, что будет исправляться в реальном приложении.
Еще лучше сразу определиться, будет ли приложение mobile first или desktop first и отразить это в промптах. От этого будет зависеть итоговая компоновка интерфейса.
Результаты прототипирования
В конце итерации мы получили такой прототип для Laraue Boards:
Прототипирование отлично включает фантазию — беглый взгляд на сгенерированный интерфейс рождает идеи. ИИ может добавить то, о чем ты даже не думал, и это выглядит хорошей функцией. Что-то, задуманное ранее, уже кажется лишним. Что-то выглядит неплохо, но есть понимание, что реализация будет долгой и сложной — такое исключается из первых итераций.
В этом и ценность прототипа: решения принимаются дёшево, изменения добавляются за секунды. К моменту, когда мы начали писать настоящий код, вопросы по интерфейсу уже были решены.
Путь от прототипа к реальному приложению
HTML-прототип — не конечный результат. Он отлично подходит для ранних демонстраций, но не является продуктом. Между прототипом и реальным приложением — огромная пропасть. В следующих статьях сгенерированный HTML-файл будет использоваться как референс для создания бэкенда и фронтенда, пока в конце концов не станет реальным продуктом, доступным пользователям.
Что дальше
Прототип показывает, как будет выглядеть продукт. Следующий вопрос о том, как пользователь будет с ним взаимодействовать. Мы определим простейший пользовательский путь, перед тем как перейти к дальнейшему проектированию.