Привет, я Дима и хочу сделать стартап за 100 дней, а именно нескучное приложение для похудения. У меня за плечами опыт создания приложения с 20 МЛН установок и номинация «Приложение года» от Google. Смогу ли я повторить успех — покажет время, а пока буду делиться процессом создания, инструментами и подходами, которые сам использую.

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

Четвёртая неделя завершилась, промежуточный итог

• Есть понимание рынка, его боли, его объёмов как на РФ, так и на остальной мир;

• Понимание маркетинговой стратегии, которая позволит привлечь первых пользователей (это сразу закладывается в функицонал приложения);

• Есть анализ конкурентов: примерное понимание выручки, скринкасты всех онбордингов, понимание на какие эмоции давят они;

• Есть бэклог функционала будущего приложения (нужно будет потом решить, что пойдёт в реализацию в первую очередь, а что оставить на потом);

• Есть первая версия прототипа онбординга пользователя, получилось чуть больше 60 экранов — звучит очень много :) но, если посмотреть на рынок, то практически у всех лидеров — длинные онбординги: у одного так вообще 80 экранов, чтобы пройти такой онбординг нужно потратить, примерно, 15 минут времени... о важности онбордингов писал ранее: можете почитать «неделя 2» и «неделя 3».

Коридорное исследование

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

На этом этапе важно осознать: всё ли понятно другим людям или собственные шоры и сильное погружение в контекст — делают много слепых зон. Такое бывает часто —  вы думаете: «да что тут объяснять и так всё понятно!», а другие смотрят и: «это ваще об чём?».

Коридорный тест — это очень важная часть пути, не нужно думать, что это что-то сложно, я никогда этого не делал и у меня не получится. Главные особенности коридорного тестирования:

— Быстрый запуск. Вам не нужно доводить продукт до совершенства, тем более пока вы будете это делать он ещё 10 раз поменяется в процессе, поэтому важно как можно скорее собрать отзывы с самой сырой версией продукта/идеи.

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

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

— Без подробностей. Когда человек будет у вас что-то спрашивать: не отвечайте ему сразу ¯\_(ツ)_/¯ пусть вопросы повиснут в воздухе, человек сам начнёт размышлять и домысливать, а вы накручивайте на ус :)

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

На всё про всё: минут 15 на человека. Делайте заметки либо во время теста, либо сразу после, не думайте, что запишите всё на следующий день: «кривая забывания Эббингауза» гласит — через 10 часов в памяти остаётся 35% от изученного.

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

Что делать с готовыми прототипами? Опыт вайбкодинг

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

А сейчас встал соблазн собрать проект в какой-нибудь нейросетевой приблуде, которая всё быстренько за тебя сделает.

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

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

Из последнего, что попробовал — Figma Make. Ожидания были крайне высокие, но на деле такая ситуация — вот прототипы на вход:

Вот что выдала Фигма на выходе:

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

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

Вот пример чуть более сложных макетов:

Результат:

• Появились какие-то слайдеры левые под кнопками, причём бывает сразу по несколько штук на одной странице;

• Плашки с навигацией перекрывают иконки;

• Непонятные белые полосы снизу;

• Иконки где-то одинаковые, где-то разные;

• Где-то текст игнорирует контейнеры текстовых блоков и просто уходит за край экрана.

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

Вроде бы, процессом как-то можно управлять и сидеть придумывать промпты, которые будут исправлять ситуацию, правда там есть стандартная ловушка: исправили одно — поломали другое.

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

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

Иконка svg с именем: svg-jxqf0c76kl
Или картинка из ассетов с именем файла: 43688c5e62dbe0105a28519904ebc73dd55d5f5a.png

Поди сразу сообрази: что где на странице, если их там много... Vibe coding VS Vibe debugging, как грится...

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

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

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