A meeting ahead.
Tuesday, 08:12. The commute connects an ETA with the calendar and a familiar coffee stop.
01 / Starting point
The route is known.
The situation is changing.
A useful answer can sit across several apps. The interface has to bring those pieces together.
In Tom’s simulated morning commute, navigation knows the arrival time, his calendar holds the design review and his phone remembers the podcast. I used that moment to explore a cockpit that brings the relationship forward: the margin before the meeting, a coffee stop that still fits and something to listen to on the way.
The question became larger than choosing which tile to show. How much can the screen adapt before it becomes hard to recognise? I developed the concept, designed the interface system and built the working prototype through AI-assisted coding to make those decisions tangible.
Navigation08:41Arrival at the office
Calendar08:45The next design review
PhoneHard ForkResume at 23:10
4 minbetween arrival and the review.
A coffee stop adds 2 min.
A familiar thread.
Along the route.
08:12, on the way to a review at 08:45. Navigation, the appointment and the podcast share one surface; the assistant makes the timing relationship visible. · Actual interface
A calmer school run.
Thursday, 15:32. Tom is driving Mia to her piano lesson. Building traffic and his stress reading call for different priorities.
A different driver.
Sunday, 15:32. Jonas borrows Tom’s car. Which parts of the owner’s context should stay private?
I separated the exploration into three decisions: how to compose the interface, where visual freedom belongs, and how relevant context could be found.
02 / Interface system
A familiar cockpit.
With room to adapt.
I started with the things people expect to find: a route, music, range and climate. Adaptation should build on that familiarity.
Navigation leads, everyday controls stay close. The route takes the main area, music and range sit beside it, and climate controls have their own strip. A reference layout from the prototype’s working components and simulated data. · Actual interface
A2UI connects the proposal to the screen.
A2UI means Agent to UI. It lets an agent describe an interface using a shared vocabulary of components. That gave me a way to explore different compositions while retaining recognisable controls.
About A2UI ↗Give adaptation a vocabulary and limits.
I designed the automotive components and the rules around them. The system can bring information forward and change its visual expression. Checks address density, night conditions, accessibility and content restrictions.
The question became: what should change for this moment, and what should remain familiar?
Context
Navigation, appointments, vehicle conditions and driver needs describe the situation. A simple city drive starts with different priorities from a school run or an upcoming meeting.
Compose
The system proposes an arrangement from familiar cockpit elements. A request can change the information that leads or describe a different visual character.
Check
The proposal is checked for density, readability and content restrictions. A moving car, night conditions or a need for larger text can change what appears.
Display
The checked composition appears through the same cockpit components. Their typography, colour and surfaces can change while their purpose stays recognisable.
Navigation
Assistant
Media
Appointments
Charging
Warnings
The vocabulary I designed: familiar automotive elements become the building blocks for an interface that responds to the situation.
03 / Prototype
Try a request.
See what changes.
Type your own request or start with an example. The prototype’s planner and guard answer in your browser; Before and After compare the complete screens. The search explorer below shows how different people’s data enters a moment.
Starting point
Starting point · Everyday drive
Navigation, music, range and climate. What would you change?
Editorial
Cream surfaces, serif typography and crisp contours.
Go beyond this demo.
Want to explore your own contexts and requests in the full Cockpit Composer? Get in touch to try the interactive prototype.
04 / Context explorer
Which context belongs
to this moment?
The commute started with a route and an appointment. What if the relevant pieces live across hundreds of entries? I built a companion vector search explorer to make that mechanism visible.
Four fictional people make the question concrete. Tom owns the car; Lena, Jonas and Mia each have their own entries from calendars, routes, messages and media. The situation decides whose entries may be searched, before the search asks what is relevant.
When Jonas borrows the car, Tom’s private entries stay out, however useful they look. This companion explorer shows how relevant context could be found; the cockpit demo above uses prepared scenario data.
Full simulated situation
Drag or use arrow keys to rotate · Shift-drag to move · + / − to zoom · 0 to reset. On touch: drag to rotate, pinch to zoom.
Each dot is a fictional entry; the picture projects 384 dimensions into three. Rings mark results, outlines the groups searched, ◆ this moment. · Actual interface
Matches for this moment
How to read this search
The dataset contains 415 fictional entries. Each is stored as an embedding: numbers that represent its meaning. The moment is searched against those entries, but only within the permitted personal spaces. An IVF index groups the entries into cells. The slider controls how many of those groups are checked per eligible person; more groups can reveal matches an earlier search missed. These controls select prepared runs locally.
The 3D picture uses three principal components of the embeddings, with each axis normalised for display. It is a projection, not the full space: similarity is computed in all 384 dimensions. Closeness in the picture and the cell outlines are illustrative; cosine similarity is not a probability.
The guest-driver example searches only eligible entries in Jonas’s space. The owner’s entries are excluded from both the search and that scenario’s plot.
05 / What remains
The boundaries are
part of the design.
A working prototype with simulated data. Live style generation, usability and driving outcomes are not yet evaluated.
Reflection
The prototype makes adaptation visible, but every context in it is simulated. What I would do differently: test the guarded composition with drivers in a simulator early, because whether a changing screen feels helpful or restless only shows while driving.
Concept to prototype
Concept · UX and interface design · System architecture · Prototype development through AI-assisted coding
Framework and references