Привет! Я Коля Димов, руковожу дизайном и исследованиями продукта в Делимобиле.
У приложения Делимобиля есть важная особенность: часть пользовательских сценариев приходится на момент, когда пользователь находится за рулём. При этом не обязательно, что в этот момент он что-то должен делать в приложении.
В какой-то момент мы внутри команды начали задавать себе довольно простой вопрос: а как вообще правильно проектировать эти сценарии? На что опираться, если хочется не просто сделать покрупнее кнопки, а реально понять границы безопасного и уместного поведения продукта? Выяснилось, что одного ответа нет. Нет главного стандарта, который бы честно сказал: вот каким должно быть приложение для водителей, вот что можно, а вот что нельзя.
В этой статье хочу поделиться тем, что нам удалось собрать и проанализировать, а также показать, как это может быть полезно в продуктовом дизайне. Какие стандарты вообще есть, чем они полезны и что из этого дизайнер может забрать в работу уже сейчас. При анализе стандартов совсем без специфичных терминов к сожалению нельзя, но я постарался их максимально упростить.
Какие гайдлайны существуют
Если упростить, дизайнеру сегодня есть на что смотреть с четырёх сторон. ISO 15008:2017 и его российская версия ГОСТ Р 58497-2019 объясняют визуальное восприятие информации: читаемость, контраст, размер символов, яркость, блики и другие параметры отображения на дисплее для водителя. Рекомендации NHTSA по visual-manual driver distraction (визуально-мануальное отвлечение водителя) описывают, какие действия отвлекают водителя слишком сильно и какие сценарии лучше вообще не допускать во время движения. NHTSA Human Factors Design Guidance собирает более широкий слой знаний про человеческий фактор: звук, голос, предупреждения, приоритеты сигналов и особенности восприятия. Android Automotive Driver Distraction Guidelines показывают, как всё это превращается в реальные ограничения интерфейса на уровне платформы.
Один документ отвечает на вопрос «видно ли это вообще». Другой — «не слишком ли это отвлекает». Третий — «что делать со звуком, голосом и предупреждениями». Четвёртый — «как эти идеи превращать в конкретные продуктовые ограничения».
И это, кстати, полезно принять сразу. Когда начинаешь искать «стандарт для интерфейсов водителя», очень хочется найти один PDF и на этом успокоиться. Но по факту приходится собирать свою опору из нескольких источников. Важно оговориться: ниже речь идёт именно о полезных ориентирах для дизайна, а не об исчерпывающем нормативном документе для всех рынков и всех типов интерфейсов.
ISO и ГОСТ: стыдно когда не видно
ISO 15008 и ГОСТ Р 58497 не регулируют весь UX интерфейса для водителя. Эти документы в первую очередь про визуальную подачу информации: как человек различает символы, считывает контраст, воспринимает цвет и видит экран в разных условиях освещения.
Стандарты отвечают на вопрос «сможет ли человек вообще быстро увидеть и распознать то, что мы ему показали».
Например, в них есть конкретные требования по контрасту для разных условий. Ночью минимальный коэффициент контраста — 5:1 ночью, в сумерках — 3:1, при дневном рассеянном свете — 3:1, под прямым солнцем — 2:1. Если проще: интерфейс нельзя проверять только в одном режиме. Если интерфейс живёт в машине, его нужно смотреть отдельно ночью, днём, при ярком свете и в сумерки. Эти цифры стоит использовать как ориентир для проверки, а не как единственный критерий качества интерфейса.
Есть ещё одна штука, которая звучит академично, но очень полезна. Размер символов в ISO и ГОСТ задаётся не в пикселях и не в пунктах, а в угловых минутах — то есть через то, каким по факту знак выглядит с точки наблюдения. Рекомендуемый уровень — 20 угловых минут, приемлемый — 16, минимальный — 12. Важно не то, какой размер текста стоит у вас в Figma. Важно то, насколько крупной надпись выглядит с расстояния до глаз водителя. Если телефон находится в держателе на приборке, он гораздо дальше, что телефон в руке. А значит, одна и та же информация начинает восприниматься по-другому.
Если взять дистанцию около 60 см, рекомендуемый угловой размер 20' даёт высоту символа примерно 5,8 мм. На человеческом языке это означает следующее: то, что в обычном мобильном интерфейсе кажется «нормальным текстом», в машине часто оказывается неразборчивым.
Стандарт полезен и в деталях, которые обычно ускользают. Он задаёт требования к пропорциям шрифта: слишком узкие и слишком широкие формы букв не приветствуются, как и слишком тонкие или слишком жирные начертания. Он ограничивает использование мигания: мигающие элементы допустимы только для привлечения внимания в критических ситуациях, причём в диапазоне 1–5 Гц, а непреднамеренное мерцание и дрожание изображения вообще запрещены. Плюс он отдельно говорит о бликах, отражениях и полярности экрана — то есть о том, когда светлый фон уместнее, а когда тёмный.
Про светлую и тёмную тему. Стандарт не говорит «делайте только dark mode» или «делайте только light mode». Ночью тёмный фон предпочтительнее, а днём светлый режим может работать лучше, если помогает бороться с отражениями. То есть вопрос не во вкусе, а в контексте использования.
Если перевести всё это на язык дизайн-системы, из ISO и ГОСТ я бы забрал пять практических правил:
Контраст надо проверять отдельно для ночи, сумерек, обычного дня и яркого солнца;
Типографика работает иначе: её нужно смотреть ещё и через реальное расстояние до экрана;
Не использовать слишком узкие, слишком тонкие и слишком жирные шрифты;
Мигающие анимации — только для критичных случаев, а не для красивого интерфейса;
Блики и отражения — это не эстетическая проблема, а прямой фактор ухудшения читаемости.
ISO и ГОСТ не описывают логику пользовательских сценария, не говорят, сколько шагов допустимо, не учат проектировать жесты и в целом не решают проблему отвлечения внимания. Более того, стандарт не покрывает HUD, ряд классов изображений, изображение с камеры заднего вида, а карты и навигационные изображения выведены из его области применения. Поэтому его нельзя использовать как единственную основу для вывода о безопасности сценария.
Из-за этого можно сделать сценарий, который формально читается, но всё равно подвергает риску водителя. Он будет аккуратным, контрастным, красивым — и при этом требовать десять секунд чтения, несколько переходов и ручной ввод.
Рекомендация от NHTSA: не отвлекай
Если ISO и ГОСТ отвечают на вопрос «видно ли это», то рекомендации NHTSA (Национальное управление безопасностью движения на трассах США) по visual-manual interaction отвечают на другой: «не слишком ли интерфейс отвлекает от дороги».
Здесь начинается очень полезный слой не только для дизайнеров, но и для продактов. Важная мысль документа: некоторые действия не нужно разрешать во время движения. К таким действиям относятся ручной ввод текста, чтение длинных текстов, просмотр видео и другой контент, который требует длительного визуального внимания.
NHTSA рекомендует использовать ориентир для оценки — один отдельный взгляд на экран не должен длиться больше 2 секунд, а суммарное время взгляда на задачу не должно превышать 12 секунд. Для продуктового дизайнера это почти готовый тест на вменяемость сценария. Если экран требует читать, сравнивать, вспоминать, искать нужный пункт в длинном списке и держать в голове, что ты делал на прошлом шаге, — этот сценарий опасный для водителя.
Отсюда довольно легко собрать несколько очень приземлённых правил:
Не стоит рассчитывать, что человек будет читать в движении
Не стоит разрешать ручной набор текста в движении
Не стоит строить сценарии, где нужно долго искать нужный вариант среди множества пунктов
Не стоит прятать важное действие глубоко в структуру экранов
Любое действие должно быть прерываемым и не требовать длинного непрерывного внимания
Мне кажется, именно здесь и ломается дизайнерская иллюзия. За ноутбуком многие экраны кажутся простыми. В машине та же «простота» быстро испаряется: нужно прочитать несколько строк, понять, куда нажать, попасть в небольшой элемент, дождаться ответа системы и не потерять нить сценария.
Human Factors и Android Automotive: когда одного разговора про экран уже мало
NHTSA Human Factors Design Guidance смотрит на водительские сценарии шире. Этот документ не является стандартом, скорее дополнение. Но при этом охватывает визуальные интерфейсы, звук, речевые сообщения, тактильные сигналы, предупреждения и логику приоритизации сообщений. В нём, например, отдельно разбирается, как ощущаемая срочность сигнала должна соответствовать реальной срочности ситуации, почему частые ложные предупреждения приводят к усталости от оповещений и почему голосовой интерфейс может уменьшить визуальную нагрузку, но не убирает когнитивную.
Для мобильных приложений это особенно полезно. Потому что безопасный интерфейс — это не всегда «показать попроще». Иногда лучше вообще ничего не показывать, а озвучить. Иногда — дать короткий звук. Иногда — отложить действие до остановки. Иногда — не тревожить пользователя без реально важного повода.
Android Automotive Driver Distraction Guidelines зашивает безопасность на уровне платформы: есть режим «без ограничений» и есть режим движения, в котором допускаются только специальные distraction-optimized экраны. Google также описывает модель restricted/unrestricted state и подход, при котором поведение интерфейса зависит от состояния автомобиля.
Да, это история не про обычный смартфон, а про Android Automotive OS. Но как образец для мышления это очень хороший ориентир. Интерфейс в движении не должен быть просто «тем же самым, только чуть крупнее». Он должен быть другим по набору действий, по глубине сценариев и по уровню свободы, который мы оставляем пользователю.
Самый полезный вывод из всей темы: стоянка и движение — это не два визуальных состояния одного экрана. Это два разных режима использования продукта.
Что из этого можно забрать в мобильное приложение
Попробуем собрать. ISO и ГОСТ дают базу для визуальной читаемости. NHTSA Visual-Manual задаёт рамки допустимых задач и помогает оценивать отвлечение. NHTSA Human Factors добавляет звук, голос, предупреждения и общую логику восприятия. Android Automotive показывает, как всё это можно превращать в режимы интерфейса и жёсткие ограничения на уровне продукта.
Если переводить это на язык мобильного приложения, я бы вынес несколько выводов.
Нужен отдельный режим движения. Не тот же экран, но чуть крупнее, а отдельное состояние продукта с урезанными сценариями, крупными приоритетными действиями и отказом от всего, что требует лишнего внимания.
Экраны полезно делить по степени риска. Какие-то вещи можно показывать в движении: короткие статусы, один главный сценарий, простые подтверждения, крупные навигационные подсказки. А какие-то лучше сразу убирать до остановки: настройки, длинные списки, история, чтение, ручной ввод, сложные выборы.
Визуальные требования нельзя проверять только в макетах. Текст, который отлично выглядит в руке, на расстоянии около 60 см может уже стать мелким. Контраст, который кажется нормальным в помещении, на ярком солнце может просто не дожить до реального использования
Оценивать надо не только внешний вид, но и цену внимания. Сколько коротких взглядов требует экран. Сколько решений пользователь должен принять. Можно ли прервать задачу в любой момент. Можно ли заменить часть сценария звуком, голосом или более простым действием.
Важный вывод: хороший интерфейс для водителя — не тот, который умеет всё. Хороший интерфейс для водителя — тот, который не отвлекает.
P.S. Чеклист для проверки
Ниже — короткий чеклист, с помощью которого можно проверить сценарий для водителя:
Можно ли понять, что делать на экране, за один короткий взгляд?
Не заставляет ли экран читать больше одной-двух коротких смысловых единиц?
Не требует ли сценарий ручного ввода текста?
Нет ли здесь длинного списка, в котором надо что-то искать?
Есть ли одно главное действие, которое визуально очевидно?
Можно ли прервать сценарий в любой момент и не потерять контекст?
Достаточно ли крупный текст и не развалится ли он на дистанции от глаз до телефона?
Проверяли ли экран ночью, днём и при ярком свете?
Не пытаемся ли мы решить задачу экраном там, где лучше сработал бы звук, голос или отложенное действие?
Точно ли этот экран вообще нужен в движении, а не только на стоянке?
Я Коля Димов, дизайн-директор с опытом в шеринге, ретейле и тревеле.
Пишу свои мысли и наблюдения в телеграм-канале @quitdesi