внутри рамок самой идеи приложения и того, для чего ребенок скачал это приложение.

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

Путь от формулировки миссии и целей до сценариев может занимать от нескольких недель до нескольких месяцев (для крупных проектов).

После этого начинается традиционная разработка приложения. Но сначала вновь пересмотрите ваш MVP. Не добавили ли вы лишние листья к вашей кочерыжке?

Традиционная разработка приложения начинается с выстраивания юзабилити. Юзабилити (от англ, usability – «удобство использования») – это качественная оценка простоты и комфорта работы с сайтом. Пользователь легко находит нужную информацию, не теряясь в многочисленных функциях и кнопках. Желательно, чтобы при этом он испытывал еще и эстетическое удовольствие от пользования продуктом.

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

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

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

Натив или гибрид? Немного полезных технических знаний

Среди разработчиков мобильных приложений самые горячие споры сейчас ведутся вокруг нативной и гибридной платформ.

О чем спорят? Объясню, максимально упрощая.

В 2007 году Стив Джобс придумал iPhone, в 2008-м Apple дала возможность под него делать приложения – на определенном языке программирования. Когда Google выпустил Android, приложения под него стали писать на другом языке.

Это и есть нативная разработка – прикладная программа, которую можно использовать на определенной платформе или определенном устройстве. Для iOS используются такие языки программирования, как Objective-C и Swift, для Android – Java и Kotlin.

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

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

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

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

Чтобы понять плюсы и минусы, проведем дуэль.

Раунд 1: опыт пользователя (user experience, UX)

Если для вас критично, чтобы ваш пользователь испытывал приятные ощущения от приложения, чтобы ему было удобно, добавляем очки в пользу натива. Например, если у вас интернет-магазин, комфорт пользователя – на первом месте (об этом мы говорили выше). Он либо купит у вас, либо не купит. Иначе говоря, либо случится конверсия, либо нет.

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

Результаты поединка: 1–0 в пользу натива.

Раунд 2: использование функций телефона

Если приложению требуются функции смартфона: камера, акселерометр (более точный, чем GPS-датчик измерения ускорения) и т. д. – то вам потребуется натив.

Нативная платформа позволяет запускать приложение в фоновом режиме. Оно не открыто на экране смартфона, но при этом продолжает работать. Самый простой пример – шагомер.

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

Результаты поединка: по одному очку в пользу натива и гибрида.

Результаты поединка: 2–1 в пользу натива.

Раунд 3: сроки разработки

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

Результаты поединка: 2–2 – ничья.

Раунд 4: быстродействие

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

Результаты поединка: 3–2 в пользу натива.

Раунд 5: стоимость разработки

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

Гибридные приложения требуют минимальной адаптации к каждому устройству. Здесь гибриды обязательно победят.

Результаты поединка: 3–3. Ничья.

Подытожим еще раз.

Итак, как же выбрать?

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

Важный критерий выбора – бюджет. Иногда мы предпочитаем потратить немного больше на разработку трех совершенно разных версий, чтобы создать оптимальный UX.

В других случаях важнее выпустить первую версию продукта быстро и недорого.

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

Задайте себе следующие вопросы:

1. Является ли UX неотъемлемой частью приложения?

2. Важна ли скорость выхода на рынок? (Например, попытка попасть в Арр Store перед потенциальными конкурентами)

3. Нужны ли вам различные уникальные функции?

4. Ограничен ли бюджет разработки?

5. Будут ли пользователи и приложение много взаимодействовать, что потребует высокой производительности?

6. Должен ли я начать с MVP, а затем разработать версию с другими функциями?

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

Делать самому или выбрать исполнителя?

Это замечательно, если у вас уже есть слаженная техническая команда, обладающая нужными знаниями. Но что делать, если такой команды нет?

Вариантов всего