Case study · Bachelor thesis · 2021

Swift

An adaptive dashboard for semi-autonomous cars

Driver assistance acts — or gives up — without ever saying why, and leaves you no way to intervene short of grabbing the wheel. Swift gives the car a voice for what it intends to do next, and the driver a way to overrule it without taking over.

The Swift dashboard: speed at top left, the Autopilot Feed listing upcoming manoeuvres down the left side, and the car rendered on the road ahead
Role
Research, UI, interaction design
Team
Fabian Schadt & Joshua Dessol
Type
Bachelor thesis, Interaction Design
School
HfG Schwäbisch Gmünd
Supervisors
Prof. Dr. Eileen Mandir, Prof. Michael Schuster
Year
Summer semester 2021

The brief

Design a user interface for a partially automated vehicle that makes the driver trust it.

Not a level-5 robotaxi. We parked ourselves in the awkward stage the industry is actually in — the handover zone where the car does most of the driving and the human is still responsible for all of it. The study we opened with put mass-market autonomy at 2040. The interesting design problem is the twenty years in between.

The problem

The car sees more than it says

Every research strand landed on the same complaint, and drivers put it better than we could.

When the system emergency brakes it doesn't show on the display what it thought the threat was.
In the current state you have to understand how the system currently works and be able to anticipate its reaction.
There is no warning ahead of sections of the road where the car is unable to perform on its own.

Tesla owners, from our survey of 46 free-text responses

No explanation

The car brakes. Nothing on screen accounts for it — 80% of the owners we surveyed had experienced phantom braking.

No forecast

Nothing tells you which parts of the route it can handle until you're already in them.

No say

The only intervention available is total takeover. An all-or-nothing switch, in a situation that is rarely all or nothing.

The result is lopsided: the car perceives far more than it shows, so the driver ends up trusting it less than the hardware deserves.

How we got there

Research

Six months, starting wide and narrowing to a single question: what does the car know that the driver doesn't?

Be your own customer

Neither of us had lived with an assistance system, so we rented a Tesla Model 3 Performance for a day. We enjoyed it and felt safe — right up until the first phantom brake.

Interaction journey map

The same drive, structured. Fabian drove, Joshua observed and filmed. Thoughts, actions and emotion plotted against time, every touchpoint marked positive or negative.

Owner survey

20 open questions posted to r/teslamotors — free text, no multiple choice, so nobody could pick our answer for us. 46 responses.

Object detection

A GoPro on the car, every frame run through ImageAI. Then a second GoPro on the driver's head, to compare the two viewpoints directly.

Design sprint

A full sprint to open the solution space, defined around trust, control and representation — and to decide what we were not going to build.

Competitive SWOT

Consumer Reports' 2020 ranking of 17 assistance systems, read for the gap between how well a system drives and how well it explains itself.

Hands resting on the steering wheel of a Tesla Model 3 on a country road, the centre screen showing the navigation map
A day with a Model 3 near Stuttgart. Fabian had years of driving behind him and had never used a modern assistance system — the closest thing to a first-time user we could get.
The interaction journey map: a timeline of screenshots and stills above an emotion curve that dips sharply in the middle
The journey map from that drive. The dip is the moment the car braked for nothing and never said why.
The sensor coverage around a Tesla, drawn as eight translucent blue fields overlapping around a car seen from above: a short ultrasonic ring, wide camera wedges to the sides and rear, and three forward wedges that narrow as they reach further ahead. Each field is labelled with its sensor and its maximum range.
Eight cameras to 250 m, twelve ultrasonic sensors to 8 m, and a forward radar that sees through rain and fog. The point isn't the spec sheet — it's the fraction of it the driver is shown.

What we learned

The design sprint turned a lot of research into a short list. Everything Swift does traces back to one of these.

  • The driver has to be able to trust the system.
  • Complex information has to be made legible, not just displayed.
  • The driver needs a way to decide when the system is unsure.
  • Eyes stay on the road.
  • A handover is announced early, never acted out abruptly.
  • Every action the car takes must be traceable afterwards.

Ideation

Getting it wrong first

Four MVPs, tested with three fellow students. What failed shaped the final system more than what worked.

The dock in the bottom-left corner

Unreachable while driving. Obvious in hindsight, invisible on a desk.

A live camera feed of the road

Too detailed, and rendered from an angle you'd never see your own car from. Worse, it showed the driver what was already out of the windscreen — a redundant double coding. This killed the raw-camera direction for good.

A confidence percentage

Nobody understood what the number measured, or the icon next to it. It survived as colour instead.

The log book

Nobody realised it existed or how to open it. It got a permanent home in the dock.

Where to put the camera

Bird's-eye visualises a route well. Top-down shrinks buildings and distorts distance, so we dropped it. Third person — fixed, behind and slightly above — won: the driver reads it as their car, and it matches a pattern people already know from games.

Bird's-eye view of the car with its blue autopilot path curving ahead
High top-down view of the car approaching a pedestrian on a residential street
Third-person view from behind and above the car, the blue path leading around a corner

The turning point was translucency

Early layouts used a solid white dock and a solid menu bar, and every screen felt boxed in. Making the panels frosted let objects and movement stay visible behind the controls. In a context this dynamic, showing everything is itself a trust device — and it moved the whole system from framed to open.

An early layout iteration with a solid, fully opaque panel over the scene
The same scene with frosted, translucent panels, the street still visible behind them
Two hands on a steering wheel in a real car, the Swift interface running on the centre screen with its blue autopilot path
Testing in a real cabin. Selection and confirmation were wired to the steering-wheel hard keys too, so the interaction can be done blind, from muscle memory.

The greeting, the tiles and the detail views tested well. Sizes and proportions tested well. The icons did not — which is exactly why they ended up with their own plate in the styleguide.

The outcome

The system

The driver should be able to do the thing they came to do with as little effort and distraction as possible. In a car, that sentence is a safety requirement.

Getting in

The car already knows where you're going.

A welcome screen greets you by name and hands over after a few seconds. It exists because its absence was conspicuous during our own test drive — nothing about getting into the car acknowledged that a person had arrived.

Then suggestions, built from past behaviour: the commute it knows you take at this hour, the temperature at your destination on arrival, charge before and after, and a forecast of how the autopilot expects to behave along the way. Accept it, adjust it, or throw it away.

One drive from the door to the road — pick a moment to jump to it.

Availability

Where it can drive itself — and why it can't elsewhere.

This is the most direct answer to the research. The route is broken into stretches, each marked with whether the system can handle it. Roadworks get a roadworks symbol. City streets get a city-streets note.

Cruise-control speed, the observation setting and the autopilot switch all live in the same view, so the decision and the controls are never more than a glance apart.

The availability card showing which stretches of the route the autopilot can drive and why it can't drive the others

The Autopilot Feed

A queue of what the car intends to do next.

The most-requested feature in every interview and the survey was some form of predictability. The feed is that: the upcoming manoeuvres, in order, each coloured by how confident the car is that it can manage it alone.

Confidence is derived from map data and other drivers' cloud data, so you see how closely you need to watch the road before the situation arrives rather than during it. The percentage we first tried didn't read at a glance — colour does.

Four stacked tiles: grey — you're driving; red — the system can't do this stretch; orange — unsure but attempting; blue — handled
Grey
You're driving.
Red
It can't do this stretch — but you can teach it.
Orange
Unsure. It will attempt it, and warn you in time.
Blue
It has this.

Object detection

It acts first, then explains itself — while it's still acting.

At speed on a dual carriageway, the car detects an unknown object ahead. Without any input it checks whether the adjacent lane is clear, finds that it is, and changes lane. An emergency stop at speed avoided.

The part that matters for trust is what happens in the cabin at the same moment: the cockpit is told what the object was and why the car moved, as it moves.

Teaching

For the stretches marked red.

The feed warns that a section is coming up the autopilot can't manage. Instead of only handing control back, the driver can offer to teach it: recording starts, they drive the section themselves, and the route data goes back into the fleet.

Driving it yourself stays available at any point. Finishing a teaching run earns reward points — the thesis suggests charging credit.

Intervention

Influence the situation without taking over.

A cyclist is registered in the car's lane. The system checks that both options are genuinely possible, then offers them: follow at an adjusted speed, or overtake. Whichever you pick, the autopilot keeps driving.

A second case — a pedestrian crossing the autopilot is unsure about — works the same way. The design goal was explicit: never let the car sit in a decision loop that a human can resolve in one tap.

The screen reads Bicycle detected — What would you like to do? with two buttons, Overtake and Follow

Notifications & the log book

The loop closes after you've parked.

Our survey asked for this one almost verbatim: a written or video log, because reading things in real time means staring at the screen instead of the road. Notifications hold the history; tapping one jumps to the event.

In the Journal you get the incident in full — how many happened on the trip, how long it took, how far it went, and a replay of the footage. Then you answer: acted correctly, report a problem, or unsure.

That answer improves the system, is shared anonymously with the manufacturer and other drivers, and earns a reward. The car explains itself, the driver judges it, and both get better.

During the drive — the event announces itself and offers a way back to it.
After it — the journal, the replay, and the verdict.
The Journal: current trip stats, a replay scrubber, and three buttons — Acted correctly, Report a problem, Unsure

What we cut

Observation Mode

A control for how much of the surroundings the car draws. Off. Normal — a realistic reading of live and cloud data, with the driver holding responsibility because calculated accuracy sits under 50%. High — everything it collects, drawn at all times. Auto — it hides the lot once other drivers' data shows the section is trouble-free.

It tested well and testers liked it. We cut it anyway: the idea leaned too far into speculative design, and the technical basis for it doesn't exist yet. It's here because a case study that only shows the parts that worked isn't a case study.

Four variants of the same road scene at increasing levels of detail, in daylight, rain and at night

Design language

Near-black ground, one confident blue, and frosted panels so movement is never fully hidden behind a control.

Eerie Black

Ground

#191919

Eerie Black

Surface

#1D1D1D

Azure

Primary

#007BE4

Orange Peel

Caution

#FF9E0B

Tart Orange

Alert

#FF3B30

White

Text, at 100 / 50 / 20 / 5%

#FFFFFF

SF Pro TextBold · Semibold · Medium8px radii on cards, full-round on pills.

The testing round flagged icons as the weakest link in the interface, so they got their own pass and their own plate in the styleguide.

The Swift icon set: forty small glyphs for climate, lights, speed limits, autopilot, media and vehicle states

Outcome

A complete UI system for a partially automated car, plus rendered use-case films — the interface composited into 3D scenes so each scenario could be judged in motion and in context rather than as a still.

Submitted in July 2021 and shown in HfG Schwäbisch Gmünd's digital exhibition.

Design & research
Fabian Schadt, Joshua Dessol
Supervisors
Prof. Dr. Eileen Mandir, Prof. Michael Schuster
Vehicle access
Itana GmbH, Stuttgart
Industry interview
amplify design GmbH

Images and films are from the original thesis documentation. Some diagrams are still captioned in German — it was written and submitted in German.