Мобильное приложение: сколько стоит и как сделать? Полный гайд
Привет! Меня зовут Глеб Федоренко, я основатель Galt Agency – мы создаём мобильные приложения под ключ для других бизнесов (в портфолио разные проекты: от e-com и fashion до логистики в Европе).
До агентства я делал несколько своих проектов, связанных с мобильными приложениями.
На пути разработки своих приложений я прошел через все стадии: от найма фрилансеров, агентств до построения своей команды.
В этой статье я максимально подробно поделюсь своим опытом и попытаюсь помочь вам определиться со стратегией, если вы решили делать мобильное приложение.
Обычно процесс создания приложения состоит из пяти стадий: от идеи до запуска. Каждую из них можно контролировать самому или делегировать специалистам.
Идея, анализ рынка, бизнес-модель
Первое, о чём стоит задуматься, — нужно ли это приложение вообще. Точно ли нельзя обойтись мобильной версией сайта?
Ваши действия зависят от стадии бизнеса. Если вы делаете приложение для работающего бизнеса, и оно поможет вам масштабироваться – вопрос отпадает.
Если делаете стартап, перед стартом работ нужно сделать три шага:
- подумать, какие проблемы актуальны для людей (выявление потребности);
- посмотреть, какие приложения уже могут их решить — что они делают, какой у них функционал и назначение, о каких проблемах пишут в отзывах (анализ рынка и конкурентов);
- просчитать, сколько денег вы реально можете вложить в этот проект, его минимальную жизнеспособность и сколько он потенциально принесёт (фин. модель).
Разберём на банальном примере. Все люди периодически хотят есть, а значит есть вечная проблема — где взять еду. Её решают несколько типов приложений: доставки продуктов из нескольких магазинов, собственные приложения доставки крупных супермаркетов, доставки готовой еды из ряда заведений и собственные приложения у крупных кафе и ресторанов. Ещё недавно на этом рынке была проблема — всё везли слишком долго, от 45 минут. Её решило известное приложение доставки продуктов за 15 минут с названием двухколёсного транспорта. И это выстрелило!
Почему приложение? Потому что быструю доставку продуктов заказывают на ходу, пока делают другие дела. Оно всегда под рукой. Выбор бананов – не выбор машины, где семья может собраться у компьютера и в деталях изучать варианты.
Если идея найдена, для неё есть место на рынке и деньги на разработку — можно идти дальше. Если самому анализировать рынок и просчитывать бизнес-модель некогда, не хочется или не совсем понятно как, можно уже на этом этапе привлечь специалистов. Они сделают это быстрее и эффективнее.
Требования к продукту
Идея есть, осталось продумать реализацию. На этом этапе стоит задать себе пять важных вопросов:
- Что приложение должно делать — собирать данные из разных источников и ранжировать их, оформлять и оплачивать заказы, обрабатывать фотографии или что-то ещё. Иными словами, зачем пользователь скачает приложение, и что он должен получить.
- Как на нём зарабатывать — например, брать деньги с кого-то за размещение в нём товаров или рекламы, продавать с его помощью собственные товары, сделать скачивание платным или внедрить механику подписки.
- Кто будет им пользоваться — понять портрет клиента, чтобы разработать приложение, которое попадет в его «боли», будет выглядеть привычно и удобно для него.
- Сколько людей будет им пользоваться – пара сотен человек или сотни тысяч человек. Понятно, что предсказать сразу, выстрелит приложение или нет, вряд ли получится. Но примерно определиться с масштабом всё же нужно ещё до разработки – чтобы построить правильную архитектуру (фундамент для деревянной дачи не выдержит небоскреб, а строить для дачи фундамент небоскреба – неоправданно дорого)
- Как им управлять — что должно быть в админской версии приложения, что в нём можно будет менять, а что нет. Этот вопрос стоит особого внимания, если до этого с приложениями дел не имели. Ведь приложение не статично, в нём придётся что-то менять, например, цены или ассортимент. Чем проще админка — тем легче управлять, но меньше вариантов для внесения изменений.
Ответы на эти вопросы по сути станут краткой версией технического задания — ТЗ, на разработку приложения. Именно это нужно рассказать тому, кто будет его создавать. Иначе высок риск получить совсем не то, что хотелось. Переделывать будет дорого и долго — мало кто готов взяться исправить чужую работу.
Прототип — это визуализация будущего приложения: от схем и набросков к интерактивной модели. На этом этапе нужно чётко понимать:
- кто будет пользоваться приложением — примерный портрет клиента, чтобы понимать вкусы и предпочтения;
- в какой ситуации — на бегу в метро или лёжа в постели в выходной;
- для чего — развлечься и занять время, сделать рабочие задачи, пообщаться с друзьями или что-то купить.
Каждый из этих пунктов влияет на дизайн. И речь не только и не столько о цветовой гамме, сколько о выборе элементов для экранов, их расположения, дополнительных фишек и виджетов.
В прототипировании есть три важных этапа:
UX дизайн/wireframe’инг — это создание прототипа приложения в виде схем и набросков экранов.
Сначала нужно продумать путь пользователя: он скачал приложение, а что дальше?
Например, регистрация — авторизация — первые действия — заполнение профиля — оформление заказа — покупка — отслеживание заказа — написание отзыва.
Каждый шаг пользователя — это отдельный экран или wireframe.
На экране размещают основные элементы: кнопки, поля, текстовые блоки, картинки. Они должны быть на привычных местах, например, корзина для товаров обычно находится в правом верхнем углу, а характеристики персонажа в игре — внизу. Вероятно, люди в итоге найдут их в любом месте, но впечатление от использования испортится.
Ещё один важный этап — количество касаний. Чтобы пользователь не сбежал, он должен находить нужное в три клика, максимум — в пять. А чтобы понять, как он будет действовать, придётся прописать пользовательские сценарии: куда в приложении люди будут заходить часто, а куда не очень, какой функционал им нужен больше, а какой — меньше.
Продумывая дополнительные возможности, снова стоит вспомнить о пользователях: когда они будут использовать приложение? Как сделать это комфортнее? Например, добавить в приложение для чтения книг тёмную тему, так как люди часто читают вечером. Или убирать товары из корзины жестом, ведь доставку многие оформляют на бегу.
UI дизайн — следующий этап дизайна, когда появляется цвет, очертания кнопок, шрифты и виджеты. Важно, чтобы цветовые решения отвечали задачам приложения. Нет смысла делать строгий монохромный дизайн в игре, выбирать розовый цвет для каталога люксовых духов или брать ярко-красные оттенки для ЭКО-направления. Пользователей это скорее оттолкнёт и запутает, они не поймут, куда попали.
Интерактивный прототип — важная часть, которую многие пропускают, по сути – анимированные макеты.
На этом этапе приложением уже можно «пользоваться», то есть нажимать кнопки и перемещаться между экранами. Хотя само приложение ещё не существует. Здесь становится наглядно понятно, удобно ли пользоваться приложением, получается ли найти нужные разделы быстро.
Лучше, если прототипы будет оценивать не один человек, а фокус-группа — хотя бы несколько человек. Так выборка будет репрезентативной. Важно, чтобы люди были из целевой аудитории: можно посадить за это сотрудников компании, но результаты будут не слишком достоверными, ведь коллеги знают продукт. В агентствах прототипы тестируют на больших фокус-группах, причём дважды: на этапе вайрфреймов и на интерактивном прототипе. Так получается найти все слабые места интерфейса приложения и устранить их ещё до запуска. А значит — меньше риск получить отрицательные отзывы и потерять деньги.
На этапе разработки важно разделить два понятия — frontend и backend. Запомнить легко:
- frontend — то, что спереди, то есть взаимодействует с пользователем;
- backend — то, что сзади, изнутри, то есть серверная часть приложения.
Многие концентрируются только на первом и недооценивают важность второго. На самом деле, архитектура приложения важна не меньше, а то и больше оболочки:
- будет приложение тормозить или нет;
- выдержит нужное число пользователей или зависнет;
- насколько безопасно получится хранить данные;
Если приложение работает плохо, пользователю будет безразлична его красота и удобный интерфейс. Он уйдёт к конкурентам, и будет прав: никто не хочет вечно ждать загрузку или в сотый раз за день вводить пароль.
Разработка архитектуры приложения включает выбор используемых технологий, построение базы данных, API (через него приложение взаимодействует с сервером), интеграции CRM, CMS и много других технических нюансов. Если вы это не знаете — лучше даже не пытаться разобраться самому, а довериться профессионалу. И надеяться, что он выберет современные и надёжные инструменты, а иначе — проблемы в работе приложения заставят вас начать разработку с нуля или отдать его на доработку. Научить вас разбираться в архитектуре приложений за одну статью мы не можем. А вот создать для вас приложение — можем.
Помимо архитектуры, необходимо разработать оболочку приложения. Варианта два:
- кроссплатформенное решение — один код, который работает на разных операционных системах (iOS, Android, MacOS, Windows);
- нативное приложение — разрабатывается под конкретную операционную систему.
Первый вариант — универсальный, современный, позволяет сэкономить около 35% ресурсов на разработке (если вы запускаете iOS и Android), а также предоставить одинаковый пользовательский опыт на всех платформах.
Второй вариант позволяет добиться максимальной производительности, но расходы на разработку и поддержку будут существенно выше (т.к. над созданием работают несколько команд разработчиков, одна под каждую ОС).
Разница в производительности будет заметна только при использовании высоконагруженных технологий (вроде запуска моделей машинного обучения).
Для 99% бизнесов, кроссплатформенное решение – оптимальный по всем параметрам вариант.
Приложение готово, пора запускать! Так думают многие, но работает это по-другому. Сначала его нужно протестировать.
Тестирование проводится в два этапа:
Пользовательское тестирование
- проверить, соответствует ли дизайн макетам, на местах ли кнопки, читаются ли тексты;
- все ли функции работают как надо;
- как приложение отображается на разных операционных системах, устройствах и экранах.
Нагрузочное тестирование
- выдерживает ли приложение имитацию большого потока пользователей;
- выдерживает ли приложение имитацию атаки;
Эту работу обычно выполняют QA-специалисты (quality assurance, контроль качества).
Во время тестирования обычно вылезают какие-то ошибки — баги. Что-то не сработало или сработало не так. Их лучше исправлять до запуска приложения, чтобы не портить впечатление пользователей и не собирать отрицательные отзывы.
И только после нескольких итераций тестов, когда все баги найдены и исправлены, приложение готово к запуску. На этом история не кончается – после запуска приложение нужно поддерживать, исправлять какие-то мелкие недочеты, которые подметят пользователи, и добавлять новые функции, улучшать его.
К кому обратиться за разработкой приложения — зависит от того, насколько вы сами в этом разбираетесь и готовы контролировать каждый этап.