Мобильный UX: 7 правил дизайна для пальца, а не курсора
Правило зоны охвата: проектируйте там, куда реально дотягивается палец
Большинство дизайн-систем до сих пор преследует призрак курсора мыши. Кто-то, где-то нарисовал библиотеку компонентов в Figma, подразумевая пользователя с указателем мыши, и это допущение незаметно закрепилось в кнопках, меню и макетах, которые отправляются на телефоны без единого вопроса о том, дотянется ли до них большой палец. Как правило, не дотягивается — по крайней мере, без дискомфорта, а данные об этом лежат на поверхности уже больше десяти лет.
Исследование Стивена Хубера о том, как люди на самом деле держат телефоны — то самое, которое цитируют в каждой презентации по мобильному UX, но редко применяют на практике — показало, что примерно три четверти пользователей управляют телефоном одной рукой, держа его в ладони и выполняя все действия одним большим пальцем. У этого пальца есть естественная дуга движения. Нижняя треть экрана и центр — легко доступны. Верхние углы, особенно верхний левый при хвате правой рукой, требуют либо перехвата всего телефона в руке, либо помощи второй руки. На экране в 6,7 дюйма этот верхний левый угол с тем же успехом мог бы находиться на другом устройстве.
Это важно, потому что большинство интерфейсных соглашений были заложены до того, как телефоны стали такими большими. Гамбургер-меню в верхнем левом углу, стрелка «назад» в верхнем левом углу, логотип приложения в верхнем левом углу — всё это наследие адаптивного веб-дизайна, где положение «в верхнем левом углу» было логичным, потому что курсор мыши стартует откуда угодно и перемещается мгновенно. Палец не перемещается мгновенно. Он движется по физической дуге, привязанной к тому, как рука держит устройство, и каждый миллиметр за пределами этой дуги стоит пользователю смены хвата.
Практическое решение несложное, но требует реального картирования зон, а не догадок. Разделите экран на три горизонтальные полосы: нижняя треть — естественная зона большого пальца, доступная без движения руки. Средняя треть — зона растяжения, доступная при небольшом вытягивании пальца. Верхняя треть — трудная зона, доступная только при смене хвата или использовании второй руки. Получив такую карту, проверьте по ней каждый интерактивный элемент. Основные действия — те, которые пользователь совершает десятки раз за сессию — должны находиться в естественной зоне. Второстепенные и деструктивные действия могут располагаться в зоне растяжения. Трудная зона должна быть отведена под то, на что смотрят, но редко нажимают: строки состояния, заголовки, декоративный брендинг.
Я видел, как клиенты сопротивлялись этому подходу, потому что он выглядит «неправильно» с точки зрения десктопной ментальной модели, где важное располагается вверху. На мобильных устройствах важность и доступность — это две разные оси, и их смешение — прямой путь к тому, что кнопка удаления оказывается на расстоянии удобного взмаха пальцем, а кнопка «подтвердить покупку» требует смены хвата. Если из этой статьи вы вынесете только одну мысль, пусть это будет карта зон. Она должна быть буквальным артефактом в вашем файле дизайна, наложенным на каждый мобильный экран до размещения хотя бы одного компонента, а не правилом, которое вы держите в голове и надеетесь не забыть.
Правило 48 пикселей: размеры целей рассчитаны на подушечку пальца, а не на указатель
Курсор мыши — это одна точка с хирургической точностью. Подушечка большого пальца, касаясь стекла, покрывает область шириной примерно 40–55 пикселей в зависимости от человека и угла касания. Это не метафора — это физический факт о человеческой анатомии, который дизайнеры интерфейсов регулярно игнорируют, потому что их собственное тестирование происходит с мышью на 27-дюймовом мониторе, либо ухоженный указательный палец мягко и осознанно касается экрана во время демонстрации — что не имеет ничего общего с тем, как реальный большой палец ведёт себя во время рассеянного, однорукого взаимодействия на ходу.
Human Interface Guidelines от Apple задают минимальный размер сенсорной цели 44x44 пункта. Material Design от Google указывает 48x48dp. Обе цифры появились потому, что обе компании провели исследования, похожие на работу Хубера, и пришли к схожим выводам о минимальном размере, ниже которого промахи при нажатии становятся измеримой, раздражающей проблемой. И тем не менее я по-прежнему регулярно аудирую приложения — включая созданные командами, которые назвали бы себя внимательными к деталям — где кнопки-иконки имеют размер 32 пикселя с интервалом 4 пикселя, в панели инструментов, требующей точности мышиного указателя для надёжного использования.
Здесь есть конкретная и важная для понимания ошибка: визуальный размер и размер сенсорной цели — это не одно и то же, и их смешение — источник большинства проблем. Иконка размером 24 пикселя вполне может иметь вокруг себя сенсорную зону в 48 пикселей — иконка это то, что видит пользователь, зона — это то, с чем реально взаимодействует его палец, а отступ между ними невидим, но функционально критичен. Дизайнеры, не заложившие это различие в спецификации компонентов, в итоге получают иконки, которые прекрасно выглядят на статичном макете, но постоянно подводят в реальном использовании, потому что визуальный контур приняли за интерактивный.
Есть и вторая, более тонкая ошибка, которая, пожалуй, хуже слишком маленьких целей: цели правильного размера, расположенные слишком близко друг к другу. Две кнопки по 48 пикселей, стоящие вплотную без зазора, всё равно будут провоцировать промахи, потому что даже при щедрой цели палец не попадает с пиксельной точностью. Расстояние между целями нуждается в собственном минимуме — я использую 8 пикселей как нижний порог и предпочитаю 12 пикселей для всего деструктивного или трудно отменяемого, например, для кнопки удаления или отправки рядом с кнопкой редактирования. Именно здесь многие «чистые», минималистичные на вид интерфейсы незаметно подрывают сами себя: плотное расположение элементов выглядит изящно на макете и порождает обращения в поддержку в продакшене.
Ещё одно место, где это правило постоянно нарушается — интерфейсы с плотными данными: административные панели, дашборды, строки таблиц со встроенными действиями, — где дизайнеры пытаются впихнуть десктопную плотность информации в мобильный макет и в итоге получают сенсорные цели размером с чекбокс в электронной таблице. Если контент действительно требует такой плотности, честный ответ часто в том, что взаимодействие на мобильном должно быть полностью иным — свайп для раскрытия действия вместо трёх встроенных кнопок-иконок, нижний лист вместо встроенного выпадающего списка, меню по долгому нажатию вместо ряда крошечных иконок. Сжатие десктопных паттернов до нужного размера — это не мобильная адаптация, а мобильное извинение.
Правило смещения вниз: перемещайте основные действия вниз, а не вверх
Навигация — это самое яркое место столкновения привычек эпохи мыши с реальностью эпохи большого пальца, и это также место, за которое клиенты борются сильнее всего, пытаясь сохранить старый паттерн, потому что «навигация должна быть сверху» ощущается как непреложный закон дизайна интерфейсов, а не как конвенция, унаследованная от десктопных браузеров, где верхнюю часть экрана уже занимали адресная строка и кнопка «назад».
На мобильных устройствах данные говорят об обратном. Нижние панели вкладок стабильно превосходят верхнюю навигацию в юзабилити-тестах именно по причине, которую предсказывает исследование зон охвата: нижняя треть экрана — это то место, где большой палец уже находится. Именно поэтому iOS с самого начала использует нижние панели вкладок как полноценный нативный паттерн, и именно поэтому Material Design в Android активно продвигал нижнюю навигацию, как только большие телефоны стали нормой, а не исключением. Это не эстетическое предпочтение. Это прямой ответ на то, где на самом деле находятся руки.
Возражение, которое я слышу от клиентов чаще всего — и оно звучит разумно на первый взгляд — заключается в том, что нижняя навигация «загораживает контент» или «выглядит захламлённо» по сравнению с чистой верхней панелью с гамбургер-иконкой в углу. Два ответа на это. Во-первых, гамбургер-меню одновременно скрывает навигацию за дополнительным нажатием и перемещает её в труднодоступную зону — это по-настоящему плохое сочетание: вы делаете самый важный инструмент навигации в приложении и невидимым, и труднодоступным. Исследования гамбургер-меню за многие годы стабильно показывают более низкую вовлечённость с пунктами навигации, когда они скрыты за иконкой, по сравнению с теми же пунктами, представленными как видимые вкладки. Во-вторых, «загораживание контента» — реальная цена, но это цена за нечто ценное — мгновенный, доступный пальцу доступ к основным разделам приложения — и для большинства приложений этот обмен оправдан.
Та же логика применима и на уровень ниже навигации — к основному действию на любом конкретном экране. Если задача экрана — побудить пользователя сделать одно конкретное действие (добавить в корзину, отправить сообщение, сохранить черновик, подтвердить бронирование), кнопка этого действия должна находиться внизу экрана, а не парить вверху, как кнопка отправки в десктопной форме. Я до сих пор вижу процессы оформления заказа, где кнопка «Оформить заказ» находится в верхней части длинного прокручиваемого сводного экрана, вынуждая палец после просмотра деталей прокручивать обратно вверх — исключительно потому, что именно там её размещает десктопная версия того же процесса. Липкие нижние панели действий существуют как паттерн именно для решения этой проблемы — закрепите основное действие внизу видимой области, позвольте контенту прокручиваться под ней, и пользователю никогда не придётся перемещать палец, чтобы завершить задачу, ради которой он пришёл.
Здесь стоит отметить один нюанс, касающийся деструктивных или высокорисковых действий. Расположение внизу делает действия легко доступными, и именно поэтому необратимые действия — удаление аккаунта, отмена изменений, отмена подписки — не должны попадать в ту же зону лёгкого доступа, что и рутинные действия, без дополнительного трения. Решение не в том, чтобы переместить их в труднодоступное место, что создаёт другую проблему юзабилити, а в добавлении шага подтверждения или визуального отделения деструктивных действий от основного потока, чтобы случайное касание пальцем не запускало то, что пользователь не сможет отменить. Доступность и безопасность — это разные дизайнерские задачи, и макет со смещением вниз требует продуманного решения обеих.
Правило отсутствия наведения: убейте всё, что зависит от hover
На сенсорном экране наведение курсора не существует. Это звучит достаточно очевидно, чтобы не нуждаться в объяснении, и тем не менее это один из самых распространённых источников сломанного мобильного опыта, который я встречаю при аудитах — именно потому, что многие продуктовые команды проектируют для десктопа в первую очередь, а затем «адаптируют» мобильную версию, убирая стили, а не переосмысливая логику взаимодействия.
Классический пример — выпадающее меню, раскрывающееся при наведении. На десктопе пользователь наводит курсор на пункт навигации, и появляется подменю; убирает курсор — оно исчезает. Перенесите это напрямую на мобильные без переработки взаимодействия, и вы получите один из двух сломанных результатов: либо подменю никогда не появляется, потому что нет состояния наведения, которое бы его запускало, либо первое нажатие срабатывает как триггер наведения и раскрывает меню, требуя второго нажатия, чтобы что-то фактически выбрать — лишний шаг, о котором никто не просил и который большинство пользователей не обнаруживают самостоятельно, потому что ничто в статичном, выглядящем нажимаемым элементе не намекает «нажми меня дважды».
У всплывающих подсказок та же проблема в более тихой форме. Десктопный интерфейс может позволить себе скрыть поясняющий текст за состоянием наведения, потому что наведение ничего не стоит пользователю — это пассивное действие, курсор уже находится там. На мобильном раскрытие подсказки требует осознанного нажатия, которое конкурирует со всеми остальными нажатиями по этому элементу за смысл, и часто содержимое подсказки — объяснение поля, причина неактивности кнопки, детали статуса — это именно то, что пользователю нужно узнать до совершения действия, а не после. Если информация достаточно важна, чтобы оправдать подсказку на десктопе, она достаточно важна, чтобы быть видимой по умолчанию или доступной через явную, очевидно нажимаемую иконку на мобильном — а не выведенной из состояния наведения, которого никогда не будет.
Зависящие от hover аффордансы уходят глубже, чем меню и подсказки — они распространяются на сам визуальный язык. Десктопные интерфейсы регулярно используют состояние наведения, чтобы сообщить, что элемент интерактивен: карточка приподнимается тенью, ссылка подчёркивается, кнопка меняет цвет — всё это запускается прибытием курсора. Уберите мышь — и вы уберёте единственный сигнал, который говорил пользователю «это кликабельно». Я просматривал мобильные экраны, где каждый нажимаемый элемент визуально был идентичен каждому статичному, потому что единственное различие — тень при наведении — просто никогда не срабатывает на сенсорном экране, а альтернативный аффорданс для состояния покоя никто не создал взамен. Решение — сделать интерактивность видимой без движения или смены состояния: последовательное использование цвета, приподнятости, иконографии или подчёркиваний, присутствующих в состоянии покоя, а не вызываемых прибытием курсора.
Есть также категория взаимодействий, которая не просто смежна с наведением, а откровенно враждебна касанию: превью, запускаемые наведением, например миниатюра товара, которая «при наведении» показывает увеличенное изображение или дополнительное фото. На мобильных они либо не срабатывают, либо кто-то реализует их через долгое нажатие, которое большинство пользователей не обнаруживает, либо через простое нажатие, которое тогда конфликтует с нажатием, открывающим страницу товара. Ни один из этих вариантов не является хорошей заменой. Честный ответ чаще всего в том, что паттерны превью по наведению нужно переосмыслить с нуля под касание — например, карусель изображений с пролистыванием — вместо неуклюжего наложения на жест, который никогда не был предназначен для этого смысла.
Правило одной руки: рассчитывайте на одну руку, а не на две
Дизайн-макеты, как правило, подразумевают идеализированного пользователя: обе руки свободны, всё внимание сосредоточено на экране, нажатия осознанные и аккуратные. Реальное использование мобильных устройств выглядит совершенно иначе. Люди проверяют телефон, держа кофе, стоя в поезде и держась за поручень, неся ребёнка, идя пешком или краем глаза поглядывая в телевизор. Одна рука занята чем-то другим, и рука с телефоном часто оказывается единственной доступной рукой для всего взаимодействия — включая то, что «очевидно» требует двух рук в вайрфрейме, например, набор сообщения с одновременным нажатием кнопки отправки на противоположном краю широкого экрана.
Это напрямую влияет на компоновку, выходя за рамки уже обсуждённого картирования зон охвата. Двуручные взаимодействия — сведение пальцев для масштабирования, перетаскивание элементов по широкому холсту, мультитач-жесты — следует рассматривать как усовершенствования, а не как единственный способ выполнить задачу. Если сведение пальцев — единственный способ рассмотреть карту или детали изображения, пользователи, оказавшиеся однорукими не по своему выбору, а по обстоятельствам, лишаются доступа к базовой функции. Резервный вариант с двойным нажатием для увеличения, выделенный элемент управления масштабом или кнопка «полноэкранный режим», перестраивающая контент так, чтобы его можно было прочитать вообще без масштабирования — это не приятные дополнения, а разница между функцией, которая работает для человека, реально держащего кофе в другой руке, и функцией, которая работает только на дизайн-ревью.
Разделённые на части и расположенные бок о бок макеты заслуживают особого внимания в свете этого правила. Сравнительная таблица, ползунок «до/после» или двухколоночная форма, которые имели смысл на макете для планшета, часто втискиваются в экран телефона так, что технически помещаются, но требуют, чтобы палец многократно преодолевал всю ширину экрана — от метки слева до поля ввода справа и обратно, десятки раз в течение заполнения формы. На телефоне, который держат одной рукой, такое перемещение по всей ширине — эквивалент гамбургер-меню в верхнем левом углу: технически доступно, практически изматывающе. Расположение этих элементов вертикально, даже ценой более длинной прокрутки, почти всегда лучший обмен, потому что вертикальная прокрутка — это движение, для которого палец создан, а горизонтальный охват на всю ширину — нет.
Дизайн форм — это место, где допущение об одной руке окупается наиболее конкретно, потому что формы — это место, где пользователь проводит длительное, повторяющееся взаимодействие, а не единичное нажатие. Подписи полей, поля ввода, сообщения о валидации и кнопки отправки должны находиться в единой вертикальной колонке, по которой палец может перемещаться, ни разу не пересекая экран по горизонтали. Автозаполнение, умные типы клавиатуры (цифровая клавиатура для номеров телефонов, клавиатура с открытым символом @ для email) и значения по умолчанию, сокращающие набор текста — всё это важнее на мобильных устройствах, чем на десктопе, именно потому что набор текста одним пальцем медленный и подверженный ошибкам так, как набор десятью пальцами на физической клавиатуре — нет. Каждое поле, которое можно предзаполнить, вывести автоматически или превратить в единичное нажатие — выбор даты вместо набора цифр, переключатель вместо набранного «да/нет» — небольшая милость для пальца, который делает всю работу в одиночку.
Правило уважения к жестам: свайпайте так, как это делает ОС, а не против неё
Каждая крупная мобильная платформа годами обучала пользователей определённому набору жестов: свайп от левого края назад, свайп вниз для обновления, свайп вниз от верхнего правого угла для открытия центра управления, долгое нажатие для контекстного меню, свайп влево по элементу списка для раскрытия действий. Это не жесты вашего приложения, которые можно переопределить. Они принадлежат операционной системе и годам мышечной памяти, накопленной каждым пользователем во всех остальных приложениях, которыми он когда-либо пользовался, и борьба с этим набором внутри вашего собственного продукта создаёт трение, не имеющее ничего общего с вашим дизайном и всё — с нарушением ожидания, о котором пользователь не подозревал, пока оно не подвело его.
Самое распространённое нарушение — переприсваивание жеста «свайп от края для возврата» под что-то другое, например, кастомное боковое меню, выезжающее слева, напрямую конкурирующее с системным жестом iOS «вернуться на предыдущий экран». Пользователи, пытающиеся вернуться назад и случайно открывающие вместо этого меню, не думают «о, у этого приложения тут кастомный жест». Они думают, что приложение сломано, или теряются, потому что жест, которому они доверяют во всех остальных приложениях, только что сделал нечто неожиданное. Если дизайн предполагает выезжающую панель, более безопасный выбор — запускать её нажатием на иконку, оставляя зону свайпа от края для собственной навигации системы.
Свайп для обновления — похожий случай, но в противоположном направлении: это жест, который стоит перенять, а не избегать, потому что он стал настолько сильной конвенцией (изначально популяризированной Twitter, теперь стандартной практически во всех приложениях-лентах), что именно его отсутствие ощущается сломанным. Пользователи тянут список вниз, ожидая загрузки нового контента, и если ничего не происходит, они предполагают, что приложение зависло, а не то, что функция просто не была реализована. Как только жест становится настолько универсальным, относиться к нему как к опциональному улучшению, а не базовому ожиданию — ошибка.
Действия по свайпу на элементах списка — свайп влево для удаления, свайп вправо для архивирования — мощны именно потому, что позволяют пользователю действовать, не покидая зону досягаемости пальца и не выискивая маленькую иконку-кнопку, но они несут в себе издержку обнаруживаемости, которую легко недооценить. Ничто в статичной строке списка визуально не намекает, что она поддерживает свайп, в отличие от кнопки, которая своей формой хотя бы подразумевает «нажми меня». Именно поэтому хорошо спроектированные свайп-взаимодействия почти всегда сочетаются с видимым, нажимаемым резервным вариантом — небольшой иконкой, выполняющей то же действие через простое нажатие, — вместо того чтобы делать свайп единственным путём. Свайп для архивирования в Gmail, свайп для удаления в Apple Mail и большинство современных приложений для списков дел поступают именно так: жест — это быстрый путь для тех, кто его освоил, а иконка или меню — путь для всех остальных. Полагаться только на свайп как на единственный механизм, особенно для нового пользователя, у которого нет предварительного представления о конкретно вашем приложении, незаметно лишает значительную часть аудитории доступа к ключевому действию.
Долгое нажатие — жест, который недоиспользуется чаще всего, во многом потому, что он наименее обнаруживаем из всех: ничто визуально не намекает, что долгое нажатие вообще что-то делает, а значит, оно никогда не должно быть единственным путём к важному действию, но оно по-настоящему полезно как второстепенный ярлык для продвинутых пользователей — для таких вещей, как изменение порядка элементов списка, открытие меню быстрых действий (как демонстрируют иконки на главном экране iOS) или предварительный просмотр контента без полного открытия. Относитесь к нему как к бонусному слою для тех, кто исследует интерфейс, а не как к единственной двери к функции, нужной более широкой аудитории.
Правило реального телефона: тестируйте одной рукой, в движении, только пальцем
Каждое из перечисленных выше правил можно понять умом и всё равно нарушить на практике, потому что среда тестирования, которую реально используют большинство команд дизайна, наименее репрезентативна из всех возможных: дизайнер сидит за столом, мышь в руке, смотрит на мобильный макет на мониторе, или, в лучшем случае, тапает по прототипу на телефоне, установленном на подставке или бережно держащемся обеими руками при полном внимании. Такая среда почти ничего не проверяет о том, как интерфейс будет реально использоваться.
Решение ничего не стоит и занимает минуты, что делает пропуск этого шага непростительным: физически возьмите реальный телефон, держите его так, как его держит реальный пользователь — одной рукой, вся работа на большом пальце — и пройдите основные сценарии, отвлекая при этом своё внимание на что-то другое, как это делают реальные пользователи. Ходите по офису, тестируя процесс оформления заказа. Попробуйте, держа чашку кофе в другой руке. Попробуйте, держа телефон в недоминирующей руке, ведь не каждый пользователь держит телефон так же, как вы привычно это делаете. Попробуйте при ярком солнечном свете, если продукт будет использоваться на улице, поскольку решения по контрасту и размеру шрифта, которые выглядят нормально на откалиброванном мониторе, часто проваливаются на фоне реальных бликов дневного света.
Такое тестирование выявляет проблемы, которые никогда не обнаружит рассматривание Figma. Кнопка, технически имеющая размер 48 пикселей, но расположенная так, что закруглённый край чехла телефона делает нажатие неудобным. Жест свайпа, который прекрасно работает при осознанном тестировании, но постоянно случайно срабатывает во время обычной прокрутки. Форма, которая совершенно удобна при внимательном заполнении сидя, но разваливается в тот момент, когда вы одновременно пытаетесь не пропустить свою остановку автобуса. Это те режимы отказа, которые порождают реальные обращения в поддержку и реальные однозвёздочные отзывы в магазине приложений, и они неизменно невидимы в контролируемой обстановке дизайн-ревью.
Дизайнер, с которым я работал над сценарием онбординга в финтех-продукте, хорошо сформулировал это после серии коридорного тестирования: «Всё, что мы одобрили в переговорной, ломалось в ту же секунду, как кто-то пробовал это стоя».
Формальное юзабилити-тестирование должно следовать той же логике, а не только неформальные командные прогоны. При наборе участников для сессий мобильного юзабилити-тестирования сопротивляйтесь инстинкту усаживать их за стол с телефоном, лежащим плоско перед ними, как маленький ноутбук — такая поза провоцирует двуручное, осознанное взаимодействие, не соответствующее реальности. Попросите держать телефон так, как они держат его обычно, желательно стоя, а если вы действительно хотите честный сигнал, попросите их проходить тест, одновременно держа что-то ещё, или пусть модератор непринуждённо разговаривает с ними, чтобы смоделировать то раздвоенное внимание, при котором происходит большая часть реального использования. Цель не в том, чтобы сделать тест искусственно сложнее, а в том, чтобы перестать делать его искусственно легче, чем реальная жизнь, — а именно это неосознанно делает почти любой лабораторный мобильный тест.
Наконец, это правило распространяется на ревью и утверждение, а не только на первичное тестирование. Дизайн-критика и презентации клиентам почти повсеместно проходят на больших внешних мониторах, где макеты увеличены намного больше любого реального экрана телефона, рассматриваются на удобном расстоянии вытянутой руки, а взаимодействие происходит точной мышью. Такая обстановка льстит отступам, которые на самом деле слишком тесные, и скрывает цели, которые на самом деле слишком маленькие, потому что всё увеличено, а тот, кто оценивает, сам не работает пальцем. Перед окончательным утверждением поместите реальную сборку на реальный телефон и передайте её реальному человеку, принимающему решение. Это небольшой ритуал, но он — самый надёжный фильтр для выявления любого нарушения шести предыдущих правил до того, как продукт выйдет в свет, потому что курсор мыши и монитор простят ошибки, которых никогда не простит большой палец, в автобусе, в спешке.
