Every seat gets a first‑class screen. And the screens work together.

Overview and principles

AVENUE is an infotainment system for the whole car. The driver, the co-pilot and each rear passenger get a screen with a mode of its own, and the screens share one system: what is playing, the route, the cabin's climate and what one seat sends to another.

It began as a rear-seat system for luxury cars, researched with rear-seat passengers and A/B tested. The rear-seat modules on this page come from that work. The driver and co-pilot modes are a design extension of it and have not yet been tested with users; we say so wherever they appear.

Principles

1. Every seat is first class. The rear screens match the quality of the front, because the research found passengers in the back reaching for their own tablets.
2. One system, many modes. Each seat sees the same state in the form that suits it. Nothing is designed for one screen alone.
3. The driver's eyes stay on the road. While the car moves, the driver's screen shows only what can be read at a glance and hands everything else to voice, physical controls or another seat.
4. Nothing takes over a screen uninvited. Sharing asks the receiving passenger first.
5. Physical feel, honest feedback. Controls press, confirm and say what happened, in words as well as motion.
6. Readable at night, readable in sun. Dark first, with every pair of colours meeting WCAG 2.2 AA.

Architecture

AVENUE is described here as a design system plus a reference implementation (this page's demo, written for the web). How it runs inside a vehicle is scoped with each partner; see integration.

Seat modes

Each screen runs in one of three modes: driver, co-pilot or rear. A mode decides which modules appear, how large targets are and which rules apply while the car moves. The rear mode is the researched design; driver and co-pilot are extensions of it.

Shared state

One state for the whole car, read by every screen:

• Journey: route, ETA, next turn, places along the way.
• Media: each seat's now playing, position and queue.
• Cabin: climate per zone (with the rear zones optionally synced), lighting, seats.
• Routines: presets that set several of the above at once.
• Vehicle: parked or moving, which the driver rules read.
• Inbox: per seat, what other seats have sent and not yet been answered.

In the reference implementation this is one reducer (src/demo/system.ts); every screen, including the four drawn into the 3D cabin, reads it. The lockout rules live in the reducer, not in the screens, so no screen can forget them.

Content routing

A seat can send what is playing, a place or a memory clip to any other seat (card Y). The item lands in the receiving seat's inbox as a card with two choices: accept (play it there, or add the place to the route) or not now. Video sent to the driver while moving is held until the car is parked.

Permission model

* NHTSA's guidelines cover any built-in device the driver can easily see or reach, even one meant for passengers. A co-pilot screen visible from the driver's seat therefore needs either a view-angle (privacy) filter or the driver's rules while moving. Which one is a hardware decision, scoped per partner.

Module reference

Each module with its states, the requirement cards it answers, and what happens on the driver's screen while the car is moving. Cards are from the rear-seat research; open them in the requirements.

Design system

Everything below is rendered live from one tokens file (src/design/tokens.ts). The site, the in-car interface and these tables all read it, so they cannot drift.

The high-fidelity concept used a neumorphic palette. We kept the soft-surface feel (a top highlight and a low, wide shadow instead of hard borders) and restyled it so that every text and control meets WCAG 2.2 AA: neumorphism's soft, low-contrast edges usually fail it.

Colour

Two themes: cabin (dark, the default, because car interfaces live at night) and paper (light, for documentation). One accent, amber: warm enough not to wash out night vision and strong enough to read on dark glass and on paper. On paper it steps darker, so a fill still stands 3:1 off the page. Red is reserved for SOS.

Contrast

Every pair the interface uses, checked against WCAG 2.2 AA in both themes (also enforced by a unit test):

Type

Display: Archivo, set wide and light, for headings and the wordmark. Interface: Instrument Sans. Numbers and specifications: DM Mono, with tabular figures so changing values never shift. All three are free (SIL Open Font License) and self-hosted.

Spacing, radius and elevation

A 4 px base. Radii are concentric: an outer radius equals the inner radius plus the padding between them.

Core components

The same components the demo is built from, live:

Interaction and motion

Controls feel physical

• Press: a control scales to 0.96 in 160 ms on an easing that starts fast and settles without overshoot (cubic-bezier(0.2, 0, 0, 1)), and a pressed control sinks (an inset shadow). Releasing returns it the same way, and a press can be interrupted.
• Feedback in words: every change that matters is also said in text (a notice on the screen and a polite live-region message), never by motion alone.
• Sound: synthesised cues (a tick on press, a rising pair to confirm, a low pulse for SOS). Off by default; a passenger turns them on from the quick bar.
• Targets: at least 44 × 44 px everywhere; 76 px on the driver's screen while moving.

Motion on this page

• The camera moves only with the visitor's scroll, slowly, along one path (exterior, round to the door, into the cabin).
• Changing seat folds the panel into its screen, flies the camera (1.1 s), then grows the next screen out (a GSAP Flip).
• Reduced motion (the system setting, or the page's own): no camera flights; the camera cuts between poses, the seat switcher cuts, and everything stays usable.

Seat-mode transitions

Switching a screen between parked and moving reshapes the driver's layout at once (no animation to watch while driving): two large tiles, the next turn and what is playing, with locked items marked and a reason given.

Safety and driver distraction

A whole-car system puts a screen in front of the driver, so distraction is the first question. AVENUE's driver mode is designed to the U.S. National Highway Traffic Safety Administration's visual-manual driver distraction guidelines. These guidelines are voluntary; they apply to light vehicles and to built-in devices the driver can easily see or reach.

What the driver's screen does while moving

• Locks video not related to driving, automatically scrolling text, text entry, long text for reading (news bodies), and camera imagery (the AR view).
• Enlarges targets to 76 px and cuts the screen to two glanceable tiles: the next turn and what is playing.
• Hands tasks to voice ("warmer", "navigate home"), to the steering-wheel and seat controls (card A), and to other seats: a film the driver picks is sent to a rear screen instead.
• Says why something is locked ("available when parked"), so it is never a dead end.

Try it in the demo: choose the driver's seat and set the car to Moving.

Status

These are design decisions, not test results. The driver mode has not been measured against the glance criteria; that test (eye-glance or occlusion, as the guidelines describe) is part of any pilot. Rear screens sit behind the front seats and are outside the guidelines' scope.

Source: Visual-Manual NHTSA Driver Distraction Guidelines for In-Vehicle Electronic Devices (78 FR 24817, 26 April 2013, docket NHTSA-2010-0053)

Accessibility

• Contrast: every colour pair meets WCAG 2.2 AA (4.5:1 for text, 3:1 for controls and edges), in both themes; a unit test checks the tokens and axe checks the page.
• Keyboard: the whole demo works from the keyboard. Seat and option groups move with the arrow keys; focus is always visible (a 2 px amber ring).
• Screen readers: every control has a name and a state; what changes is announced politely; locked items say why.
• Text size: three steps per seat (default, large, largest), and a high-contrast mode.
• Captions on by default for anything that plays.
• Motion: reduced motion removes camera flights and cuts instead; nothing is conveyed by motion alone.
• Touch: targets of at least 44 × 44 px, 76 px for the driver while moving.

Automated checks (axe) find only part of the problems; testing with people who use assistive technology is part of any pilot.

Integration notes

AVENUE is platform-agnostic. What exists today:

• a design system: tokens, components and the interaction, motion and safety rules on this page;
• a reference implementation for the web (this demo), with the shared state and the driver rules as plain code;
• this documentation.

How AVENUE runs in a particular vehicle (the operating system, the display hardware, the vehicle signals it reads, such as speed and gear, and how it is certified) is scoped with each partner. We make no claim to run on any specific automotive platform today.

What a pilot typically settles first: the vehicle signal that defines "moving", the co-pilot screen's visibility from the driver's seat, the voice stack, and the test plan for the driver mode.

Changelog

0.1, reference demo

• Whole-car seat modes: driver, co-pilot, rear (driver and co-pilot as a design extension, not yet user-tested).
• Seven modules, content sharing between seats, SOS, driver lockout.
• Design tokens, core components and these docs.

Next entries will follow the first partner engagement.