Designing a client’s mobile app for drivers of their vehicles
My role
Visual / UX Designer
Year
2019
Introduction
I led UX and visual design for Scania’s Driver’s Guide. Delivering Android 2.0 and the first iOS release. After facilitating a three-day ideation workshop, I reframed the app from a document-first manual to a task-first tool, redesigned the information architecture, and created high-fidelity prototypes and a clear visual system shared across platforms. The work shipped with production-ready specifications that reduced ambiguity for engineering and positioned the app to deliver faster answers to common driver scenarios.
Client
Scania
Sector
Automotive
Project team
Project Manager
Creative Director
Visual / UX Designer
Experience Strategist
Solution Architect
iOS Developer
Android Developer
QA Tester
Timeline
12 weeks
Constraints
Parity across iOS and Android while respecting native conventions. Reuse where possible. Keep content structure compatible with existing data sources.
Overview
Problem
The existing app was essentially a portable manual. Drivers needed something more useful during day-to-day tasks. Quick answers, clearer wayfinding, and a structure that reduced hunt time and cognitive load. The business goal was to increase adoption and perceived value by making the app genuinely helpful in the flow of work.
Challenge
Shorten the path from question to answer for common driver scenarios. Replace document-first navigation with task-first entry points and clearer IA. Establish a visual system and component library that works across iOS and Android. Provide production-ready specs to reduce implementation ambiguity.
Solution
A restructured IA that starts with driver tasks and quick entry to common scenarios. High-fidelity prototypes demonstrating core flows for Android 2.0 and iOS 1.0. A visual direction with component patterns and shared tokens applied across platforms. Specifications covering behaviours, states, and content structure to guide engineering.
Results
Android 2.0 shipped with a clearer, task-oriented experience. iOS launched with a first-class, platform-native release aligned to the same logic. A shared design language reduced ambiguity and supported more predictable development.
My process
Research activities
Three-day client ideation workshop to surface tasks, contexts, and pain points. Audit of the current app’s information architecture and content patterns. Task inventory. Competitive pattern scan (task-oriented help, on-device guides).
Definition activities
Information architecture and task models. Shared design tokens and components.
Design activities
High-fidelity prototypes for Android v2.0 and iOS v1.0 with states and edge cases.
Testing activities
Rapid concept testing through interactive prototypes and stakeholder walkthroughs.
Iteration activities
Quick iterations to de-risk build.
Handoff activities
Developer-ready specifications. Behaviours, and content guidelines.
Research
Insights in the beginning
Drivers think in tasks (“what I’m doing now”), not chapters. Search and navigation needed to prioritise common scenarios over document hierarchy. Visual hierarchy and language should enable “at-a-glance” comprehension.
What we would track post-launch
Search success and no-result rates. Time-to-answer for top tasks. Repeat use and feature adoption across the two platforms.
Key decisions
Task-first information architecture
Reorganise navigation around driver tasks and common scenarios, with search and recent items elevated — this was to reduce hunting through document trees and align the app with how drivers think and work.
Progressive disclosure of detail
Lead with concise guidance and key steps; provide deeper reference only when requested — this was to support rapid decision-making without overwhelming the user.
Define cross-platform components and tokens; implement with native patterns (navigation, gestures, controls) — this was to maintain consistency and speed up delivery while keeping the app “at home” on each platform.
Clear visual hierarchy
Typography and spacing rules that make headings, steps, warnings, and tips instantly scannable — this was to improve at-a-glance comprehension in time-pressured contexts.
Specification depth
Document states, empty/loading/error cases, and behavioural rules for search and navigation — this was to reduce rework and ensure parity between Android and iOS implementations.
Risks and how they were managed
Scope creep
Prioritised critical tasks for v2.0/v1.0. Staged lower-value features behind release gates.
Cross-platform divergence
Governed with shared tokens/components and platform-specific guidelines.
Content complexity
Introduced content structure and examples to keep guidance concise and consistent.
