Важные мелочи при разработке мобильных приложений

Рассказывает Мария Г., аналитик SibEDGE

Наверное, вы не раз искали в маркетах мобильное приложение по какому-то ключевому слову, скачивали вариант без громкого имени, делали в нём несколько действий, после чего благополучно удаляли. А вы задумывались, почему? Скорее всего, оно не соответствовало вашим ожиданиям, имело не самый интуитивно понятный интерфейс и будто «тормозило». Это вполне объяснимо, так как часто приложения с узнаваемым брендом — детище продуктовой разработки. А заказчики, не захотев тратиться или ждать, отправили пользователям сырой и недоработанный продукт.

В чём отличия заказной разработки мобильных приложений от продуктовой

Давайте разберёмся, в чём отличия продуктовой мобильной разработки от заказной и от разработки приложений в целом.

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

То есть одна из задач создания продукта — удовлетворённость целевой аудитории.

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

И всё это очень напоминает сюжеты фильмов Тарантино: как всех обмануть, чтобы потом за это ничего не было.

Может ли это к чему-то привести?

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

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

Фичи

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

В заказной же разработке перечень функций часто диктует заказчик. И делает он это не основываясь на пользовательском опыте и анализе рынка, а просто потому, что «я знаю, что это гениально!» или «я у соседа такое видел». А аргумент, что сосед занимается продажей винтиков и гаек, а мы хотим людей клингонскому языку обучать, его не интересует. Также в заказной разработке часто встречаются накладки по времени и ресурсам — дата релиза уже запланирована, а iOS- или Android-разработчик внезапно ударился в буддизм, ушёл в горы, и заменить его, в общем-то, некем. Поэтому после экстренных поисков нового сотрудника мы получаем отставание от календарного плана в N дней, а фичи или даже основную функциональность приходится делать абы как, чтобы успеть в срок. Да и толком оттестировать приложение времени нет. И сырой продукт с багами уходит в маркеты. Как следствие — плохие отзывы, малое количество скачиваний, провальный для заказчика проект.

Юзабилити

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

Есть довольно большой пользовательский опыт, который жизненно необходимо учитывать при разработке UIX. При этом следует помнить, что приложения должны быть нативными. Так что дизайнера, который рисует одинаковые компоненты для iOS и Android просто потому, что «нужно ж одинаково», гоните в Интернет или из проекта в зависимости от времени. Пользователь Android будет ядом самой гремучей змеи плеваться, если ему придётся выбирать время на iOS-ном барабане.

Приложения должны быть нативными. Дизайнера, который рисует одинаковые компоненты для iOS и Android, гоните в Интернет или из проекта.

Но есть и общие моменты, которые нужно учесть при реализации пользовательского интерфейса. И самый важный из них — старт приложения. Если пользователь видит белый экран, где ничего не происходит, а приложение в это время грузится, это очень смущает. Добавьте splash screen, причём без кучи текста — за несколько секунд его не успеют прочитать, и ощущение чего-то упущенного может остаться. Выберите что-то простое и лёгкое для восприятия.

Если в приложении предусмотрены поля ввода, крайне необходимо менять вид экранной клавиатуры. Если пользователь вводит e-mail, он не должен искать символ «@» на дополнительных вкладках. А если набирает номер телефона, предоставьте ему клавиатуру с цифрами и знаками «+», «*» и «#». Также правилом хорошего тона станет дублирование кнопок интерфейса «Ок» или «Далее» на экранной клавиатуре. А ещё учтите, что кнопка, спрятавшаяся за развёрнутой клавиатурой, действует на некоторых пользователей как красная тряпка.

Кнопка, спрятавшаяся за развёрнутой клавиатурой, действует на некоторых пользователей как красная тряпка.

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

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

Вывод

Есть ещё множество кейсов, которые мы не будем перечислять в этой статье.

Основной совет для разработки хорошего мобильного приложения такой: попробуйте посмотреть на своё приложение глазами пользователя. Вас что-то бесит? Кажется неочевидным? Тогда лучше пересмотреть реализацию или дизайн.

Конечно, при разработке продукта вы имеете гораздо больше времени и можете довести до ума даже незначительные мелочи. Но не стоит забывать, что «встречают по одёжке», и даже если ваше приложение не содержит в первом релизе какие-нибудь крутые фичи, им должно быть удобно и приятно пользоваться.

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