Ctrl + ↑ Позднее

На одной из съемных квартир у меня был телевизор. Какой-то обычный Филипс, похожий на этот:

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

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

Человек, который проектировал интерфейс Филипса либо сам попадал в похожую ситуацию, либо как следует изучил пользователей. Когда я выключал звук на том телевизоре и нажимал «Volume —», слайдер на шкале громкости также медленно полз вниз, но режим «Без звука» не выключался. Когда я добирался до комфортного уровня звука (каждый знает эту цифру для своего телевизора), то либо снова нажимал кнопку «Выключить звук», либо один раз на «Volume +». Все логично и безумно удобно. Посоны, такой фичи даже в OS X нету!

Телевизор я не смотрю уже давно, но про тот Филипс всегда вспоминаю с любовью.

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

Как это часто бывает, прельщенный рецензией на эту книгу на сайте издательства «Манн, Иванов и Фербер», я ожидал от прочтения большего.

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

Тем не менее, я советую прочесть эту книгу всем новичкам в сфере UX, проектирования интерфейсов и смежных областях. Почему? Потому что сквозь всю книгу фоном проходит основная мысль: если ты хочешь сделать хороший продукт (неважно, реальный это объект или веб-интерфейс), то научись слушать и понимать пользователей этого продукта. Книга «Сторителлинг в проектировании интерфейсов», подобно психологическому тренингу, закрепляет где-то на уровне подсознания неотъемлемую важность проектирования, ориентированного на пользователя. Именно поэтому ее необходимо читать новичкам — как азбуку в школе.

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

Ставлю этой книге крепкую тройку по пятибалльной шкале.

15 мая 2015, 11:16

Сайдбарная слепота

В далеком 1997 Якоб Нильсен в статье Why Advertising Doesn't Work on the Web впервые использовал термин «баннерная слепота» (banner blindness). Суть термина понятна — пользователи веб-сайтов концентрируют внимание на нужном им контенте и абстрагируются от рекламных блоков и баннеров, то есть попросту не замечают их.

Позже он написал статью Banner Blindness: Old and New Findings, основываясь на результатах айтрекинговых исследований. В ней наглядно подтверждаются основные постулаты материала десятилетней давности:

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

Аналогичные выводы я сделал, проводя анализ метрик проектов, над которыми работал лично. Этот эффект, по аналогии с термином Нильсена, я назвал «сайдбарная слепота».

Откуда взялись сайдбары

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

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

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

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

О чем стоит знать дизайнерам

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

Тут у читателя могут появиться вопросы, например: «у нашей компании есть блог с замечательными статьями, которые очень нравятся клиентам. По-вашему, нужно оставить только сам текст статьи, и убрать из сайдбара форму подписки на рассылку? И кнопки “Поделиться”?» Убрать эту информацию из сайдбара — не значит вовсе убрать ее со страницы. В приведенном примере подписка на рассылку и возможность поделиться — это контекстные действия, которые подавляющее большинство пользователей совершит только после прочтения статьи. И тогда стоит задуматься, необходимо ли их располагать в сайдбаре, может быть правильнее их разместить под текст статьи?

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

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

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

Иначе так и будут создаваться сайты, в которых CTA-кнопка расположена в сайдбаре, например:

Мы начинаем двигаться в правильном направлении

Например, не так давно в Яндексе поняли, что рекламные ссылки в сайдбаре не дают столько прибыли, как должны, и перенесли рекламную выдачу из сайдбара в низ колонки органической выдачи, что увеличило количество кликов на рекламные объявления в 2,5 раза.

Нельзя не вспомнить о Люке Вроблевски, который написал целую книгу о mobile first-дизайне — дизайне, в котором мы начинаем с контента, расположенного в одну колонку, то есть волей-неволей приходится располагать наиболее важную информацию друг за другом в порядке релевантности.

Мои любимые примеры — интернет-ресурсы, которые используют сайдбары в их первоначальном смысле (т. е. для контекстных комментариев к определенным абазцам), например Medium, сайт дизайн-бюро Артёма Горбунова или книга Magic Ink Брета Виктора.

Да и вообще, сравните Youtube и Vimeo. Какой из этих сайтов создан, чтобы получать удовольствие от просмотра видео?

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

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

Существует множество инструментов — как для создания, так и для оценки качества уже разработанных ИА. Основные из них — стандартное юзабилити-тестирование, карточная сортировка, тестирование дерева — требуют немалых временных и финансовых затрат.

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

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

Почему эвристики — это хорошо?

Помимо быстроты и беззатратности, эвристики имеют еще несколько положительных моментов.

В первую очередь, они доступны. По сути, эвристики — это своеобразный чек-лист, который легко можно найти в сети. Еще один плюс — многовариантность: почти все гуру UX «отметились» в создании своего заветного списка. Прогоните свой проект по понрваившемуся вам набору эвристик — и получите полноправное исследование, результат которого можно использовать для подкрепления своей точки зрения фактическими данными.

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

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

А теперь приступаем к самому главному: собственно, сами эвристики.

Из чего выбирать?

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

1990: «Эвристики юзабилити» Якоба Нильсена
2004: UX HoneyComb Питера Морвиля и «Эвристики информационной архитектуры» Луи Розенфельда
2006: ISO 9421 «Эргономика человеко-машинного взаимодействия» (а именно: часть 110 «Принципы организации диалога» и часть 12 «Представление информации»)
2011: Pervasive Information Arcitecture Ресмини и Розати

Конечно, у каждого, даже самого крутого, набора эвристик найдутся свои минусы. Именно поэтому независимый консультант в области информационной архитектуры Эбби Коверт (Abby Covert) в 2012 году решила объединить все 5 подходов (а это более 50 эвристик) и создать универсальный набор, который было бы легко держать в памяти и удобно применять на практике.

Так что откройте сайт или приложение, над которым вы сейчас работаете, и посмотрите, соответствует ли его информационная архитектура следующим эвристикам:

Находимость

  1. Могут ли пользователи без особых усилий найти интересующую их информацию?
  2. Изменяется ли скорость обнаружения необходимой информации в зависимости от экранного разрешения или используемого девайса?
  3. Можно ли получить один и тот же контент различными способами (имеется в виду поиск, глобальная навигация, карта сайта и т. п.)?
  4. Как внешние и внутренние поисковые системы «видят» информацию сайта? Эффективно ли использованы построители запросов (query builders)?
  5. Сгруппированы ли результаты поиска? Насколько эта группировка логична?
  6. Что сделано для повышения релевантности найденной через поиск информации? Демонстрирует ли результат поиска дополнительную полезную информацию?

Доступность

  1. Доступен ли контент сайта на всех возможных устройствах и во всех экранных разрешениях?
  2. Остается ли взаимодействие последовательным на различных устройствах и разрешениях?
  3. Учитываются ли при дизайне требования для людей с различными формами отклонения в зрительном восприятии?

Понятность

  1. Легко ли воспринимается информация?
  2. Учитываются ли демографические факторы целевой аудитории?
  3. Путь к выполнению задачи очевиден для пользователя? Его ничто не отвлекает на этом пути?
  4. Сможет ли пользователь с легкостью описать последовательность выполненных действий?

Коммуникативность

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

Полезность

  1. Удобна ли текущая структура пользователям? Могут ли они решить свои задачи, не испытывая разочарования и не закрывая сайт/приложение на полпути?
  2. Дает ли текущая информационная архитектура возможность удовлетворить как нового пользователя, так и эксперта?
  3. Выделены ли пункты навигации, к которым пользователь с большей вероятностью обратится на следующем шаге? Понятно ли они названы?

Степень доверия

  1. Соответствует ли дизайн контексту использования и целевой аудитории?
  2. Регулярно ли обновляется контент?
  3. Нет ли перегруженности рекламой?
  4. Легко ли найти контактные данные реальной персоны?
  5. Легко ли пользователь может найти подтверждение компетентности компании?
  6. Используется ли вспомогательный контент (подсказки, faq и т. п.) там, где он может быть необходим?

Контролируемость

  1. Доступна ли дополнительная информация о взаимодействии с продуктом?
  2. Насколько качественно предвосхищаются и исправляются ошибки пользователя?
  3. Если ошибка все-таки случилась, легко ли пользователь может ее устранить?
  4. Есть ли функционал, позволяющий пользователю подстроить информацию под контекст использования?
  5. Кнопки выхода и другие важные контролы хорошо заметны?

Ценность

  1. Удовлетворяет ли контент какую-либо нужду целевого пользователя? Является ли желанным?
  2. Соответствует ли он паттернам взаимодействий на различных платформах и устройствах?
  3. Пользователь легко может описать, в чем для него заключается ценность сайта/приложения?
  4. Как степень качества информационной архитектуры может быть измерена? Влияет ли она на вашу прибыль? Влияет ли она на удовлетворенность пользователей?

Обучаемость

  1. Быстро ли пользователь может разобраться в структуре вашего сайта/приложения?
  2. Легко ли он сможет запомнить ее?
  3. Легко ли ее восстановить в памяти при следующем посещении?
  4. Сделано ли что-то для упрощения сложных комплексных процессов?
  5. Является ли взаимодействие настолько последовательным, что в определенный момент становится предсказуемым?

Креативность

  1. В чем ваши отличия от конкурентов и сервисов, предлагающих похожий опыт?
  2. Какие кроссплатформенные решения могут быть приняты как креативные?
  3. Какие ожидания пользователей не только удовлетворены, но и превышены?
  4. Какие неожиданные решения реализованы?
  5. Реализовали ли вы какие-то стандартные решения нестандартным путем?

Напоследок

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

Брюс Тоньяццини (Bruce Tognazzini), бывший сотрудник Apple, еще в далеком 1999 году разработал замечательный тест на знание закона Фиттса. Несмотря на то, что с того времени прошло уже 14 лет, сам тест не теряет своей актуальности (стоит только вспомнить, что свой закон Пол Фиттс разработал в 1954 году).

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

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

Обзор вопросов

Сперва пробегите глазами все вопросы теста, чтобы получить о нем представление. После этого вернитесь к первому вопросу и начинайте отвечать по порядку. Отнеситесь к этому тесту серьезно и избегайте ситуаций «Это слишком легко, конечно я знаю ответ!». Постарайтесь отвечать развернуто (желательно письменно) и аргументировать свою позицию.

Никаких ловушек в тесте нет. Все ответы основаны на реальных исследованиях.

  1. Большинство операционных систем предлагает пользователю возможность отображения текстовой подписи под каждой пиктограммой на рабочем столе (ярлыки, файлы, папки). Назовите как минимум одну причину, по которой пиктограммы с подписями являются более доступными. (Допустим, пользователь знает, что обозначает каждый графический элемент на рабочем столе и не нуждается в подписи для идентификации).
  2. Представьте стандартный графический редактор (Paint, Photoshop). Вдоль левого края приложения располагается панель основных инструментов редактирования изображения. Она представляет собой матрицу 2х8 (2 колонки и 8 рядов) из пиктограмм размером 16х16 пикселей. Какие шаги можно предпринять, чтобы ускорить время перехода к каждому из инструментов, не перемещая панель инструментов из левой части экрана и не изменяя размер иконок?
  3. Известно, что курсор мыши пользователя находится в центре экрана разрешением 1600х1200 пикселей. Нам необходимо, чтобы пользователь кликнул по цели размером 1х1 пиксель. Перечислите пять позиций для размещения целевой точки, по которым пользователь может кликнуть быстрее других. Дополнительно: учитывая, что пользователь — правша, перечислите позиции по порядку скорости доступа к ним.
  4. Панель задач Microsoft может быть расположена на любой из четырех границ экрана. Также есть возможность отображать ее либо постоянно, либо только при наведении курсора. Опишите, по крайней мере, 2 причины, по которым решение с появлением скрытой панели задач при наведении курсора является крайне неэффективным.
  5. Объясните, почему к строке меню в Macintosh можно получить доступ как минимум в 5 раз быстрее, чем к типичной строке меню в окне Windows. Дополнительно: предположите 2 причины, по которым Microsoft воплотил такое глупое решение.
  6. Назовите хотя бы одно преимущество радиального всплывающего меню над стандартным, линейным всплывающим меню.
  7. Что бы вы сделали, чтобы сбалансировать скорость доступа к тем пунктам выпадающего или всплывающего меню, которые находятся на  втором уровне и глубже?
  8. Промышленные дизайнеры Apple сократили размеры клавиатуры Mac на целых полкнопки, «обрезав» функциональные клавиши ровно наполовину, соответственно. Почему это было неправильным решением?
  9. Что является общим решением для всех заданных вопросов?

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

Ответы

Давайте начнем с ответа на вопрос 9 — общим решением является закон Фиттса.

Закон Фиттса: время, требуемое для позиционирования на какой-либо элемент есть функция от расстояния до этого элемента и от его размера.

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

Вопрос 1

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

Я вижу две причины (у вас их может быть и больше).

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

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

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

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

Вопрос 2

  • Представьте стандартный графический редактор (Paint, Photoshop). Вдоль левого края приложения располагается панель основных инструментов редактирования изображения. Она представляет собой матрицу 2х8 (2 колонки и 8 рядов) из пиктограмм размером 16х16 пикселей. Какие шаги можно предпринять, чтобы ускорить время перехода к каждому из инструментов, не перемещая панель инструментов из левой части экрана и не изменяя размер иконок?

В этот интерфейс можно внести две корректировки. Обе очень важны.

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

Вопрос 3

  • Известно, что курсор мыши пользователя находится в центре экрана разрешением 1600х1200 пикселей. Нам необходимо, чтобы пользователь кликнул по цели размером 1х1 пиксель. Перечислите пять позиций для размещения целевой точки, по которым пользователь может кликнуть быстрее других. Дополнительно: учитывая, что пользователь — правша, перечислите позиции по порядку скорости доступа к ним.

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

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

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

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

  • Правый нижний угол
  • Верхний левый угол
  • Правый верхний угол
  • Левый нижний угол

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

Вопрос 4

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

После первых трех заданий, этот вопрос уже не должен представлять сложности.

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

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

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

Вопрос 5

  • Объясните, почему к строке меню в Macintosh можно получить доступ как минимум в 5 раз быстрее, чем к типичной строке меню в окне Windows. Дополнительно: предположите 2 причины, по которым Microsoft воплотил такое глупое решение.

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

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

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

Затем я попросил обычных пользователей Mac перейти в один из пунктов меню на нижнем мониторе. В начале теста их курсор «вылетал» на верхний монитор где-то на 22 сантиметра, только потому, что они не боялись сильно толкать мышь. Затем они поняли, что должны замедлять курсор перед приближением к строке меню. К тому времени, как они достигли успеха, скорость их доступа к пунктам меню стала примерно равной скорости доступа к аналогичному меню в Microsoft.

Вопрос 6

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

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

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

Вопрос 7

  • Что бы вы сделали, чтобы сбалансировать скорость доступа к тем пунктам выпадающего или всплывающего меню, которые находятся на  втором уровне и глубже?

Виктор Замбрано (Victor Zambrano) предложил следующую технику: центрировать меню второго уровня, как это показано на картинке. В таком случае максимальное возможное расстояние между курсором и пунктом меню равно количеству всех пунктов меню, поделенному на 2.

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

Вопрос 8

  • Промышленные дизайнеры Apple сократили размеры клавиатуры Mac на целых полкнопки, «обрезав» функциональные клавиши ровно наполовину, соответственно. Почему это было неправильным решением?

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

Вопрос 9

  • Что является общим решением для всех заданных вопросов?

Теперь вы знаете, что это закон Фиттса. И вы можете использовать его в повседневном дизайне, будь то разработка новой операционной системы или создание веб-страницы. Например, не забывайте поставить несколько пробелов слева и справа от стандартной кнопки «ОК», ведь в ней всего две буквы. Если вы разрабатываете графический редактор, то убедитесь, что пользователь может выбрать инструмент, кликнув по самому краю экрана. Если в интерфейсе можно организовать панель меню в верхней части экрана, используйте это!

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

Оригинал материала: A Quiz Designed to Give You Fitts

Как научиться создавать удобные и современные продукты, от которых пользователи будут без ума? Следуйте этим девяти заповедям проектировщика взаимодействия:

Проводите исследования

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

Избегайте эмоциональной привязанности к проектам

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

Научитесь слушать и понимать людей

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

Привлекайте к проектированию всех членов команды

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

Проектируйте единым фронтом

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

Не используйте профессиональный жаргон

Избегайте UX-терминов при общении с членами вашей команды и, тем более, с заказчиками. Такие понятия, как «аффорданс» и «персоны», должны быть заменены более понятными словами. В противном случае вы можете показаться слишком высокомерными.

Будьте заметными

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

Подключитесь к UX-сообществу

Если вы читаете данный материал, то, скорее всего, вы уже выполняете этот пункт. Но если вас нет в Twitter, Facebook и вы не подписаны на обновления UX Booth, UX Magazine, UXmatteers, UX fox и массы других UX-ориентированных интернет-ресурсов, начните прямо сейчас. Находите проектировщиков интерфейсов в вашем городе, общайтесь, пишите материалы и выкладывайте результаты исследований в свой блог.

Никогда не прекращайте учиться

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

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

Как звучит закон Фиттса? Чем больше и ближе цель, тем быстрее мы кликнем по ней. Это легко понять, несложно реализовать и, кажется, этому не имеет смысла противоречить.

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

Правило 1: Создавайте цели больших размеров

Об этом в законе Фиттса говорится достаточно четко: чем больше цель, тем она доступнее.

Преимущества:

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

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

На левой кнопке несколько пикселей тратится впустую. А правая, используя каждый пиксель, имеющийся в распоряжении, обеспечивает более быстрое нажатие. (Слева: Firefox, справа: Apple)

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

Абсолютный и относительный размер элементов расставляет акценты в интерфейсе (пример: LibreOffice)

Несмотря на то, что существует гораздо больше аспектов, которые следует учесть при создании CTA-кнопки, закон Фиттса является наиболее значимым.

Возможные проблемы:

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

Используйте пиксели грамотно: юзабилити и размер цели имеют нелинейное отношение

Правило 2: Сведите к минимуму передвижение курсора

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

Преимущества:

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

Для примера можно рассмотреть интерфейс Ubuntu Unity. Он позволяет вам использовать два фильтра контента: текстовый и по типу файла. Однако заметьте, насколько далеко друг от друга они находятся. Текстовый фильтр находится на самом верху экрана, а фильтр по типу файла — в самом низу.

Несоответствие закону Фиттса: Поисковые фильтры часто используются в связке, соответственно должны быть расположены рядом. (Пример: Ubuntu Unity)

Возможные проблемы:

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

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

Сортировка элементов интерфейса в смысловые группы обеспечивает вашему интерфейсу понятную и последовательную структуру. (Пример: Numbers)

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

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

Выпадающие меню помогут структурировать содержание и разгрузить интерфейс. (Пример: Blurb.com)

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

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

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

Позиция элементов интерфейса может как вызвать, так и предотвратить ошибки. (Пример: Codebeamer.com)

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

Если я кликну не на ту ссылку, я могу просто нажать кнопку «Назад» в браузере. То есть нет ничего страшного в том, чтобы разместить рядом друг с другом ссылки в главном или боковом меню.

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

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

Чтобы минимизировать ошибки необходимо принимать следующие меры предосторожности:

  • Предлагать простой способ отмены выполненного действия
  • Оставлять пространство между кнопками
  • Подсвечивать элементы при наведении или выделении
  • Не группировать кнопки с абсолютно разными функциями

На последний пункт списка можно привести такой пример: если вы нажмете кнопку «Все письма» вместо «Написать письмо», то не случится ничего страшного, как если бы рядом были расположены кнопки «Ответить» и «Удалить».

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

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

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

Правило 3. Сведите к минимуму мышечное напряжение

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

Преимущества:

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

Закон Фиттса может облегчить и продлить взаимодействие с вертикальными сенсорными экранами. (Пример: Perceptive Pixel)

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

Возможные проблемы:

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

Выбор элементов пользовательского интерфейса в зависимости от «тяжести» их последствий: ползунки для опасных команд, кнопки для обычных. (Пример: iPhone)

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

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

Вторая причина, по которой здесь можно пренебречь законом Фиттса, — возможность использовать пространство более эффективно.

Хороший пример можно найти в интерфейсе deviantART. Для того, чтобы добавить элемент в избранное, вам не надо нажимать на кнопку. Вместо этого, как только вы начнете перетаскивать изображение, отобразится панель избранного, в которую его можно «положить».

Перетаскивание элементов обеспечивает функциональность без необходимости в видимых элементах. (Пример: deviantART)

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

Правило 4: Используйте «магические» пиксели

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

Преимущества:

Контекстное меню появляется на том самом пикселе, по которому вы кликнули. То есть путь до целевого элемента всегда равен нулю. Есть два вида контекстных меню: линейные и круговые (или радиальные).

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

Исходя из закона Фиттса, радиальные меню предпочтительнее, чем линейные. (Слева: OneNote 2013, справа: Firefox)

Преимущество размещения элементов на границах экрана в том, что курсор автоматически останавливается на них.

Углы и края экрана имеют наибольшую скорость доступа. (Схемы: Particletree)

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

Возможные проблемы:

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

На самом деле, несмотря на лучшее соответствие закону Фиттса, радиальное меню имеет ряд недостатков.

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

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

Группировка пунктов гораздо проще в линейном меню. (Пример: Word 2013)

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

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

  • Необходимо предоставить много вариантов
  • Будут использованы меню второго уровня
  • Важна группировка и ранжирование пунктов меню
  • Пространство на экране имеет очень важную роль

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

То же можно сказать об устройствах, которые работают без мыши: сенсорных экранах и других подобных. В случае с ними размещение элементов интерфейса в углах и по краям экрана не только не ускорит взаимодействие, но и может оказать обратный эффект. Было бы неправильно требовать от людей, пользующихся большими тачскринами, постоянно тянуться рукой в угол экрана. Соответственно, на больших девайсах, часто используемые инструменты должны быть сделаны свободно перемещаемыми. Так пользователи смогут работать более комфортно, помещая необходимые инструменты в соответствии с оптимальным положением рук (что, кстати, полностью отвечает закону Фиттса).

Выводы

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

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

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

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

Оригинал материала: When You Shouldn’t Use Fitts’s Law To Measure User Experience

Тому, кто занимается или интересуется пользовательскими интерфейсами, наверняка известен закон Фиттса. Его суть пердельно проста: чем больше элемент и чем ближе он к курсору, тем легче на него кликнуть. Это очень классно иллюстрирует Кевин Хэйл (KevinHale) в своей статье «Визуализация закона Фиттса».

Чтобы спасти вас от утомительного чтения, привожу укороченную версию закона Фиттса:

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

  • Область размером 1х1 пиксель в произвольном месте экрана
  • Область размером 5х5 пикселей в произвольном месте экрана
  • Более существенную область — 50х50 пикселей
  • Область размером 5х5 пикселей в углу экрана
  • Область 1х100 пикселей, которая находится на нижней границе экрана

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

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

Алан Купер пишет в своей книге «Об интерфейсе. Основы проектирования взаимодействия»:

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

Программы должны иметь «катапульты», чтобы пользователи могли время от времени перемещать внутри интерфейса стабильные объекты или существенно менять функциональность либо поведение приложения. Единственное, что никогда не должно случаться, — так это непреднамеренное катапультирование.

opposite-fitts-1.png

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

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

Давайте, к примеру, посмотрим на нашего друга Gmail:

Курсор находится между двумя кнопками и вы спросите: «Он хочет отослать письмо или сохранить его в черновиках?». Честно говоря, к тому времени, как я дописал это послание, полное ненависти, я уже успел остыть. Ничего, что я нечаянно отправил его адресату, вместо того, чтобы сохранить, мы всегда можем просто отменить отправленное письмо. Погодите-ка, мы ведь не можем! В данном случае кресло пилота было выброшено из кабины самолета.

Встречаются ситуации похуже. Например, когда я отправляю письма в архив:

В прошлом примере между кнопками было по крайней мере 10 пикселей, здесь же их целых… 3! Раз в пару дней я случайно отмечаю как спам то, что должно было быть заархивировано. Спасибо Google, что он предлагает простой и очевидный способ отменить такой случайный клик. Но я до сих пор не могу понять, неужели две кнопки, поддерживающие абсолютно различные функции, обязаны находиться рядом друг с другом?

Никто не оспаривает эффективность кнопки «Отменить», но было бы гораздо лучше, если бы мне вообще не приходилось нажимать эту кнопку. Может, было бы лучше разместить ее в другом месте и уменьшить? Взгляните на редактор постов для блога в WordPress:

Главным акцентом здесь является кнопка «Update» («Внести изменения») — ее легко заметить и по ней легко кликнуть. Менее важная кнопка «Переместить в корзину» представлена в виде гиперссылки и расположена на расстоянии от кнопки превалирующего действия.

В следующий раз, когда вы будете проектировать пользовательский интерфейс, обязательно следуйте закону Фиттса. Но не забывайте также про его обратное следствие: по редко используемым или «опасным» элементам должно быть сложно кликнуть.

Оригинал материала: The Opposite of Fitts' Law

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

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

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

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

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

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

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

Оригинал: Ignore details early on

Как сделать опыт пользователей идеальным? Анонимный пользователь Quora точно знает толк в UX. Поэтому, когда был задан вопрос «Какие, по вашему мнению, наилучшие ресурсы для изучения новейших веб-технологий, проектирования UI и UX?», он скромно ответил: «Лучший ресурс — тот, который я сейчас сам напишу». Этот пост посвящен переводу данного сакрального знания.

Итак, о каких 10 шагах нужно всегда помнить, чтобы достичь настоящих высот в UX?

1. Исследуйте проблему

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

Стоп!

Я уверен, что ваша новая техника CSS просто прекрасна, но не забывайте, что особенность проектирования интерфейсов или опыта взаимодействия — решение проблем пользователей. Насколько бы я ни был неравнодушен к CSS и ProximaNova, эти вещи не решают основных проблем, они только делают решения приятнее.

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

  • Сайт не оптимизирован для мобильных устройств
  • Сайт недоступен для людей с низким световосприятием
  • Страница загружается 12 секунд
  • Смысл приложения не очевиден сразу
  • Слишком длинная процедура регистрации

2. Изучите своих пользователей

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

  • каков их средний возраст?
  • какой браузер они используют?
  • как они пришли/придут на ваш сайт?
  • что они хотят получить от вашего сайта?
  • что ваш сайт хочет от них?

3. Научитесь качественно прототипировать

Теперь, когда мы знаем, кто наши пользователи и какие проблемы они испытывают, мы можем приступить к проектированию главной страницы. Все правильно?

Нет.

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

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

Итак, нам нужен заголовок, контент статьи, дата, затем… подождите. А нам точно нужно указывать дату? Влияет ли она на релевантность статьи? Если да, то оставляем. Если нет — убираем. Так необходимо продолжать, пока мы не добавим все необходимые элементы.

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

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

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

4. Эффективная коммуникация

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

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

5. Направляйте пользователей

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

6. Поддерживайте пользователей

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

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

7. Поощряйте пользователей

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

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

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

8. Изучите базовые технологии (HTML, CSS, JS, Ruby, Python и т. д.)

И этим все сказано.

9. Изучайте графический дизайн

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

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

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

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

Компоновка, баланс, выравнивание и контраст — необходимые навыки, когда дело доходит до выяснения наиболее эффективного способа организации контента на странице.

10. Учитесь, учитесь и снова учитесь

Есть бесчисленное количество ресурсов, на которых проектировщики могут найти необходимую информацию. Я приведу лишь некоторые из них:
Smashing Magazine
Nielsen Norman Group
52 Weeks of UX
Little Big Details
Aarron Walter
Paul Irish
Ryan Singer
Luke Wroblewski
Smashing Magazine