Хабрахабр

[Перевод] Четыре правила интуитивного UX

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

100500 результатов!) (Серьёзно, поищите «дизайн-мышление».

Для кого эта статья?

  • Разработчики. Вы создали собственное приложение, но каждый пользователь мучается с ним. И вы знаете: если они говорят вам это в лицо, то дело действительно плохо.
  • Графические дизайнеры. Изучать UX по статьям в интернете — это какой-то… очень болезненный способ умереть.
  • Менеджеры проектов. Вы уже на четверть UX-дизайнер. Было бы неплохо освоить остальные навыки.
  • И остальные проходимцы. Все, кто корпит над своими проектами по вечерам и выходным. Вам тоже пригодится.

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

Этот навык — «понимать язык интерфейса».

Я не говорю об ошибках, которые можно выявить после длительного A/B-тестирования. В начале карьеры меня поражало, как часто клиенты передавали первоначальные наброски (или живые, рабочие прототипы) с совершенно очевидными ошибками UX. Я говорю о простых, самых глупых ошибках.

За неимением лучшего примера:

Где-то есть группа разработчиков, которые знают HTML, но не знают разницы между переключателем и флажком

Чтобы понять это, нужно просто знать язык интерфейса. Мои клиенты не настолько плохи, но чёрт побери, не нужно быть семи пядей во лбу, чтобы понять: если можно выбрать только ОДИН элемент из списка, то нужны ПЕРЕКЛЮЧАТЕЛИ, а не флажки. Свободное владение интерфейсом доступно каждому. И для меня это самое безумное. Вам не нужен колледж, не нужны курсы и так далее.

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

Постоянно повторяйте эту процедуру — и станете профессионалом в кратчайшие сроки.

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

(Именно тогда начинайте прослушивать лекции других дизайнеров UX о новейших академических методах исследований пользователей!)

Вот что мы осветим:

  1. Закон локальности
  2. Что угодно, только не выпадающие списки
  3. Тест на прищур
  4. Обучение на примерах

Вопросов нет? Тогда вперёд.
Размещайте элементы интерфейса там, где они вызывают изменение.

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

Где разместить кнопку «ДОБАВИТЬ НОВЫЙ ЭЛЕМЕНТ»? Допустим, у вас список элементов.

Вопрос: Ну и где происходит изменение?

Ответ: В конце списка.

Отлично, поставьте кнопку в конце списка.

Вы думаете, что это довольно просто. ПОДОЖДИТЕ. Но есть искушение.

Искушение состоит в том, чтобы просто поставить её там, где есть свободное место.

Почему бы просто не поставить его в меню!?» Например, если у вас меню, то вы можете подумать: «У нас есть меню!

Нарушение закона локальности в музыкальном интерфейсе

Ответ очевиден: потому что там её никто не будет искать.

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

Когда-нибудь встречали этот интерфейс? Думаете, что я шучу?

Нарушение закона локальности в интерфейсе Evernote

«Нужна кнопка „Добавить”? Столь же плохая и распространённая альтернатива — просто взять решение, которое вы видели в Уважаемой Технической Компании, не задумываясь о том, имеет ли это смысл для вас. Я видел одну такую кнопку. Не вопрос. Подержи-ка пиво!»

Ещё одна кнопка там, где пользователи никогда не будут её искать. Смотрите. Потому что именно там она находится. Вообще говоря, они будут подозревать, что эта кнопка добавляет что-то новое на большом пустом белом пространстве.

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

Итак, теперь давайте использовать его.

Бам.

Если пользователь создаст тонну плейлистов, то кнопка уйдёт на сотни пикселей вниз! Возможно, вы прирождённый дизайнер UX и всегда визуально представляете, что будет при наличии тысячи элементов вместо пяти, и понимаете — там возникнет проблема.

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

Именно так сделал Spotify. Блестяще!

Для бонуса (1) используйте встроенную кнопку, пока она не выйдет за пределы экрана, и в этот момент переключитесь на закреплённый элемент и (2) сделайте его более заметным, чем кнопка Spotify, которую лично я заметил только через несколько месяцев, беспомощно щёлкая правой кнопкой мыши, чтобы добавлять в плейлисты отдельные песни!

Где самое близкое подходящее место для неё? Другой вариант — признать, что мы не можем надёжно и последовательно показывать кнопку в нижней части списка.

И ответ, (я думаю, довольно очевидный) — в верхней части списка.

Это моё пожелание

Именно так сделал Rdio, конкурент Spotify, прежде чем его купила Pandora. Чёрт возьми!

Реконструкция по памяти (как и вся реальность, если подумать)

Никогда не продавайте свою компанию и всегда, всегда соблюдайте закон локальности. Вывод ясен.

Если интересно, читайте здесь). (На самом деле есть три закона локальности, и «размещать элементы UI там, где они влияют на изменение» — только первый.

Следующий!

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

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

Добро пожаловать в ад!

Они не всегда плохи, но против вас играют следующие факторы:

  • Выпадающие списки требуют слишком много кликов/нажатий. Один для открытия, ещё несколько, чтобы прокрутить до нужного варианта (на мобильном телефоне), ещё один для выбора правильного варианта и (на мобильном телефоне) последний, чтобы закрыть (сравните с одним щелчком мыши для выбора из перечисленных вариантов).
  • Выпадающие списки не показывают варианты! Чтобы их увидеть, нужно сначала нажать на список, а на мобильном телефоне часто отображается не весь список за раз.
  • В длинных выпадающих списках трудно ориентироваться. В выпадающем списке стран может быть более 195 элементов. В какой-то момент практически любой другой вариант UI будет быстрее, чем прокручивать выпадающий список.

Это довольно просто, поэтому давайте рассмотрим основные альтернативы выпадающему списку.

Если выбор между двумя вариантами…

У нас есть несколько фантастических способов для выбора одного из двух вариантов. Все они (а) сразу показывают варианты и (б) требуют меньше нажатий/кликов.

Для вопросов, на которые нет ответа «по умолчанию», попробуйте сегментированную кнопку.

Он также хорош для настроек, которые не влияют на изменение, пока пользователь не нажмёт «Сохранить» или «Отправить». Если есть состояние по умолчанию, которое соответствует 'OFF', попробуйте установить флажок.

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

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

Если выбор между 2−5 вариантами…

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

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

Для подробного отображения нескольких вариантов хорошо подходят карточки.

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

Видимо, «Тесле» тоже это нравится

Если выбор между многими вариантами…

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

Если выбираете дату…

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

Ну, это зависит от обстоятельств. Какая альтернатива? Первый вопрос: какой тип даты вы выбираете?

  1. Пуассоновы даты. Сначала более вероятные даты, а далее по списку — менее вероятные. Например, дата запланированной встречи или авиарейса.
  2. Даты с высокой изменчивостью. Даты, у которых примерно одинаковая вероятность в широком диапазоне времени. Например, день рождения.

(Да, я назвал «пуассоновы даты» в честь математического распределения 🙂

Для различных типов подходят разные элементы управления.

Совершенно нормально, если выбрать дату вне этого диапазона будет чуть сложнее. Для пуассоновых дат мы хотим сделать МАКСИМАЛЬНО УПРОСТИТЬ выбор дат в наиболее вероятном диапазоне (например, для планирования встречи это может быть следующие, скажем, 14 дней).

Если вы знаете, что дата с высокой вероятностью попадает на ближайшие 2-4 недели, вы в шоколаде. Элемент управления «календарь» вполне отвечает этим требованиям для пуассоновых дат.

Довольно креативно, Google Flights по умолчанию предлагает вам рейс примерно через две недели, что иногда вызывает путаницу («Я этого не выбирал!»), но это, наверное, самый вероятный выбор по распределению Пуассона.

Текстовое поле даты, вероятно, лучший вариант для дат с высокой вариативностью, где (А) нет причин отдавать предпочтение какой-то одной дате перед другой, то есть (Б) все варианты одинаково трудно выбрать.

Помните, что input[type=date] — это ваш друг… по крайней мере, на десктопе

Если выбираете число…

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

Очень часто. Как часто вам нужен 1 билет?

Не слишком. Как часто вам нужно 10 билетов?

Это какая-то жестокая шутка? Как часто вам нужно 10 000 билетов?

Здесь мы опять имеем дело с распределением Пуассона и должны использовать элемент управления, смещённый к более низким числам: например, степпер.

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

Можно хоть где-то использовать выпадающие списки?

Конечно.

Помните, что они нормально работают, когда…

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

Возможно, самые наблюдательные среди вас заметили, что в интерфейсе Google Flights, который я хвалил выше, на самом деле три заметных выпадающих списка!

Что примечательно, в мобильном интерфейсе нет выпадающего списка 'Economy'

Потенциальные проблемы юзабилити быстро смягчаются за счёт следующего: Они на самом деле хорошо здесь поработали.

  • Специальные элементы управления, которые по нажатию показывают все параметры (в том числе на мобильном телефоне) — и заменяют собой четыре выпадающих списка (взрослые, дети, младенцы в сиденье, младенцы на руках) четырьмя степперами в одном раскрывающемся списке.
  • Удаление выпадающего списка 'Economy' в мобильном интерфейсе
  • Мало вариантов и умные значения по умолчанию для каждого элемента

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

Контрольный вопрос: что должен сделать пользователь, чтобы использовать эту страницу?

(Примечание: я её заблюрил, поэтому следуйте инстинктам, но могу дать подсказку: это форма ввода данных)

Я бы предположил две вещи:

  1. Установить все соответствующие флажки (??) в жёлтой области
  2. Нажать синюю кнопку «Отправить»

Вы тоже так подумали?

Ошибка и ошибка.

  1. «Флажки» на самом деле представляют собой очень маленькие поля для ввода текстовых данных (если вы прочитали предыдущий раздел, то знаете, что здесь должны быть степперы).
  2. Самое главное («Найти варианты» — кстати, это очень запутанный способ сказать «Отправить») оформлено серой и незаметной кнопкой. Гораздо менее важная вещь («Помощь») находится непосредственно рядом, но больше по размеру и лучше заметна.

Тест на прищур говорит, что самая важная вещь должна быть самой заметной. Что здесь самое важное? Это текстовое поле (или степпер 😉 и кнопка «Отправить».

Если вы пройдёте дальше, то следующая страница ещё хуже.

Что вы нажмёте: серую кнопку слева или такую же серую кнопку справа?

Надеюсь, вы выбрали левую!

В спешке на этой форме я на самом деле сначала нажал кнопку «Помощь». Ой. Зайдя второй раз, я нажал «Вернуться», даже бегло просканировав названия обоих кнопок, потому что на 99,999% других сайтов (с направлением письма слева направо) кнопка «Вернуться» всегда слева

Опять же, если прищурить глаза, я не могу сказать, что важно.

Исправление схемы за 30 секунд. Как закон локальности и исключение выпадающих списков, тест на прищур довольно простой.

В реальном редизайне я хотел бы поместить выбор количества билетов на ЭТОЙ ЖЕ СТРАНИЦЕ. Но это другой закон для другого времени

Это работает?

Четыре переключателя и кнопка. Сами скажите. И крошечная ссылка снизу.

Я не пытаюсь придираться к сайту AlaskaTrain.com, такое встречается повсюду.

Вот экран регистрации в моей любимой социальной сети на основе рекомендаций Foursquare (заблюреный, конечно).

Как в реальности отправить введённые данные (самое главное)?

Подсказка: кнопка скрыта за обычным текстом в правом верхнем углу.

К сожалению, нарушение теста на прищур часто встречается даже у лидеров отрасли. Но Foursquare здесь просто следует стандартам дизайна Apple.

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

На каждые сто просмотренных карточек я затем перейду к…

  • Показать ответ (примерно 95 раз)
  • Вернуться к списку карточек (дважды)
  • Начать добавлять карты (дважды)
  • Некоторые другие функции (очень редко)

Такой анализ действительно намекает, какой интерфейс здесь лучше будет работать.

  • Акцентируйте наиболее часто используемые функции (в первом приближении «наиболее используемые» равняется «наиболее важным»)
  • Ослабьте, скройте или удалите менее используемые функции

Но с помощью всего лишь нескольких простых эвристик мы сократили беспорядочный, запутанный интерфейс из десяти элементов UI всего до пяти. Но это только начало (например, я бы хотел посмотреть, поймут ли пользователи, что кнопка с плюсом без подписи добавляет карточки). Это… проверьте тут мои расчёты… в два раза меньше.

Или, если у вас нет десяти минут, вот иллюстрированная статья в блоге с тем же пошаговым редизайном. Для дополнительной информации о тесте на прищур можете посмотреть моё видео с демонстрацией редизайна веб-приложения Timezon.es.

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

У нас есть странная тенденция пытаться объяснить всё словами, когда примеры намного яснее.

Заголовки на этой странице: Возьмём новый стартап Teeming.ai, который недавно обратился ко мне, чтобы проконсультироваться по дизайну главной страницы.

  • «Teeming избавляет от изоляции в удалённой работе»
  • «Teeming помогает с удалённым тимбилдингом», это также «обучение, решение проблем, получение удовольствия и мотивация друг друга»
  • «Teeming и видео для синхронной [связи]»
  • «Работает со всеми вашими любимыми видеоплатформами»

Но вот вопрос. Что на самом деле делает Teeming?

Понятно, что это как-то связано с… позитивом для удалённых работников? Трудно сказать. Но у меня нет конкретных идей, как это поможет лично мне, так что я не стану пробовать этот сервис, рекомендовать его и т. д.

(Извините, Teeming, вы знаете, я вас люблю).

Может, вы уже знаете, что они делают — тогда притворитесь, что не знаете, и попытайтесь понять это из заголовков на главной странице: Далее, посмотрим на IFTTT.

  • Автоматически осветить дорогу парню с доставкой пиццы (Dominoes+Hue)
  • Публикуйте свои фотографии везде и смотрите их отовсюду (Instagram+Twitter)
  • Сделайте свой голосовой помощник более персональным (Google Assistant+iOS Calendar)

Не нужно перечислять много примеров, чтобы нарисовать довольно чёткую картину: IFTTT соединяет приложения вместе, чтобы они делали то, на что не способны по отдельности.

Сумасшедшая вещь в том, что на главной странице они сначала объясняют это текстом:

IFTTT — это бесплатный способ заставить все приложения и устройства разговаривать друг с другом. IFTTT помогает вашим приложениям и устройствам работать вместе по-новому. Не всё в интернете хорошо работает, поэтому наша миссия — построить более связанный мир.

Блииин.

Примеры или описание? Вопрос: что лучше объясняет идею приложения?

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

Вот что мы видим при первом входе в инструмент управления проектами Basecamp. Но примеры нужны не только на целевой странице.

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

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

Есть даже дружелюбная… гора?… которая говорит, что я могу посмотреть двухминутное пояснительное видео об этом обучающем проекте.

Примеры показывают, как будут выглядеть мои проекты, а видео показывает, как использовать программное обеспечение. И спасибо вам, мистер Гора, за руководство: демонстрационные видеоролики — это ещё один способ обучения на примерах!

Блестяще.

Если ваше приложение даёт пользователям что-то создавать, то демонстрация — отличный способ показать возможности на примере.

Замечательное приложение для рисования Procreate выиграло Apple Design Award, «Выбор редактора» App Store и App Store Essential, а Джон Грубер назвал его «новаторским» и т. д. — но никакие награды не восхищают так, как реальные примеры работ, созданных в этом редакторе.

Это не обычное приложение для рисования

Вау.

Это вам не MS Paint.

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

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

Вкратце, мои любимые способы сделать это:

  1. На любой странице, которая пытается предложить пользователю функцию/приложение и т. д., покажите примеры, что можно сделать с этим инструментом.
  2. Используйте метод «первоначальной загрузки», покажите образцы данных и пример, как будет выглядеть правильно работающее приложение.
  3. Стратегически внедряйте справочную информацию (например, статьи, видео или подсказки) вместе с примерами использования.
  4. Ваше приложение позволяет создавать что-то творческое? Покажите галерею работ, чтобы подстегнуть воображение.

Есть смысл? Давай на этом и закруглимся.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть