Наверное, вы не раз искали в маркетах мобильное приложение по какому-то ключевому слову, скачивали вариант без громкого имени, делали в нём несколько действий, после чего благополучно удаляли. А вы задумывались, почему? Скорее всего, оно не соответствовало вашим ожиданиям, имело не самый интуитивно понятный интерфейс и будто «тормозило». Это вполне объяснимо, так как часто приложения с узнаваемым брендом — детище продуктовой разработки. А заказчики, не захотев тратиться или ждать, отправили пользователям сырой и недоработанный продукт, — пишет tproger.ru.
В чём отличия заказной разработки мобильных приложений от продуктовой
Давайте разберёмся, в чём отличия продуктовой мобильной разработки от заказной и от разработки приложений в целом.
Продукт предполагает, что приложение бесконечно улучшается, меняется, при его модификации учитываются отзывы пользователей.
То есть одна из задач создания продукта — удовлетворённость целевой аудитории.
Заказной проект почти всегда ограничен бюджетом, временем, желанием «лишь бы уже сдать и успеть доделать другой проект».
И всё это очень напоминает сюжеты фильмов Тарантино: как всех обмануть, чтобы потом за это ничего не было.
Может ли это к чему-то привести?
Такое отношение к заказной разработке чревато потерей целевой аудитории, а вместе с ней и денег на дальнейшую работу с проектом. Да и оттока кадров, скорее всего, не избежать. Разработчики, которые ушли «от заказухи в проект» хвастаются, что теперь им работается гораздо комфортнее: нет постоянных переработок и очередных «хотелок», из-за которых приходится всё переделывать.
Но давайте оставим вопросы кадров HR-ам и поговорим о качестве разрабатываемых мобильных приложений.
Фичи
Вы замечали, как в продуктовой разработке внедряется функциональность? Сначала делаются базовые функции приложения, и уже после, от релиза к релизу к нему добавляются дополнительные модули и фичи. Причём перед тем, как приступить к реализации чего-то новенького, проводится анализ рынка и выясняется — а нужно ли это пользователю? Если нет, то принимается решение не тратить ресурсы на невостребованную функцию. Кроме того, всегда найдётся время на качественное тестирование. В крайнем случае сдвинут сроки релиза, но не допустят попадания недоделанного и непроверенного продукта к пользователям.
В заказной же разработке перечень функций часто диктует заказчик. И делает он это не основываясь на пользовательском опыте и анализе рынка, а просто потому, что «я знаю, что это гениально!» или «я у соседа такое видел». А аргумент, что сосед занимается продажей винтиков и гаек, а мы хотим людей клингонскому языку обучать, его не интересует. Также в заказной разработке часто встречаются накладки по времени и ресурсам — дата релиза уже запланирована, а iOS- или Android-разработчик внезапно ударился в буддизм, ушёл в горы, и заменить его, в общем-то, некем. Поэтому после экстренных поисков нового сотрудника мы получаем отставание от календарного плана в N дней, а фичи или даже основную функциональность приходится делать абы как, чтобы успеть в срок. Да и толком оттестировать приложение времени нет. И сырой продукт с багами уходит в маркеты. Как следствие — плохие отзывы, малое количество скачиваний, провальный для заказчика проект.
Юзабилити
Если в приложении нет вундервафли, но оно покрывает необходимые функции и удобно в эксплуатации — это лучше, чем если хитрых фич и «кружавчиков» много, но пользователь не может найти нужную кнопку или пункт в меню.
Есть довольно большой пользовательский опыт, который жизненно необходимо учитывать при разработке UIX. При этом следует помнить, что приложения должны быть нативными. Так что дизайнера, который рисует одинаковые компоненты для iOS и Android просто потому, что «нужно ж одинаково», гоните в Интернет или из проекта в зависимости от времени. Пользователь Android будет ядом самой гремучей змеи плеваться, если ему придётся выбирать время на iOS-ном барабане.
Приложения должны быть нативными. Дизайнера, который рисует одинаковые компоненты для iOS и Android, гоните в Интернет или из проекта.
Но есть и общие моменты, которые нужно учесть при реализации пользовательского интерфейса. И самый важный из них — старт приложения. Если пользователь видит белый экран, где ничего не происходит, а приложение в это время грузится, это очень смущает. Добавьте splash screen, причём без кучи текста — за несколько секунд его не успеют прочитать, и ощущение чего-то упущенного может остаться. Выберите что-то простое и лёгкое для восприятия.
Если в приложении предусмотрены поля ввода, крайне необходимо менять вид экранной клавиатуры. Если пользователь вводит e-mail, он не должен искать символ «@» на дополнительных вкладках. А если набирает номер телефона, предоставьте ему клавиатуру с цифрами и знаками «+», «*» и «#». Также правилом хорошего тона станет дублирование кнопок интерфейса «Ок» или «Далее» на экранной клавиатуре. А ещё учтите, что кнопка, спрятавшаяся за развёрнутой клавиатурой, действует на некоторых пользователей как красная тряпка.
Важный вопрос для проработки — как отображать ошибки, возникшие в приложении? Просто поставьте себя на место пользователя и подумайте: вам понятно, что произошло и что делать дальше? Если нет, то стоит переформулировать текст ошибки и описание дальнейших действий. И ни в коем случае не оставляйте системные ошибки и ошибки для разработчиков, которые введут пользователя в ступор. Придумайте заглушку или понятную обработку.
И последнее, о чём я напишу сегодня, — режим работы приложения офлайн. Если при потере интернет-соединения вашим приложением невозможно пользоваться, то как быстро вы потеряете аудиторию? Предусмотрите офлайн-режим для работы с частью функций, где это уместно.
Вывод
Есть ещё множество кейсов, которые мы не будем перечислять в этой статье.
Основной совет для разработки хорошего мобильного приложения такой: попробуйте посмотреть на своё приложение глазами пользователя. Вас что-то бесит? Кажется неочевидным? Тогда лучше пересмотреть реализацию или дизайн.
Конечно, при разработке продукта вы имеете гораздо больше времени и можете довести до ума даже незначительные мелочи. Но не стоит забывать, что «встречают по одёжке», и даже если ваше приложение не содержит в первом релизе какие-нибудь крутые фичи, им должно быть удобно и приятно пользоваться.
Исполнители, разрабатывайте любые мобильные приложения, будто это ваш продукт. В конце концов, отчасти так и есть. А заказчики, наберитесь терпения и не жадничайте там, где это неуместно. Сэкономив 100 тыс. рублей сейчас, вы можете потерять миллионы потом.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]