Telenav Rhine

Turning 90 wireframes into one in-dash system that held up in daylight, at night and mid-turn.

Automotive Navigation · In-Dash Software · USA

·

Telenav

Scroll to explore

var(--variable-lVkmgb23s)

Telenav Rhine

Turning 90 wireframes into one in-dash system that held up in daylight, at night and mid-turn.

Automotive Navigation · In-Dash Software · USA

·

Telenav

Scroll to explore

var(--variable-lVkmgb23s)

Scroll to explore

Telenav Rhine

Turning 90 wireframes into one in-dash system that held up in daylight, at night and mid-turn.

Automotive Navigation · In-Dash Software · USA

·

Telenav

var(--variable-lVkmgb23s)

Telenav Rhine

Turning 90 wireframes into one in-dash system that held up in daylight, at night and mid-turn.

Automotive Navigation · In-Dash Software · USA

·

Telenav

Scroll to explore

var(--variable-lVkmgb23s)

PROJECT OVERVIEW

I turned Telenav’s 90 wireframes for GM’s European brands into a complete visual design on GM’s style guide, with the spec books and assets engineers needed to build it pixel for pixel. It went on sale in Opel and Vauxhall cars in July 2017.

CLIENT

Telenav

MY ROLE

Design Lead, via Plexable

SCOPE

Visual design for 90 screens on GM’s style guide, UI state rules, four spec books, icon production in three sizes, 14 EU traffic signs, and keyboards for five European languages

VALIDATION

Reviewed across feedback rounds with Telenav; map pins, the menu icon and keyboard sizing changed as a result

TIMELINE

October 2015 - February 2016

TEAM

Delivered through Plexable with Telenav’s product team

The context

Rhine is the in-dash navigation Telenav built for GM's European brands, Opel and Vauxhall. Telenav had the wireframes and the engineering team. What the programme needed was a visual system that held together across every screen and every state.

The request was specific: visual design for 90 wireframes on GM's style guide, plus UI rules for how each screen changes state. Everything had to arrive with sizes precise enough for engineers to build from without asking twice.

My responsibility

My job was to turn a set of wireframes into something a GM programme could build: one visual system, held to GM's style guide, consistent across every screen and every state a head unit passes through.

That made the design and its documentation the same deliverable. Nothing left my hands without the sizes, states and assets an engineer needed to build it.

Ninety screens is where consistency breaks. Each one looks reasonable on its own, and together they drift: a slightly different red, a label that truncates, an icon that only exists in daylight.

I treated the set as one system from the first screen, so a decision made once held everywhere it appeared.

01

What I owned

I owned the visual design for all 90 screens and the UI state rules behind them, then the documentation and production assets that let engineering build from the design without interpreting it.

01

What I owned

I owned the visual design for all 90 screens and the UI state rules behind them, then the documentation and production assets that let engineering build from the design without interpreting it.

02

How I led

When feedback came back from Telenav I folded it into the system rather than patching single screens, so a change to pin sizing or an icon held everywhere that component appeared. Everything left my hands with sizes attached, which kept the conversation with engineering about the build instead of about interpretation.

02

How I led

When feedback came back from Telenav I folded it into the system rather than patching single screens, so a change to pin sizing or an icon held everywhere that component appeared. Everything left my hands with sizes attached, which kept the conversation with engineering about the build instead of about interpretation.

CONSTRAINTS & TRADE-OFFS

A head unit has to work in daylight and at night, mid-turn and parked, with and without GPS. GM's style guide set the typeface and the frame before I started, and turn information still had to read at a glance from the driver's seat.

01

The constraint

Every screen had to hold up in four states and inside GM's style guide at the same time. That left very little room: the typeface was given, the frame was given, and legibility at speed was not negotiable.

01

The constraint

Every screen had to hold up in four states and inside GM's style guide at the same time. That left very little room: the typeface was given, the frame was given, and legibility at speed was not negotiable.

02

The trade-off

I chose legibility over variety: big type, high contrast, short labels, and one red for every highlight and active state across the whole system. That meant accepting that 33 px type always runs to two lines and designing around it rather than shrinking the type. Night driving got its own pass rather than a filter, with separate camera, school zone, railway and lost-GPS icons.

02

The trade-off

I chose legibility over variety: big type, high contrast, short labels, and one red for every highlight and active state across the whole system. That meant accepting that 33 px type always runs to two lines and designing around it rather than shrinking the type. Night driving got its own pass rather than a filter, with separate camera, school zone, railway and lost-GPS icons.

● RESEARCH & CONTEXT

What the feedback rounds changed

Feedback rounds with Telenav changed concrete things. Numbered map pins were resized to hold two digits. The menu icon was redrawn so it would not confuse drivers. Keyboard buttons were enlarged, and icon sizes were changed so developers could align assets easily.

Each of those went back into the system rather than into a single screen, so the fix held everywhere the component appeared.

● PRODUCT DECISIONS

A visual system on GM’s style guide

01

Before navigating

Search, results, places, routes, favourites, traffic and settings.

01

Before navigating

Search, results, places, routes, favourites, traffic and settings.

02

Navigating

Turn cards, lane guidance, tight turns, junction views, multi-stop trips and arrival.

02

Navigating

Turn cards, lane guidance, tight turns, junction views, multi-stop trips and arrival.

03

Specs and assets

Four spec books plus production assets: lane-assist and turn icons in three sizes, alert icons and 14 EU traffic signs.

03

Specs and assets

Four spec books plus production assets: lane-assist and turn icons in three sizes, alert icons and 14 EU traffic signs.

● PRODUCT ARCHITECTURE

The blueprint and evolution

The system is organised around what the driver is doing: one set of screens for planning a trip, another for being on it.

Underneath both sits a single state model. Every component is specified as default, pressed, disabled and night, and every screen carries exact sizes, so the same rule produces the same result wherever it is applied.

● PROCESS & EVIDENCE

Four spec books covered every screen, from before navigating through to headers and system screens. Each page carried exact measurements: an 800 × 104 pop-up, 76 × 76 icons, and 33 px type.

Alongside them I delivered the full icon library, with lane-assist and turn icons exported in three sizes, alert icons, 14 EU traffic signs, and on-screen keyboards for five European languages.

01.

Readable in a glance

Big turn information, high contrast and short labels, so the driver reads the screen in a glance.

04.

Lane guidance and tight turns

Lane arrows and the next turn shown together when two turns come close.

02.

One red, everywhere

Type and highlights unified on a single red (#AF0D18) across every screen.

05.

Traffic along the route

Incidents listed with the delay each one adds, plus alert icons for accidents, congestion, construction and closed roads.

03.

Built for night driving

Night versions of the camera, school zone, railway and lost-GPS icons, plus disabled and highlight states.

06.

Specified in every state

Every component documented as default, pressed, disabled and night, so the build never had to guess.

01.

Readable in a glance

Big turn information, high contrast and short labels, so the driver reads the screen in a glance.

03.

Built for night driving

Night versions of the camera, school zone, railway and lost-GPS icons, plus disabled and highlight states.

05.

Traffic along the route

Incidents listed with the delay each one adds, plus alert icons for accidents, congestion, construction and closed roads.

02.

One red, everywhere

Type and highlights unified on a single red (#AF0D18) across every screen.

04.

Lane guidance and tight turns

Lane arrows and the next turn shown together when two turns come close.

06.

Specified in every state

Every component documented as default, pressed, disabled and night, so the build never had to guess.

01.

Readable in a glance

Big turn information, high contrast and short labels, so the driver reads the screen in a glance.

02.

One red, everywhere

Type and highlights unified on a single red (#AF0D18) across every screen.

03.

Built for night driving

Night versions of the camera, school zone, railway and lost-GPS icons, plus disabled and highlight states.

04.

Lane guidance and tight turns

Lane arrows and the next turn shown together when two turns come close.

05.

Traffic along the route

Incidents listed with the delay each one adds, plus alert icons for accidents, congestion, construction and closed roads.

06.

Specified in every state

Every component documented as default, pressed, disabled and night, so the build never had to guess.

01.

Readable in a glance

Big turn information, high contrast and short labels, so the driver reads the screen in a glance.

03.

Built for night driving

Night versions of the camera, school zone, railway and lost-GPS icons, plus disabled and highlight states.

05.

Traffic along the route

Incidents listed with the delay each one adds, plus alert icons for accidents, congestion, construction and closed roads.

02.

One red, everywhere

Type and highlights unified on a single red (#AF0D18) across every screen.

04.

Lane guidance and tight turns

Lane arrows and the next turn shown together when two turns come close.

06.

Specified in every state

Every component documented as default, pressed, disabled and night, so the build never had to guess.

FINAL UI

ABOUT ME

null
null
null
null
null
null
null
null
null
null
null
null

DESIGN SYSTEM

ABOUT ME

null
null

SPECS

ABOUT ME

null
null
null

FINAL UI

ABOUT ME

null
null
null
null
null
null
null
null
null

DESIGN SYSTEM

ABOUT ME

null
null

SPECS

ABOUT ME

null
null

OUTCOMES

What shipped, and where

90

Screens designed

Telenav’s wireframes turned into a full visual design on GM’s style guide.

4

Models at launch

Adam, Corsa, Karl and Zafira, sold under both the Opel and Vauxhall names.

5

Months, two extensions

From October 2015 to February 2016, with the work extended twice by Telenav.

WHAT I’D IMPROVE

What the system changed

Engineers built from exact sizes and exported assets instead of interpreting a design file.

Every component arrived with its night, pressed and disabled states, so the head unit stayed consistent at any hour.

WHAT I LEARNED

What I would carry forward

In embedded work the spec book is part of the design. Sizes, states and assets decide whether the screen survives the build.

One accent colour applied with discipline does more for legibility at speed than any amount of visual variety.

HIRING A HEAD OF PRODUCT DESIGN?