Мобильное приложение - сделано с любовью

Рассказываем, как наш клиент потерял 500 тысяч рублей на разработке мобильного приложения. И как мы исправляли эту ситуацию, создавая приложение, которое должно “всегда и у всех работать".

Примерно год назад представитель одной компании по оптовой продаже нефтепродуктов (бензин, дизель, мазут) обратился к IT-шникам "по объявлению", чтобы те создали удобное мобильное приложение для быстрого заказа топлива. В нём должно было быть отслеживание всех этапов доставки с пуш-смс-ватсап уведомлениями, включая карту с машинками "как в убере". На всё это навешивалось несколько ролей: клиент, менеджер, логист, водитель, бухгалтер и админ - и у каждого свои кнопочки и формочки.

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

Договорились, ударили по рукам - и уже через 2 месяца бодрые программисты выкатили веб-версию приложения, которая вроде как-то работала и формально даже почти удовлетворяла требованиям ТЗ, нооо... Проблема в том, что формальное "удовлетворяет ТЗ" и реальное "работает у всех и всегда” - это две большие разницы. Мало кто проверяет работу приложений на "маленьких" разрешениях и "старых" телефонах. Мало кто смотрит на версию прошивки Android или iOS. Не особо обращают внимание и на скорость работы приложения, а ведь лишние полсекунды на одно действие приводят к десяткам секунд, потраченных на ожидание за всю сессию, что уже очень сильно раздражает. Когда к этому добавляется еще и плохой UX/UI дизайн (а простыми словами - не продуманный интерфейс пользователя), то возникает ощущение дешевой подделки. Таким приложением не хочется пользоваться, оно вызывает только раздражение (и мысль о потраченных впустую деньгах).

В конце концов заказчику пришла правильная мысль: смириться, зафиксировать убытки, сделать выводы - и заказать это же приложение, но уже более вдумчиво, описав внятно и подробно все требования в техническом задании. Мы помогли ему с этим шагом, и приступили к работе над приложением только тогда, когда ТЗ было полностью согласовано и подписано обеими сторонами. В качестве фреймворка выбрали React Native, поскольку он использует те же компоненты, что и обычные приложения для iOS и Android.

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

В первую очередь хочется сказать, что ОБЯЗАТЕЛЬНО должно присутствовать в приложении:

1. Высокая скорость работы

2. Удобство интерфейса (UX/UI)

3. Информативность

4. Разумное(!) дублирование

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

Идея дублирования элементов управления в самолетах жизненно необходима! И она вполне применима к интерфейсу мобильного приложения. Даже если у пользователя поврежден экран и тач не работает в определенной зоне, всегда есть возможность ткнуть в другую область и получить желаемое.

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

Есть еще одна сторона в дублировании, которая зачастую остается невидимой для пользователя: любая функция должна уметь работать при отсутствии интернета. Как только пропадает связь, все сразу начинают нервничать. Бывает, ты уже заполнил 100500 полей, и сидишь с досадой смотришь на этот крутящийся кружочек, который не дает ничего больше делать в приложении, понимая, что всё придется заполнять заново. Конечно должно быть всё гладко и бесшовно: при критических операциях ненавязчиво уведомлять об отсутствии связи, не мешая работать дальше, а в остальных случаях просто выполнить отложенные действия сразу при появлении интернета.

Мы не можем похвастаться большим отделом крутых дизайнеров, но, как правило, нас выручает простой принцип: "Красота - это отсутствие лишнего".

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

Вот такой набросок у нас был в самом начале работы над интерфейсом пользователя:

А вот что из этого вышло в итоге:

Мы уложились в бюджет 480 т.р., и 2.5 месяца у нас ушло на весь основной функционал. А кроме самого приложения (благодаря использованию Python/Django на сервере) наш клиент получил в подарок админский интерфейс для управления всеми объектами, которые есть в системе:

Вторым "подарком" от нас была версия приложения с тёмной темой:

Ну кто не любит подарки? А для нас очень приятно слышать слова благодарности.

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

Видео с обзором функционала основных ролей:

Мобильное приложение - это просто, удобно, надежно и функционально. Но только в том случае, если вы доверяете работу профессионалам, и внимательно относитесь к составлению ТЗ ;)