惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Last Week in AI
Last Week in AI
阮一峰的网络日志
阮一峰的网络日志
P
Proofpoint News Feed
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
MongoDB | Blog
MongoDB | Blog
云风的 BLOG
云风的 BLOG
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
J
Java Code Geeks
WordPress大学
WordPress大学
T
The Blog of Author Tim Ferriss
V
Visual Studio Blog
小众软件
小众软件
Microsoft Azure Blog
Microsoft Azure Blog
博客园_首页
IT之家
IT之家
Vercel News
Vercel News
C
Check Point Blog
Google DeepMind News
Google DeepMind News
月光博客
月光博客
D
DataBreaches.Net
酷 壳 – CoolShell
酷 壳 – CoolShell
美团技术团队
Y
Y Combinator Blog
Hugging Face - Blog
Hugging Face - Blog

Все публикации подряд на Хабре

Ловим музу за клавиатуру: как айтишнику стать автором Что умеет Midjourney в 2026? Мой немного грустный разбор этого шикарного инструмента Никто не любит писать тесты, но ИИ может исправить это IPv8 выглядит как мечта. Поэтому почти наверняка не взлетит Производители вернули в продажу материнки с DDR3. Что происходит? Управление агентом с телефона через Telegram теперь в KodaCode От координации к лидерству: как меняется роль руководителя разработки Я сделала родителям бизнес вместо пенсии: зарабатываем 70 тысяч, мама не даёт продать В три раза быстрее приемка товара и оптимизация трудозатрат на 73%: как «РСТ-Инвент» помог Gulliver Group ИИ-шечный мир победил? О влиянии искусственного интеллекта на игропром Кремль снижает давление на Телеграмм пока Европа строит интернет по паспорту Как CEO, CTO и CIO за 8 часов собрали ИИ-директора, который умеет держать позицию под давлением Как (не) потерять домен за выходные Вместо 8 разных VPS: как я организовал практику студентам на одном сервере Почему твой Open Source проект не замечают? R&D: искусство управления неопределенностью в разработке AI-дефляция: вакансий для разработчиков больше, а рост зарплат — худший за 15 лет Мы отдали управление роботами OpenClaw. Что из этого вышло Галактический ID: система идентификации для всех форм разумной жизни Шесть основ бизнес-анализа: начинаем с вопроса «Кто в игре?» Код-ревью, в котором дело не в коде Данные переехали. Команда — нет Системной подход к сдаче OSWE в 2025 Почему комната управления реактором покрашена в цвет морской пены 4 YAML-файла вместо PySpark: как аналитикам строить пайплайны без разработчиков LLM-агент для поиска свободных доменов: автоматизируем подбор Когда, зачем и как правильно начинать новую сессию в Claude Code? Как я заставил нейросеть писать макросы для FreeCAD Анатомия ИИ‑агента для подбора персонала. От тысячи резюме к топ‑10 за минуты Опыт разработчика как экономика внимания
Гайдлайны для дизайна водительских продуктов
Николай Димов · 2026-05-29 · via Все публикации подряд на Хабре

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

5 мин

6K

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

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

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

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

sddg.delimobil.design

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первый слой

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

Второй слой

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

Третий слой

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

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

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

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

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

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