Рекомендации по разработке мобильных приложений и анализ ошибок

Рекомендации по разработке мобильных приложений и анализ ошибок

https://t.me/uxidesign


В 2017 году из iOS App Store и Google Play было загружено более 91 миллиарда приложений, которые не включают в себя все сторонние магазины приложений и магазины приложений для других платформ. Это очень большое количество - примерно 13 на человека - по всей планете. Неудивительно, что при загрузке стольких приложений, что среднее приложение имеет показатель оттока 57% в первый месяц (пользователи, которые не открывают приложение более одного раза в течение первых 30 дней после его загрузки) и колоссальные 71 % через 90 дней.

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

Итак, почему у многих приложений не получается заинтересовать клиента? Является ли это предсказуемым явлением, которое должны принять разработчики приложений и разработчики? Для клиентов это показатель успеха? Что нужно, чтобы ваши приложения не удалялись?

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

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

Общая ошибка №1: Плохое первое впечатление

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

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

Хотя это может быть хорошим способом заставить кого-то быстро ориентироваться, но долго вступление также может помешать пользователям делать то, что они хотят делать с приложением. Часто эти учебные пособия слишком длинные, и это надоедает.

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

Мобильный адаптационный дизайн (Johan Adam Horn)


Общая ошибка №2: Создание приложения без цели

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

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

Передача этого видения потенциальным пользователям означает, что они поймут ценность, которую приложение приносит в их жизнь. Видение должно быть четко передано из первого впечатления пользователя. Как быстро может видение приложения передаваться пользователям? Как это улучшит жизнь человека или обеспечит какое-то наслаждение или утешение? До тех пор, пока полезность приложения не будет немедленно передана пользователям, оно, скорее всего, станет частью 21% приложений, которые погибают в первые 90 дней.

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

Общая ошибка №3: невозможность оптимизировать поток пользователей

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

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

Хорошо продуманная схема последовательности операций пользователя (Michael Pons)


Общая ошибка № 4: игнорирование бюджета развития приложений

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

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

Общая шибка № 5: Переполненность в особенности дизайна

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

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


Если приложение не может быть объяснено в краткой форме, оно, вероятно, пытается сделать слишком много. Урезать функции всегда тяжело, но это необходимо. Лучшая стратегия может заключаться в том, чтобы в начале пользователи получили только одну или две функции перед тестированием новых дополнений в более поздних версиях, чтобы узнать, что взаимодействует с пользователями. Таким образом, дополнительные функции с меньшей вероятностью будут влиять на решающие первые несколько дней жизни приложения.


Общая ошибка №6: отклонение контекста приложения

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

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

Является ли ваше приложение доступным для быстрого доступа и в течение короткого периода времени? Или это приложение с большим количеством контента, которое позволяет пользователям оставаться на некоторое время? Как дизайн передаст этот тип использования? Внимательно изучите эти моменты при отображении потока UX вашего приложения.

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

Обычная ошибка № 7: Злоупотребление уведомлениями

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

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

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

Push-уведомления - деликатный баланс в хорошем мобильном дизайне (Jona Nalder).

Общая ошибка № 8: Чрезмерное использование дизайна приложения

Известный архитектор Mies Van der Rohe однажды сказал: «Лучше быть хорошим, чем быть уникальным». Очень важно, чтобы дизайн соответствовал спецификациям в краткой форме, прежде чем дизайнеры начнут ломать коробку или добавлять другие расцветки.

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

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

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

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

Общая ошибка № 9: Несоответствия дизайна

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

Равномерно ли отформатирован текст? Делают ли элементы пользовательского интерфейса предсказуемыми, но приятными способами в приложении? Консистенция проекта должна найти баланс между существующим общим визуальным языком и избежать эстетического застоя. Баланс между интуитивной последовательностью и скукой - тонкая грань.

Обычная ошибка № 10: Недостаточное использование бета-тестирования приложений

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

Отправляйте объявление для бета-тестеров и работайте с избранной аудиторией перед публикацией или используйте службу тестирования, такую как UserZoom. Это отличный способ сгладить детали, отредактировать функции и найти то, чего не хватает. Бета-тестирование может занять много времени, но это определенно лучшая альтернатива разработке приложения, которое проваливается.

Дизайнеры должны уделять особое внимание тестированию мобильных пользователей, поскольку потенциальные пользователи непостоянны (источник: Fake Crow).

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



Report Page