Как создать свое мобильное приложение? Процесс и алгоритм от практика

Всем привет! Хочу поделиться личным опытом создания мобильного приложения. Без описания бизнес процессов, бизнес-планов, чисто технически: как сделать, а точнее как я делаю мобильные приложения. Я помог сделать более 10-ти приложений для клиентов и одно сделал для себя (приложение по обучению дизайну в формате игры Lyra). Сапожник с сапогами :)

Когда ко мне приходит клиент, первое, что я спрашиваю «что уже есть?». Мне важно понять, что человек уже подготовил к этому моменту и конечно мне хочется разобраться, что же клиент хочет сделать.

Чаще всего клиент присылает ТЗ написаное как-то и черновики. Последние два моих прекрасных клиента, прислали мне скетчи которые они сделали на листке бумаги. Это конечно немного вгоняет меня в тоску разбираться с тем, что написано от руки на листке, но я работаю с любыми вводными которые есть.

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

Некоторые из мои клиентов проверяли спрос на свой продукт до того как обратились ко мне. Чаще всего — это было в формате кастдевов, то есть интервью. И это прекрасный инструмент если его правильно использовать, чтобы понять будет ли твой продукт решать реальную проблему.

Когда я проводил тест своего продукта (Lyra), я заморочился чуть сильнее. Я собрал три тестовых урока в фигме, собрал чат-бота, закупил рекламу в тг и соединил все вместе. Я хотел реально выяснить — мой продукт кому-то вообще интересен. В этой статье описываю детально об этом эксперименте.

Следующим этапом идет погружение в проект. Я разбираюсь с ЦА, нюансами ниши, болями и потребностями, делаю распаковку клиента (модное словечко распаковка, но оно мне нравится) и как итог составляю карту всего проекта.

Карта — это фундамент проекта, я ее делаю всегда без исключения, потому, что это сразу дает понять объем приложения и вообще что к чему. Какие страницы, как они связаны, корректен ли путь пользователя.

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

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

Также мы создаем интерактив в фигме. Это когда вы видите не только дизайн, но и можете покликать его (подобие как реальное приложение).

Так как мы создали дизайн и не просто дизайн, а интерактивный, мы можем взять фокус группу и потестировать наш продукт на предмет понятности \ удобности.

Например когда мы делали ре-дизайн модулей в забота 2.0 мы тестировали каждый модуль на пользователях. И не на каких-то рандомных, а на тех, кто использовал текущую версию заботы 2.0. Мы смотрели насколько людям удобнее\понятнее в новой версии, да и пользователи были заинтересованы все покликать от души (ведь им потом пользоваться системой). Мы собирали фидбэк, дорабатывали и после отдавали в разработку.

Когда дизайн готов и протестирован то важно подготовиться к передаче в разработку и написать детализированное ТЗ. И тут ключевое слово детализированное — это значит очень внимательно и дотошно описать фронтэнд, возможности которые вам нужны в админке и прочее. Чем детальнее и точнее, тем лучше будет результат.

Я когда делал Lyra, я нашел разработчиков и они работали за фикс по ТЗ. И было важно, чтобы ТЗ соответствовало, а иначе я бы платил за доработки. По итогу к концу работы, мы отклонились от ТЗ максимум на 2-3%. Это все благодаря детализированному ТЗ.

Когда начался этап разработки я замучился проверять и контролировать разработчиков. То там что-то сломается, то тут. То тут починили, а там снова сломалось. Страшно мучительно, так это еще с учетом того что функционала у меня не много.

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

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