Гайдлайны для дизайна водительских продуктов

от автора

Привет! Я Коля Димов, руковожу дизайном и исследованиями продукта в Делимобиле.

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

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

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

sddg.delimobil.design

Почему мы решили сделать свои гайды

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

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

Для кого эти гайды

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

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

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

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

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

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

Главное правило

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

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

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

Когда мобильный интерфейс попадает в машину

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

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

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

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

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

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

Как устроены гайды

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

Первый слой

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

Второй слой

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

Третий слой

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

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

Вместо заключения

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

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

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

ссылка на оригинал статьи https://habr.com/ru/articles/1041106/