Россия
www.azoft.ru Share

Azoft

С 2002 года года Azoft работает на рынке международного IT-аутсорсинга, предоставляя услуги разработки ПО для компаний по всему миру. Наши клиенты — компании из США и Канады, Великобритании и Австрали...
Страна: Россия
Город:
Год основания: 2002
Количество сотрудников: 100+
Специализация:
Количество приложений: 52
PR/Медиа:
Показаны записи 1-12 из 52.
Каталоги
Free
Покупки
Free
Путешествия
Free
Инструменты
Free
Финансы
Free
Покупки
Free
Спорт
Free
Стиль жизни
Free
Стиль жизни
Free
Образование
Free
Образование
Free
Путешествия
Free
 
 
06-04-2017, 09:00
Azoft

8 заблуждений на пути к идеальному UX дизайну

Мы расскажем о распространённых заблуждениях в UX дизайне, которые портят любое приложение. Где что-то может пойти не так:

  • на этапе планирования: когда есть идея продукта и необходимо продумать её воплощение;
  • на этапе создания приложения: когда разработчики строят UX-архитектуру;
  • на этапе оптимизации: когда приложение вышло на рынок и нужно вносить изменения в UX дизайн.

#1. Зачем мы это делаем?

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

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

Что делать?

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

#2. Целевую аудиторию определим на ходу

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

Что делать?

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

#3. Да кто они такие?

Виктор уверен в уникальности своего продукта и не желает опираться на опыт конкурентов. Это плохое решение, Виктор. Если изучить других игроков на рынке, продукт не станет менее самобытным, зато можно будет избежать ошибок и узнать много полезного.

Что делать?

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

#4. Веб-дизайн — наше всё

Итак, команда перешла от этапа проектирования к созданию приложения. Цель поставили, целевую аудиторию определили, конкурентов изучили. Но это еще не всё.

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

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

Что делать?

Убедиться, что приложение правильно реагирует на движение пальца. Тут механика отличается от десктопной мыши. Расстояние между целями для нажатия — «tap targets» — не больше вытянутого пальца. Обязательно добавьте в приложение виртуальную клавиатуру. Если клиент в приложении вводит даты или другие цифры, подготовьте удобную раскладку. Не забудьте кнопки для быстрого набора E-mail адреса.

#5. Добавим еще пару функций!

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

Что делать?

Используйте аналитику, проводите глубинные интервью пользователей и определите самый популярный функционал. Расставьте приоритеты и помните о принципе KISS – keep it short and simple. Не загромождайте интерфейс лишними разделами и переходами.

#6. Обойдемся без тестов

Приложение еще не вышло, но Виктор и его команда уверены, что их продукт прекрасен. Архитектура получилась изящная, навигация простая, а дизайн продуман до мелочей. Что до практической ценности, то приложение играючи решает проблемы пользователя. «Тестировать, наверное, и не будем даже», — думают разработчики.

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

Что делать?

Тестировать. Искать в коде баги и править.

Юзабилити можно тестировать как в процессе разработки, так и после релиза. Для этого есть два способа: коридорное тестирование и фокус-тесты.

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

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

Не забывайте об аналитике. Чем точнее изучите поведение пользователей — тем проще и удобнее сделаете приложение. Используйте Appsee, Flurry, Mixpanel или Google Analytics, это популярные и полезные инструменты.

#7. Юзеры сами разберутся

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

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

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

Что делать?

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

#8. Нужно больше полей регистрации

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

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

Что делать?

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

Как вариант, сделайте урезанную версию регистрации. Пользователь вводит почту и получает доступ к приложению. В случае, если он свернет приложение — попросите закончить регистрацию.

Сделайте автосохранение форм. Если данные пропадут в момент заполнения — пользователь может уйти из приложения, так и не закончив регистрироваться.

Кажется, всё

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

Чтобы оставлять комментарии вам необходимо зарегистрироваться