Какая информация представлена в разделе каталог мобильного приложения
Практическое руководство от команды студии мобильной разработки Winfox для тех, кто начинает делать свое приложение.
Что именно входит в создание приложения? Вопрос, который нам чаще всего задают клиенты. Они хотят знать, сколько денег и времени от них потребуется, как строится работа, с чего начать и как в результате заработать, а не потерять.
Этот важный вопрос, на который нельзя ответить в двух словах, вдохновил нас на публикацию этого цикла статей. В них не будет туманных советов из серии «как сделать приложение: три простых шага». Зато будет опыт, накопленный нами за пять с лишним лет работы на рынке мобильной разработки, примеры из практики и руководство к действию.
В предыдущих материалах мы рассказывали:
Сейчас поговорим о том, как строится работа над созданием мобильного приложения: что включает в себя этап аналитики и что должно быть в техническом задании.
Мы в студии обычно строим работу так:
- аналитика;
- техническое задание;
- проектирование и дизайн;
- разработка;
- тестирование и стабилизация;
- публикация в сторах;
- поддержка и развитие.
Каждый проект — особенный. Для одного можно объединить несколько этапов в один, чтобы реализовать задуманное быстрее и дешевле. Для другого целесообразно пройти все этапы. Мы поможем выбрать оптимальный путь.
Каждое приложение начинается с идеи. Вы рассказываете нам, какие задачи должен решать будущий сервис, и мы приступаем к сбору аналитики. Глубокий срез рынка, анализ уже существующих решений, изучение конкурентов и моделей поведения покупателей… На каждом этапе анализа мы помним о конечном пользователе и продумываем жизненный цикл клиента. Это помогает нам вместе понять, как люди будут использовать новое приложение — и сделать его максимально удобным, понятным и полезным. Такой сервис принесет пользу и вашему бизнесу.
Что в результате: референсы по функциональности и дизайну.
Аналитика — принципиально важный этап. Не надо от него отказываться и начинать работу над проектом с технического задания. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать. Мы обычно собираем лучшие практики и предлагаем клиенту проверенные решения, которые 100% сработают.
Мы составляем подробное описание функциональности и дизайна будущего приложения. Определяем персонажи пользователей, описываем пользовательские истории (User Story), составляем карту путешествия пользователей (Customer Journey Map) и формируем технические требования к сервису. То есть фиксируем, каким должно быть приложение, что оно должно уметь и как это будет работать.
Благодаря такому техническому заданию (ТЗ) наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею.
Что в результате:
- перечень функций, которые должны быть в приложении;
- требования к интерфейсу, ролям пользователя, безопасности, производительности и другие нефункциональные требования;
- описание того, как будут реализованы все эти требования;
- смета проекта.
Пользовательские истории (User Story) пошагово описывают, как пользователь ведет себя в приложении: проходит авторизацию, просматривает каталог, оформляет заказ, совершает покупку. Такая история описывает задачу пользователя, которую он решает с помощью и приложения, и его конечную выгоду. В результате мы получаем список требований, который позволяет определить функциональность будущего приложения и сделать его максимально удобным для пользователя.
Допустим, вы хотите сделать приложение, с помощью которого можно будет распечатывать фотографии как фотоальбом. Основными пользовательскими историями будут создание аккаунта, выбор фотографий из фотогалереи, выбор размера альбома, оплата за альбом с помощью карты, доступ к истории заказов. Мы всегда работаем над пользовательскими историями всей командой и обязательно вместе в заказчиком. Это помогает продумать все нюансы и взглянуть на всю систему целиком, а в будущем избежать сложностей на этапе проектирования и разработки.
Карта путешествия пользователя (Customer Journey Map) позволяет наглядно представить, как разные персонажи будут пользоваться приложением в каждой из пользовательских историй. На такой карте виден весь путь пользователя — перемещение между экранами и клики на кнопки.
Составление карты помогает понять, как технически реализовать все функции приложения.
Мы делаем карту путешествия пользователя в Miro. Вся команда может работать над картой в реальном времени, а заказчик — смотреть результат в режиме презентации.
У каждой студии разработки свой подход к составлению этого документа. Мы считаем, что для успешной реализации проекта в нем должно быть отражено следующее.
1. Общие сведения:
- цель создания сервиса;
- совместимость с платформами: это будет приложение для iOS, Android или других платформ;
- масштабируемость: умеет ли приложение быстро адаптироваться к внезапным изменениям и пиковым нагрузкам, например к росту числа пользователей или объема передачи данных;
- отказоустойчивость: должно ли приложение продолжить свою работу, если откажет один или несколько его компонентов.
2. Функциональные требования к приложению:
- роли пользователей: какие уровни доступа должны быть у разных пользователей, например у гостя и авторизованного пользователя;
- форматы данных: как будет реализован обмен данными в приложении;
- интеграция: должно ли приложение поддерживать совместную работу с другими сервисами, например с платежными системами и почтовыми серверами;
- интерфейсы доступа: как приложение будет обмениваться данными с внешними сервисами;
- дополнительные функции: должно ли приложение уметь что-то еще, например работать с файлами или библиотеками шифрования;
- конфигурация и администрирование: с помощью каких элементов администратор будет управлять приложением;
- состав системы: из чего состоит мобильное приложение, то есть экраны, пуш-уведомления, система аутентификации и т.д.
3. Нефункциональные требования к приложению:
- безопасность: требования к безопасности приложения;
- логирование: нужно ли системе формировать и сохранять отчеты об ошибках, которые возникли при работе приложения, и для каких типов событий это надо делать;
- производительность: требования к работе приложения, например к скорости работы базы данных;
- требования к аппаратному обеспечению сервера: перечень технических характеристик.
4. Реализация функциональности приложения:
- экран загрузки;
- регистрация и авторизация;
- основной экран;
- меню;
- поиск;
- …
- уведомления.
Не отказывайтесь от этапа аналитики. В процессе анализа мы понимаем, кто есть на рынке, на кого ориентироваться, а как лучше не делать.
Благодаря грамотно составленному ТЗ наша команда дизайнеров и разработчиков четко понимает, какой сервис хочет получить заказчик, и поэтапно реализует первоначальную идею. Чтобы правильно составить ТЗ, используйте наш чек-лист.
В следующем материале мы расскажем, что нужно знать заказчику про проектирование, дизайн и разработку.
Этот цикл статей основан на книге, которую мы недавно сделали для своих клиентов. В этой книге мы постарались ответить на основные вопросы, которые у них возникают:
- как понять, что моему бизнесу нужно мобильное приложение;
- для чего компании делают свои мобильные сервисы;
- сколько стоит разработка и как на ней сэкономить;
- как строится работа над мобильным приложением;
- с кем лучше работать — с фрилансером или студией;
- что делать после того, как приложение готово.
Остались вопросы? Не согласны с нами? Хотите высказать свою точку зрения или поделиться опытом? Пишите в комментариях. Давайте обсуждать!
Здравствуйте, у кого нибудь есть ответы в академии бристоль? Можете помочь пожалуйста
Не могу пройти тест в мобильном приложение на 10 тестов
Кто-нибудь может скинуть ответы на академию бристоль
Здравствуйте, у кого нибудь есть ответы в академии бристоль? Можете помочь пожалуйста
Рассмотрим основные моменты на наш взгляд по реализации мобильного приложения на платформе 1С. В качестве примера будем использовать приложение для просмотра данных по результатам тестирования для конфигурации «Тестирование 3.0».
Приложение доступно в Google Play (поиск выполняйте по словосочетанию «Тестирование 3.0: Отчеты» или по ссылке в конце статьи). Оно предназначено для отображения результатов тестирования на мобильном устройстве совместно с конфигурацией "Тестирование 3.0".
1. Демонстрационный режим
Для демонстрации работы и возможностей приложения мы добавили режим - «демо». В этом случае приложение для построения отчетов и графиков использует сохраненные заранее в макете данные и не требует соединения с сервером.
Технически данные для демонстрации хранятся в плоской таблице с двумя колонками «url» и «текстовые данные». Пример таблицы можно увидеть на рисунке ниже.
В функции выполнения запроса вставили проверку на наличие режима и при положительном условии сразу возвращаем данные из макета по соответствию url запроса. В случае отсутствия соответствия возвращается пустая строка, что может соответствовать ошибке.
Данный функционал удобно использовать при прототипировании интерфейса приложения, выполнения отладки, тестирования.
2. Авторизация
1С пока не поддерживает windows авторизацию в мобильном приложении, поэтому для обеспечения безопасности и подключения к серверу внутри сети предприятия мы используем VPN-канал (any-connect или другое приложение). Если без VPN, то рекомендуем обязательно использовать SSL.
На форме «Авторизация» мы реализовали сохранение настроек входа в приложение, что позволило упростить процедуру ввода необходимых данных. Доступны следующие комбинации:
а) сохраняются автоматически последние введенные данные после успешного входа и всегда отображаются при запуске (сервер, имя базы, логин, ssl);
б) при включении настройки «сохранять пароль» будет сохраняется пароль пользователя.
3. Дизайн форм приложения
Мобильное приложение должно иметь дизайн, позволяющий комфортно обрабатывать информацию.
Шрифт не должен быть мелким, в таблицах не должно быть излишнее число колонок, число элементов управления должно быть минимальным (два блока оптимально). Глубина операции не должна быть излишней (кликабельность) - оптимально не более 3х.
Отображение форм должно быть простым, а не перегруженным и излишне сложным. Ниже на картинке приведен пример в сравнении «сложной» формы с «легкой».
Раскройте все опции сразу
Адаптируйте приложение к изменению положения экрана (вертикально или горизонтально).
4. Получение данных
Мы используем для обмена информацией SOAP, REST сервисы. При разработке удобно использовать технологию REST (нет жесткого описания формата данных).
Был выбран «JSON» формат для передачи данных. С ним довольно легко работать. Тип передаваемых данных всегда структура. У структуры обязательно определено несколько основных полей – «ТипОбъекта», «Проверка», «Дата». Свойство «ТипОбъекта» используется для идентификации режима отображения и может содержать следующие значение: График, Таблица, HTML.
Приведем пример кода для преобразования ответа сервера из формата «JSON» в стандартный тип данных 1С (см. справку для более подробной информации):
5. Фоновое получение и обновление данных
Если предполагается получение большого объема данных, то чтобы не было зависаний в приложении используем фоновые задания для получения или обработки данных, т.е. асинхронно.
Реализовать это удалось, связав механизм фоновых заданий, хранилище настроек и обработчик ожидания. Логически процесс работы с фоновыми заданиями выглядит стандартно:
а) при открытии формы мы проверяем режим получения данных. Если асинхронно, то запускаем фоновое задание, в качестве ключа передаем имя формы.
б) запускаем фоновое задание и в хранилище настроек пишем признак того что задание запущено и не выполнено. Функция в фоновом задании по завершению в хранилище настроек записывает результат по переданному ранее ключу.
в) далее подключаем обработчик ожидания с минимальной длительностью в «0.1 с». (если канал хороший и данных не очень много, то синхронный режим справляется замечательно и быстрее чем с фоновым)
в) в функции при выполнении обработчика ожидания проверяем наличие в хранилище настроек признака выполнения по ключу.
Интерфейсно мы сначала активируем вкладку «знак загрузки» и показываем знак длительной операции, а потом по готовности данных переключаемся на вкладку с данными. Картинка ниже демонстрирует описанную схему.
6. Получение информации по изменению ориентации экрана
Для определения события изменения ориентации необходимо использовать функцию формы «ПриИзмененииПараметровЭкрана».
Для получения информации о текущем состоянии окна – вертикально или горизонтально используем функцию «ПолучитьИнформациюЭкрановКлиента». Приведем немного кода в качестве примера:
7. Использование таблиц и большого количества отображения данных
Фильтруйте данные, отображайте постраничный вывод – это позволит повысить отзывчивость приложения и упростит визуальную обработку информации пользователем.
На формах с таблицами используем фильтр с опциями: «все», «только ошибки», «только падения», «только пропуски».
Мы используем ограниченное количество колонок, все служебные поля обязательно скрываем. Подробную информацию выводим только в детализации.
8. Глобальные параметры, настройки
Практически всегда требуется использовать по отдельности или все вместе: какие-либо глобальные опции, настройки, сохранение значений реквизитов на управляемых формах (в мобильном приложении пока нет автосохранения реквизитов). Для решения всех этих задач совместно реализован механизм описанный в п.12.
В нашем приложении мы используем глобальный параметр «Тестируемый клиент». В десктопном приложении, мы выводили его в верху формы, и пользователь мог спокойно выбрать его или изменить, но в мобильно приложении существует проблема размещения. Поэтому мы вынесли эту настройку, а изменение значения реализовали в отдельной форме. Перейти к нему возможно из пункта меню.
Дополнительно, если пользователь не будет заходить при первом запуске системы в настройки приложения, то мы реализовали при открытии формы переадресацию на форму выбора текущего тестируемого клиента.
9. Используем иконки вместо текста
При отображении информации, особенно в табличном представлении мы сталкиваемся с ограничением в количестве колонок, особенно в вертикальном положении экрана. Поэтому удобно использовать картинки вместо слов – это выгодно экономит пространство и более наглядно.
В нашем приложении для информирования:
- о результатах последнего теста используем следующую картинку: (пропуск, успешно, в работе, ошибка, провал)
- о результатах сводке за последние 5 заданий - картинки в форме перехода от солнышка к тучкам
10. Использование цветов на диаграммах и графиках
Необходимо использовать устоявшиеся цвета и обозначения. В нашем приложении на диаграммах используется следующая цветовая маркировка (см. рис. ниже): успешно – зеленый, провал – красный, ошибка – желто-оранжевый, пропуск – серый.
Не стоит использовать произвольные цвета или обратные. К примеру, для понятия «да» использовать красный цвет или иной не подходящий, а для «нет» использовать зеленый.
11. Используем АБ-тестирование
Используйте АБ-тестирование для определения выбора варианта дизайна форм
12. Используем поле HTML
Иногда удобно использовать поле html для отображения информации. Мы в нашем приложении используем данный вариант в сводке по дефектам - для вывода общей информации по тестам с ошибками.
13. Сохранение настроек и параметров
Пока в мобильных приложениях нет функционала сохранения настроек на формах, реквизитов в формах и хранилища общих настроек. Поэтому для решения этого вопроса мы создали свое решение:
а) создали регистр сведений «ОбщееХранениеНастроек» (измерения: КлючОбъекта, КлючНастроек,Пользователь и ресурсы: Настройки (хранилище значения));
б) написали три функции в общем модуле «УправлениеОбщимХранилищемНастроек» – СохранитьНастройкиПользователя, ЗагрузитьНастройкиПользователя, УдалитьНастройкиПользователя (код функций тривиальный – запись значения в регистр сведений, чтение и удаление по параметрам);
Используем этот функционал практически везде: для сохранения настроек авторизации, передачи параметром от фонового задания инициатору и сохранению реквизитов, сохранения настроек отображения форм и др.
14. Демонстрация бета версии и сбор замечаний от первых пользователей
Оформляем приложение и запускаем его использование в ограниченном кругу лиц. В результате получаем первые отзывы по юзабилити, недостатках и другие советы, и замечания. В этот круг могут входить коллеги (заинтересованные лица), можно дать жене, детям, тете или дяде (не заинтересованным лицам).
По результатам обратной связи мы уже изменили некоторый функционал и внесли доработки в интерфейс. Также будем ждать отзывов и советов сообщества.
Каждый год популярность мобильных приложений только растет — с помощью нескольких нажатий пальцем мы заказываем продукты и одежду, покупаем авиабилеты и записываемся на прием к врачу. Если вы уже хотите разработать приложение, сейчас самое время для его создания — удобный, быстрый и бесконтактный сервис в следующие несколько лет будет как никогда кстати.
В статье рассказываем про основные этапы и принципы разработки приложений — от аналитики и тестирования до выхода на рынок.
Основные стадии разработки мобильного приложения
Любой проект важно начинать с детального планирования, изучения собственного бизнеса, аудитории и конкурентов. Чем качественнее будут исследования, тем меньше проблем и доработок будет в дальнейшем.
Аналитика
Во время исследования определите цели бизнеса, изучите аудиторию и каналы коммуникации, проанализируйте конкурентов — это поможет определиться с правильным позиционированием. Аналитика обычно включает в себя интервью с руководителями и клиентами, фокус-группы и экспертную оценку.
Такая подготовка поможет собрать все требования и упаковать их в понятные визуальные модели: схемы бизнес-процессов, майнд мэп, пути пользователей, чтобы определить основы для разработки и перейти к прототипу.
Варианты монетизации
Приложение — еще один способ увеличить прибыль, так что еще на берегу продумайте схему монетизации, чтобы учесть ее при создании интерфейса.
Определиться с монетизацией помогут наводящие вопросы:
- Какую проблему решает сервис?
- За какие возможности люди готовы будут заплатить?
- Сколько у вас есть времени для монетизации? Можно ли подождать, чтобы набрать базу клиентов?
Какие способы монетизации бывают:
Продвижение
Без маркетинговой стратегии даже самое перспективный проект канет в пучину небытия. Позаботьтесь о продвижении в начале, чтобы к моменту реализации приложение уже было в виш-листе покупателей.
Рекламироваться можно с помощью таргетированной рекламы, нативных материалов в СМИ и блогах, партнерских программ и виральных техник. Распишите портрет своей аудитории, изучите способы продвижения конкурентов, составьте собственную стратегию и меняйте ее в зависимости от обстоятельств.
Техническое задание в процессе создания мобильного приложения
После аналитики и проработки стратегии развития наступает процесс создания мобильного приложения, на первоначальном этапе которого изучается техническая документация и готовится техническое задание.
Обычно в нем прописываются:
- Цели проекта.
- Пользовательские истории и карта путешествия человека — описывают, какие задачи будут решать люди с помощью сервиса, и как они будут это делать.
- Обязательные функции.
- Технические требования к интерфейсу, производительности, роли пользователей, безопасности.
- Реализация функциональности: UX и UI дизайн.
- Этапы разработки.
- Время, необходимое, для всех работ.
- Бюджет.
Описание требований к интерфейсу помогает дизайнерам и разработчикам понять, что именно хочет клиент и как это можно выполнить. Чем подробнее будет ТЗ, тем выше шанс получить то, что действительно нужно и избежать бесконечных правок.
Чаще всего студии разработки помогают с подготовкой ТЗ. Например, в AppCraft мы всегда проверяем ТЗ на соответствие требованиям платформ и разрабатываем его с нуля, если у вас не хватает на него времени или возникли какие-то сложности.
Организация команды
Обычно в состав выделенной проектной команды входят: тестировщик, UX\UI дизайнер, мобильные разработчики, — количество зависит от масштаба проекта — и проектный менеджер, который организовывает работу команды.
Мы в AppCraft никогда не привлекаем для работы внешних специалистов, потому что выбираем работать с проверенными временем людьми и плотно общаться внутри команды. У такого подхода есть большой плюс — каждый сотрудник сфокусирован на конечном продукте и заинтересован сделать свою работу качественно.
Создание дизайна и прототипа
На этом этапе UX/UI дизайнер выстраивает логику взаимодействия между страницами экранов регистрации и авторизации, заполнения данных, личного кабинета, корзины, оплаты покупки и отслеживания заказа. Разрабатывает внешний вид будущего сервиса в соответствии с техзаданием и фирменным стилем: подбирает цветовое решение, шрифты, отрисовывает иконки, кнопки, пуш-уведомления, слайдеры и т.д.
После согласования дизайна, дизайнер готовит прототип (если это не было сделано на этапе подготовки ТЗ) — в нем воспроизводится базовая логика, структура и функционал.
Подробнее о прототипах в этой статье.
Разработка
Одна из трудозатратных стадий включает написание кода, проработку архитектуры и делится на Back-end и Front-end разработку. Мобильные разработчики должны знать концепцию проекта, его уникальность и включаться во все процессы, чтобы оценить жизнеспособность идеи и реализовать желания заказчика.
На этом этапе Front-end программисты разрабатывают продуманный и протестированный клиентский интерфейс и логику платформы.
Back-end разработчики создают сервер для хранения и обмена информации. Специалисты выбирают язык программирования для написания кода и хостинг для сервера и API, выстраивают систему управления базой данных. Чем лучше выбраны параметры, тем быстрее будет работать приложение.
Разработка может быть реализована несколькими способами:
- Нативная. Разрабатывается отдельное приложение для каждой мобильной платформы. Этот способ самый дорогой, но надежный: вы получите полную поддержку от сторов, а интерфейс будет работать быстро и выглядеть максимально органично.
- Кроссплатформенная. Разработчики используют универсальный код под все платформы, но операционная система все равно запускает его как нативное. Самый оптимальный вариант в плане «цена-качество».
Подробнее о плюсах и минусах нативной и кроссплатформенной разработки писали в этой статье.
Тестирование
Некоторые компании выделяют тестирование в отдельный этап и досконально проверяют приложение только перед релизом.
Мы думаем, что тестирование приложения нужно проводить на каждом этапе разработки — по готовности каждой части функционала. Лучше потратить больше времени на исправление багов до релиза, чем каждый час получать негативные отзывы на странице после публикации в сторе. Поэтому каждую страницу тестируем настолько часто, насколько это возможно.
Публикация
Перед запуском важно внимательно изучить правила Google Play Store и Apple App Store и подготовить скриншоты страниц, маркетинговый план и описание. После загрузки сторы проверяют всю информацию, актуальность проекта и дают заключение: будут они публиковать приложение или нет. Если все прошло удачно, его можно будет скачивать через несколько дней.
С публикацией могут возникать трудности, поэтому действительно важно ознакомиться со всеми правилами магазинов. В AppCraft проектные менеджеры не оставляют клиентов со всем этим наедине: помогают с публикацией приложения и консультируют по всем вопросам, связанным с регистрацией аккаунтов в магазинах, требованиями к материалам и их форматам.
Доработка и техподдержка
После запуска вы сможете анализировать, какие разделы самые популярные, а какие не очень, сколько человек завершили целевые действия, а какие страницы стоит доработать. Внимательно изучайте и обрабатывайте все входящие данные: они помогут дорабатывать приложение и убирать ненужные функции. Процесс аналитики практически бесконечен, так что вам понадобится техническая поддержка, которая будет фиксировать и оперативно решать текущие проблемы, оптимизировать приложение и дорабатывать его.
В Appcraft гарантийная поддержка кода — 12 месяцев. Мы полностью передаем заказчику права на приложение, но продолжаем мониторить системную аналитику и оперативно устраняем неполадки в приложении, если они вдруг возникают.
Может быть интересно
В этой статье писали о особенностях разработки приложений android с нуля.
Описанные этапы — классический вариант процесса разработки, но мы всегда обсуждаем этот процесс отдельно с каждым новым клиентом. Потому что для нас важно синхронизироваться с заказчиком и сделать так, чтобы процесс разработки был удобным и понятным.
В AppCraft мы занимаемся всеми этапами разработки от аналитики (базовой первичной аналитики или глубоких исследований) до релиза и обеспечиваем оперативную техподдержку. За 10 лет мы создали несколько собственных проектов и больше 200 мобильных приложений для клиентов — мессенджеры, корпоративные решения, банковские системы, e-commerce и соцсети.
Если вы решили, что вам нужно мобильное приложение — подумайте ещё раз. Будет ли оно решать ваши задачи? Есть ли в нем то, чего нет ни в одном существующем продукте? Готовы ли вы заниматься его продвижением и поддержкой? Есть сомнения — пишите нам. Мы поделимся опытом и знаниями. Если уверены в своем решение — тоже пишите. Мы проконсультируем по всем вопросам и превратим вашу идею в полноценный продукт, который поможет поддерживать общение с клиентами и увеличит прибыль.
5 способов увеличить прибыль в приложении с помощью UX-дизайна
Покупатели просматривают каталоги и предложения в мобильном приложении, но не все пользователи доходят до покупки? В статье рассказали как с помощью дизайна улучшить пользовательский опыт и увеличить продажи.
Свяжитесь с нами
Хотите получить бесплатную консультацию о разработке мобильного приложения?
Мы сможем сразу дать ориентировочную оценку проекта по стоимости и срокам, если Вы кратко опишите его основную идею и функции.
Заполните заявку или позвоните нам
Тоже интересно
Юзабилити-аудит мобильных приложений
Создание мобильных приложений для банков: функции, этапы разработки и тренды 2021
Разработка мобильных приложений в финансовой сфере — одно из популярных направлений в 2021 году. По данным Insider Intelligence, 89% пользователей банковских услуг пользуются мобильным банкингом — в основном это поколение миллениалов и поколение X от 20 до 55 лет. Мобильное приложение позволяет полностью заменить или снизить нагрузку на отделения банков, уменьшить затраты на аренду помещений и персонал и повысить лояльность клиентов.Мобильные приложения: виды и принципы работы
По данным eMarketer, люди всё больше времени проводят в телефонах, и в ближайшее время тенденция будет только нарастать — по прогнозам, в 2022 году люди будут сидеть в смартфонах по 4 часа в день, и 88% этого времени проведут в приложениях. В статье разбираем типы мобильных приложений, принципы их работы и отличия от веб-сайтов.
Разработка мобильных приложений для медицинских центров, медклиник
По результатам исследования Ricoh Research,79% пациентов отдают предпочтение клиникам с удобными сайтами и приложениями — они вызывают доверие и помогают сократить время на запись к врачам и заполнение документов. В статье мы описали особенности и шаги разработки приложений в сфере медицины опираясь на наш десятилетний опыт разработки.Контакты
- 107140, Москва, ул. Русаковская, 1, оф. 306
- 390006, г. Рязань,
пр. Речников, 21–1
150 тысяч новых приложений регистрируют в App Store и Google Play каждый месяц. Привлечь внимание пользователей и добиться коммерческого успеха помогает продуманный дизайн мобильных приложений. Так, согласно исследованию McKinsey, в компаниях с хорошим дизайном рост выручки больше на треть.
О том, какие знания и навыки нужны дизайнеру приложений, как создаётся мобильное приложение, что нужно учитывать при разработке, рассказывает Алексей Комаров, UX/UI-дизайнер в IBM и преподаватель Нетологии на курсе «Дизайнер мобильных приложений».
Алексей Комаров
UX/UI-дизайнер в IBM
светлана третяк
Дизайнер приложения отвечает за эмоции от использования продукта. Для реализации этой задачи дизайнер должен создавать не только привлекательный визуальный облик, но и уметь выяснять потребности пользователей с помощью исследований, составлять навигационную модель (как связаны экраны приложения), проектировать интерфейс (расставлять по важности иерархию компонентов).
Давайте разбираться с самого начала.
Что нужно знать мобильному дизайнеру
Колористика
— искусство сочетания цветов.
Например, вместе не рекомендуется использовать зелёный и красный — насыщенные цвета, которые как бы перекрикивают друг друга. Получается вырвиглазный интерфейс, отсутствует контрастность и объекты трудно различить на экране. Для несочетаемых цветов дизайнеры даже придумали определение «зелубой» (зелёный + голубой).
Для подбора цвета часто используют специальные палитры или цветовые круги — например, Material palette, Adobe Color.
Также можно брать на заметку палитры готовых продуктов. Например, в Америке существует определённый культ кроссовок, где их покупают не ради замены старой пары, а, скорее, с эстетической точки зрения. Поэтому некоторые экземпляры можно назвать источником вдохновения для дизайнеров, которые используют цветовые схемы кроссовок для своих продуктов.
Сервис Coolors позволяет создавать цветовую палитру по фотоТипографика
— умение оформлять текст при помощи набора и вёрстки.
По сути дизайн — это оформление контента, 80% которого передаётся через текст. Любая информация располагается в виде иерархии — главная и второстепенная части, которые выделяются с помощью определённой стилизации текста.
Например, уровни заголовков — заголовок 1-го или 2-го уровня — различаются по размеру шрифта и служат навигацией, а также делают материал структурированным.
Выравнивание по левому краю придаёт тексту аккуратный вид — его легче воспринимать. Строки начинаются на одном уровне, и глаз быстро находит начало следующей строки — удобно и быстро привыкаешь.
Композиция
— умение грамотно управлять объектами в пространстве. Какие размеры объекта, отступы между объектами и краями экрана, расстояния и связи между объектами позволят создать гармоничную композицию для лучшего восприятия объектов.
Если говорить о том, как колористика, типографика и композиция влияют на поведение пользователя и эффективность интерфейса, то стоит упомянуть про четыре типа нагрузок.
Когнитивные нагрузки — усилия, которые прикладываем, чтобы распознать объект, логику его работы и принять решение о дальнейших действиях. Например, понимаем, что перед нами кнопка, а не округлый прямоугольник, и на эту кнопку можно нажать, чтобы попасть на нужный экран.
⇒ Чем больше мозгу требуется усилий для определения объекта, тем больше мы устаём.
Визуальные нагрузки — усилия для определения объекта на экране по визуальным признакам (круг, небо, кошка) и выделения его среди других.
⇒ Чем больше объектов в интерфейсе, тем больше мы устаём.
Моторные нагрузки — возникают при физическом контакте с интерфейсом: свайп, тап и другие.
⇒ Чем больше жестов управления интерфейсом и чем они сложнее, тем больше мы устаём.
Внешние нагрузки — возникают при взаимодействии пользователя с приложением (собака залаяла, машина проехала, пошёл дождь). Эти нагрузки сложно точно предугадать — можно лишь предположить, в каких условиях будет использоваться приложение чаще всего.
⇒ Чем больше отвлекающих моментов, тем больше мы пытаемся сосредоточиться и быстрее устаём.
Все типы нагрузок идут в связке, влияя друг на друга.
К примеру, если приложение предназначено для пожарных, которые часто находятся в стрессовых ситуациях, нужен максимально понятный интерфейс — у них нет времени разбираться в чём-то сложном. А если пользователь — офисный сотрудник, который заходит в приложение, чтобы убить время по дороге на работу, то можно добавить больше контента или функций, чтобы пользователь увлёкся и провёл в приложении больше времени.
Инструменты
Из графических редакторов сейчас популярны Figma, Sketch или Adobe XD.
Figma
Кросс-платформенный онлайн-редактор, который работает на Windows, macOS, Linux. В нём можно работать всей командой, в том числе с заказчиками. Бесплатный для одного пользователя и платный для работы с командой, если нужно видеть все действия команды, а не только за последние 30 дней.
Sketch
Платный графический редактор для macOS. Плюс Sketch в том, что на рынке он дольше Figma, поэтому в некоторых случаях возможностей и интеграций для него находится больше. Но если вы фрилансер, работать с заказчиками будет непросто, поскольку это не кросс-платформенный инструмент. В Sketch можно работать в офлайне.
Adobe XD
Приложение Adobe для проектирования интерфейсов. Плюсы и минусы аналогичны Sketch, кроме того, что в Adobe XD есть возможность создавать голосовые прототипы при помощи Amazon Alexa. XD заметно менее популярен по сравнению с Figma и Sketch.
Графические редакторы достаточно похожи, поэтому, если освоить один инструмент, то изучение другого не займёт много времени.
Из других инструментов дизайнера можно отметить:
В этом сервисе удобно делать брейнстормы, обсуждения, прорабатывать гипотезы, проектировать навигацию с помощью mindmap и создавать Customer Journey Map.
Сервисы для создания прототипов
Помимо встроенного прототипирования в Figma, Sketch или Adobe XD дополнительно используют такие решения, как InVision, Marvel, ProtoPie, Flinto, Principle for Mac.
Цели и задачи разработки
Дизайнер должен понимать, какие задачи у бизнеса и для кого предназначено приложение.
Приложение — это инструмент бизнеса со своими целями и задачами.
Для примера рассмотрим мобильное приложение банка.
снизить расходы на обслуживание клиентов в отделениях и повысить средний доход на одного клиента.
контролировать свои расходы.
создать дистанционный канал поддержки клиентов и увеличить продажи банковских продуктов.
При разработке приложения всегда учитывают требования бизнеса, задачи пользователей и возможности технологий.
Можно сделать великолепный дизайн, но он не будет решать задачи компании или разработчики не смогут его реализовать. Например, бывает, что бизнес выдвигает гипотезы, не проверяет их на этапе исследования и сразу отправляет в разработку. Получается функциональность, которая никому не нужна, при этом время и деньги потрачены впустую.
Бывает, что ресурсы безрезультатно тратятся не только на бесполезные фичи, но и на приложение.
К слову, если интересуетесь культурой стартапов, в целом (есть утрированные моменты) она хорошо показана в сериале «Кремниевая долина». Его рекомендует к просмотру и Билл Гейтс: «Продюсеры и сценаристы проводят много исследований перед каждым новым сезоном шоу. В прошлом году я был одним из нескольких людей, с которыми они встретились, чтобы поговорить об истории отрасли и рассказать о некоторых своих идеях для пятого сезона».
Soft skills
Коммуникационные навыки
Например, больше половины рабочего времени я общаюсь, согласовываю, обсуждаю. При этом стоит помнить, что непрерывное общение может привести к профессиональному выгоранию, поэтому периодически нужно прислушиваться к себе.
Правильная реакция на критику
Дизайнеров постоянно критикуют, и многие на это обижаются.
Если критикуют, то критикуют работу, а не дизайнера. Важно отделять и не принимать близко к сердцу.
Главное — получать конструктивную критику. Если сказали, что плохо, но не сказали почему, то это неаргументированное мнение, на которое не нужно реагировать.
Относитесь ко всему с юмором — это помогает в том числе трансформировать негатив в хорошее настроение ?
К примеру, когда я работал в крупной финансовой компании, менеджер попросила меня сделать кнопки жёлтыми (этот цвет не корпоративный). На мой вопрос, почему именно таким цветом, менеджер пояснила, что на курсах, которые она посещала, сказали, что «жёлтые кнопки привлекают внимание, поэтому, например, в IKEA выходы жёлтые». То, что в IKEA жёлтый — один из корпоративных цветов, которые логично использовали в оформлении магазина, на курсах, видимо, забыли сказать ¯\_(ツ)_/¯
Mindmap — диаграмма связей, интеллект-карта, карта мыслей или ассоциативная карта.
Это способ изображения процесса общего системного мышления с помощью схем.
Что нужно учитывать при разработке интерфейса
Взаимодействие с пользователями
Создание мобильных приложений не сильно отличается от создания сайтов в плане процессов — и те, и другие относятся к цифровым продуктам.
Основное различие заключается во взаимодействии пользователя с продуктом. За компьютером мы сидим или стоим, а вот с телефоном мы можем оказаться в любой ситуации: на прогулке, занимаясь спортом, в магазине, автомобиле и так далее. Также различаются размеры устройств и период контакта.
Смартфоны меньше компьютеров и ноутбуков, а сеансы использования приложений короткие, но частые — всё это нужно учитывать. На экране приложения должно быть минимум информации — только полезная. Пользователь должен быстро получать доступ к контенту. Возьмём, к примеру, Яндекс.Почту. Если мы зайдём в браузерную версию с компьютера, то увидим много дополнительной информации. На телефоне видим только письма, остальное скрыто и показывается по требованию (нажатию) — удобно.
Во многом благодаря желанию быстро и удобно получать информацию и появились мобильные приложения.
Ведь чтобы зайти на сайт, нужно ввести его адрес в строку браузера, а приложение можно открыть и сразу им пользоваться.
Нюансы мобильных платформ
Особенности создания интерфейсов для приложений описаны в гайдлайнах мобильных платформ — Human Interface Guidelines для iOS (Apple) и Material Design для Android (Google).
В создании приложений на платформах Android и iOS есть различия. Например, в паттернах поведения: в iOS меню показывается целиком, а в Android «гамбургерное» меню (три полоски); в разном управлении: в Android три кнопки («назад», «домой» и «последние приложения»), в iOS только «домой».
Грань с каждым обновлением постепенно стирается, но пока ограничения существуют. К примеру, модельный ряд iOS достаточно скромен, а в Android большое количество устройств да ещё и от разных производителей. Из-за этого при разработке на Android тяжелее отлаживать интерфейс — на это уходит много времени.
В основном Android доступнее, чем iOS. И из-за дешёвых компонентов встаёт вопрос качества — на плохой матрице экрана страдает цветопередача, а с плохим сенсором тяжелее попадать на кнопки (низкая чувствительность).
Интерфейс приложения лучше сразу адаптировать для двух платформ, а не делать что-то среднее — в будущем такая попытка сэкономить может дорого обойтись.
Стоимость «экономии» оценить в вакууме сложно — зависит от компании, бизнес-модели, рынка. Немаловажно и то, что для iOS характерна одна модель поведения пользователей, для Android — другая.
Если говорить о средних значениях, то давайте прикинем. Средняя зарплата разработчика — 150 тысяч рублей. В крупной компании приложение могут делать год, но мы будем ориентироваться на агентства, которые делают приложение примерно 3 месяца. Для Android нужны 2 программиста, для iOS — 1 (разработка примерно одинаковая по трудозатратам, но больше нужно отлаживать в Android).
Если просчитались с разработкой приложения на iOS, то это 150 000 рублей х 1 разработчик х 3 месяца = 450 000 рублей, на Android — 900 000 рублей. И это только расходы на зарплатный фонд — без учёта упущенной выгоды, репутационных потерь и снижения лояльности пользователей.
Адаптация контента
Не нужно пытаться уместить контент сайта в десктопной версии на компьютере или ноутбуке в маленький экран смартфона. При адаптации интерфейса под телефон контент приоритезируют и оставляют только самое важное.
Длинные процессы
Если на сайте можно использовать длинные формы (опросники) в несколько шагов, то на телефоне это делать не рекомендуется. Пользователю будет неудобно их заполнять, и он может бросить это занятие в любой момент.
Профессия
Дизайнер
мобильных приложений
Узнать больше
- Сможете самостоятельно разрабатывать дизайн мобильных приложений и руководить созданием интерфейсов мобильных продуктов
- Работайте над своим проектом или выберите учебный
- Каждый выпускник получает помощь и поддержку Центра развития карьеры Нетологии
Итак, мы разобрали базу для создания визуальной части интерфейса — дизайна. А теперь рассмотрим непосредственно процесс разработки приложений.
Этапы создания мобильного приложения
Исследование
Погружаемся в цели и задачи бизнеса.
Изучаем целевую аудиторию.
Исследования делятся на количественные и качественные.
Количественные исследования отвечают на вопросы «сколько?», «как часто?». Обычно их проводят при помощи опросов, анкетирования, телефонных интервью.
Качественные отвечают на вопросы «кто?», «почему?». Получают информацию в индивидуальных глубинных интервью, групповых дискуссиях (фокус-группах) или прибегая к экспертным оценкам.
Если приложение делается с нуля, то сначала с помощью комбинации методов проводят качественные исследования, потом количественные.
Если приложение уже разработано и его нужно доработать, тогда сначала собирают статистику количественными методами, а потом — качественными.
Дальше проводим конкурентный анализ, изучаем другие каналы коммуникации бизнеса: сайт, презентации, реклама, при наличии — офлайн-точки.
Это нужно для правильного позиционирования бизнеса в приложении. У каждого бренда или компании есть свой язык общения с клиентом. Через каналы коммуникации бренд транслирует посылы аудитории. Например, слоган Nike «Just do it» отражается в простом, спортивно-повседневном стиле, в котором оформлены магазины и сайты компании.
Аналитики предварительно пропускают через себя требования бизнеса и упаковывают это в понятные модели: mindmap, схемы бизнес-процессов, типичные пользовательские пути и другое, — создают артефакты аналитики.
На основе вышеуказанных артефактов дизайнер принимает решения.
Также артефакты помогают управлять коммуникацией с бизнесом: чтобы каждую неделю не прилетали изменения, все бизнес-требования обговариваются и фиксируются. Это важно, чтобы не делать работу в стол и избежать бесконечных доработок.
Если каждую неделю приходят новые требования, то бизнес-заказчик не знает или не понимает, что на самом деле он хочет. А если нет чётких критериев приёмки, будет сложно показывать результат работы. Можно попасть в петлю непрекращающихся правок и постоянных переделок.
Вышеперечисленное — исследования, общение с бизнесом, аналитика — может сделать дизайнер, менеджер продукта или аналитик, если есть такой специалист в компании. Это зависит от компании и бюджета на проект.
Если есть выделенные аналитики, то зона ответственности между ними для целей разработки приложения может распределяться следующим образом:
- бизнес-аналитик погружается в бизнес-процессы и собирает требования от компании,
- UX-аналитик изучает проблемы пользователей, проводит качественные и количественные исследования,
- продуктовый аналитик обычно работает с метриками и показателями продукта.
Проектирование
По сути это создание скелета приложения: дизайнер понимает, где какая будет информация, раскидывает контент по экранам и определяет, сколько экранов будет в каждом пользовательском сценарии.
Чтобы проверить эту логику на практике, дизайнер собирает черновик приложения. Там он тестирует связку экранов, проверяет, что компоненты интерфейса расположены в правильном месте и понятно, как с ними взаимодействовать: что-то нужно нажать, потянуть, выделить или удалить.
На этом этапе важно не переходить в визуальный дизайн и не углубляться в вопросы из серии «какого цвета будет кнопка» или «какие сделать скругления у картинки».
Для проектирования чаще всего используют чёрно-белые прототипы — вайрфреймы, которые создаются в графическом редакторе.
Перед вайрфреймами некоторые создают бумажные прототипы — от руки делают эскиз будущего приложения на бумаге.
Бумажные прототипы подходят для быстрого обсуждения идей, чтобы проверить себя и синхронизироваться с командой перед тем, как приступить к работе в графическом редакторе.
Бумага и карандаш — такие же инструменты дизайнера, как и графический редактор.
Когда дизайнер продумывает процессы в приложении, сложно удержать всё в памяти в один момент времени — нужно фиксировать ход мысли. И в этом сложно полагаться на графические редакторы, которые заточены под определённые задачи — например, обработать фотографии или создать иллюстрации. К тому же, когда мы сразу работаем в графическом редакторе, мы вынуждены подстраиваться под его ограничения, то есть не мы управляем инструментом, а инструмент — нами.
Между идеей в голове и её реализацией получается много посредников: интерфейс графического редактора, экран монитора, клавиатура, мышка. А при работе с бумагой идея быстрее становится осязаемой.
Читайте также: