Неправильно используемые мобильные UX паттерны

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

Некоторые могут сказать, что придерживаясь гайдлайнов и чужих работ вы убиваете творчество и, в конце концов, все приложения будут выглядеть одинаково. С точки зрения UX я вижу другую проблему. Привыкание к адаптации лучших решений может заставить вас поверить, что Google / Facebook / Instagram / [Ваше любимое приложение] всегда правы, их цели дизайна такие же, как ваши, и вы не подвергаете их сомнению. Вот несколько моделей, которые показывают (или показывали) лучшие практики. И они выглядят не так хорошо, как вы думаете, на первый взгляд.

1. Скрытая навигация

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

Левое меню гибкое и удобное для использования

Левое меню гибкое и удобное для использования

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

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

Изменения в навигации Ютуба

Изменения в навигации Ютуба

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

2. Иконки, везде иконки

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

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

Личные сообщения в Инстаграме

Или, предположим, что вы никогда не использовали Google Translate раньше. Какую реакцию вы бы ожидали, нажав на эту иконку?

Странная иконка в Гугл Переводчике

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

Странный бар в bloom.fm

Странное меню в Bloom.fm

Если вы нарисовали иконку, и вы чувствуете, что требуется какое-то пояснение, для её понимания, то вы делаете что-то неправильно. Даже если вы Foursquare и ваши пользователи в любом случае будут учить иконки.

Подсказки в Swarm

Подсказки в Swarm

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

Популярные иконки, которые узнают большинство пользователей

Популярные иконки, которые узнают большинство пользователей

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

Навигация в pixelmator

Навигация в pixelmator

Основная функциональность может быть эффективно представлена ​​иконками. Для сложных функций, должны быть показаны текстовые описания. (Если вы используете иконки, тестируйте их с помощью юзабилити-тестов).

3. Навигация на основе жестов

Когда Apple представила iPhone в 2007 году, технология мультитача получила внимание большой аудитории. Пользователи узнали, что они могут не только тапать, но и зумить, использовать щипок и свайп.

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

Навигация жестами в Сlear app

Навигация жестами в Сlear app

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

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

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

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

Смахивание вправо работает как «Отметить нерпочитанным» в Apple mail

Смахивание вправо работает как «Отметить нерпочитанным» в Apple mail

Тот же самый жест архивирует письмо

Тот же самый жест архивирует письмо в Mailbox

Или, встряхивание устройства может означать как Отмену (в iOS), так и Отправить отзыв (Google Maps).

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

4. Обучающий оверлей как onboarding

Onboarding, свежая и горячая тема в UX, которая относится к первой встрече между пользователем и приложением. (Onboarding — обучение новых пользователей использованию приложения — прим. переводчика). Во многих случаях, это просто означает, показать полупрозрачный оверлей, чтобы объяснить интерфейс:

Обучающие пометки в dcovery app

Обучающие пометки в dcovery app

Почему это плохое решение? Потому что многие пользователи будут пропускать это интро; они просто хотят начать работу с приложением. И даже если они изучают вашу обучалку, они обычно забывают все, как только закрывают оверлей. (Особенно, если экран переполнен информацией.) И последнее, но не менее важное: добавление обучающих отметок для вашего интерфейса не сделает его более понятным. Запомните это:

Интерфейс как шутка. Если вы должны объяснять её — это плохая шутка.

Интерфейс как шутка. Если вы должны объяснять её — это плохая шутка. Источник: Startup Vitamins

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

slack_welcome

Более интерактивный способ вовлечь неопытных пользователей — прогрессивный onboarding.

Duolingo не объясняет, как работает приложение: пользователям предлагается сразу сделать быстрый тест на выбранном языке (даже без регистрации). Потому что люди учатся лучше, делая что-то. Кроме того, это гораздо более привлекательный способ, показать полезность приложения.

Duolingo onboarding

Помните, разные жесты свайпа в Mailbox и в Apple Mail? Как работает их прогрессивный onboarding: пользователи следуют руководству, где они должны попробовать каждый жест, прежде чем на самом деле начнут использовать приложение.

Обучение пользователей в Mailbox

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

5. Креативные, но непонятные пустые состояния

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

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

Возьмем этот пустой экран в Google Photos:

Пустой экран в Google Photos

Пустой экран в Google Photos

На первый взгляд, выглядит круто, правда? Хорошая композиция, следование гайдлайнам, красивая графика.

На второй взгляд, есть некоторые странные моменты:

  • Почему так заметна кнопка поиска, если нет никаких коллекции? Почему вы хотите, чтобы искали там, где ничего нет?
  • Второй наиболее заметный элемент — это картинка. Очевидно, не реагирующая на нажатия (хотя многие будут пытаться).
  • Подсказка говорит, что я должен найти кнопку «+» вверху, что является супер неудобным. Почему сама подсказка не содержит кнопку добавления? Это, как сказать «нажмите на кнопку Продолжить, чтобы продолжить».

Этот пустой экран не помогает пользователям понять контекст:

  • Что такое коллекции? Почему они полезны?
  • Почему у меня их нет?
  • Что я могу с этим сделать (и должен ли я что-то делать вообще)?

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

Пустой экран в Lootsy

Пустой экран в Lootsy

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

Подвергайте сомнению

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

Развивайте собственное мышление. Делайте свой дизайн. Проводите свои собственные исследования.

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

---

 

Вольный перевод Misused mobile UX patterns.


Подписка по РСС
Мой твитер
Поделиться
Отправить
Запинить

Нет комментариев

Оставить коментарий

Суперрассылка!

Введите почту и будьте в курсе