Driving towards zero road deaths through an engaging educational playbook
Challenge
The Transport Accident Commission (TAC) is a government agency with the ambitious vision of eliminating road deaths and serious injuries in Victoria, Australia by 2050.
This engagement aims to support that vision by targeting first car buyers and young people, offering non-biased advice on every step of the process with content tailored to individual needs - TAC handed us this vision to recommend and execute.
Solution
A playbook which leads young people through every step of the car buying journey, from figuring out if they need a car to using engaging interactive tools. Finding a safe car for their budget or checking out a car already in mind. To handy used car inspection checklists. All with a digital native focus on quality and interaction.
Client
Transport Accident Commission
Team
Delivery Lead
Engineering Manager
Product Design Lead
3x Developers
Impact
Web education platform
VCE curriculum resource
Highlights from my design process
Jump to a section!
Moderated user testing
Building confidence in the solution.
Planning and recruitment
Within budget and time constraints I interviewed 2 key audience groups over 3 days, conducting 8 x 90 minute moderated tests.
Recruitment specification:
18 - 25 and 40 - 60 years old
Mix of metropolitan, sub-urban and rural participants
5 young adults searching for their own car
3 parents helping their children to find their first car
Each moderated test followed a bespoke script that pressure tested my assumptions through an interactive prototype.
Principal insights
I found that our users shared the following overarching sentiment, which formed a set of principals to apply across the experience;
Language significantly influences how receptive our users are to recommendations
Use cost as a key driver to make suggestions more compelling
Facilitating comparison throughout the website is important when offering multiple options
Use TACs credibility to build confidence through a process that can cause anxiety
Design recommendations
Based on insights I formed 56 recommendations across the experience. These were grouped into 6 themes — language, features, layout, credibility, component and SEO.
All recommendations were documented in our ClickUp product definition alongside in-situ annotations across the wireframes. This made it easier to implement the changes during the final design phase (which happened later in the year), ensuring all learnings made their way to the product!
Minimum loveable product
Prioritising quality for a digital native audience.
Designing for digital natives
With a strong understanding of our primary audience of young people, I felt confident to push an experience that speaks directly to them.
Combining this instinct with TAC prioritising design and interactions in a non-function workshop, the keys were in our hands to drive the project forward.
I built out a series of interactive components to drive engagement while simplifying jargon heavy car content and tailoring it to the user based on their needs — three examples below:
Car search tool
Swipe through a deck of cards and compare vehicles using a simplified rating system, prioritising features that are important to young people.
Quick quiz
In page, low effort quizzes to help understand your options and what kind of cars are right for you — all controlled from the CMS.
Infographics
Breaking down costs and facilitating comparison across different methods of transport — data point and categories fully CMS controlled.
Introducing atomic motion
Our focus on delivering a polished, engaging product at launch quickly lead me to design a motion framework for our team to ensure we meet our vision.
The use of motion was in it's infancy at my agency and needed structure to ensure we built a beautifully interactive experience at pace, with consistency and within budget.
I designed an 'Atomic Motion Framework' learning from more mature, public facing design systems such as Material UI, ebay's Evo and brand.dropbox. Their methodology was largely the same, but didn't directly suit the agency process — often being too rigorous and inflexible to apply to different tech stacks and teams.
I designed it to be broad enough to support any designer and brand, but specific enough to offer consistency and reusability.
Through My First Car we paved the way for this process and found huge success in it!
Form concepts
Why motion is being applied
Define feelings
What the motion behaves like
Design specification
How to visualise motion
Dev implementation
Working motion in code
Design/Dev collaboration
Setting a foundation for success.
Cultivating behaviours
I'm so proud of the behaviours and practices our team adopted through this project, and it shows in the outcome.
The Engineering Manager and I pushed to embed behaviours and processes to help us work efficiently and happily, leaning on the team to help form these design/developer initiatives:
Pairing early and often
Ensuring design isn't over promising early in the exploration phase and keeping developers in context before the build phase.
Comprehensive kickoffs
Walking developers through each feature's design spec, sharing rational and interrogating the design for any unaccounted for states/functionality.
In-code problem solving
Where design tools weren't as effective to problem solve, we made space to play in code and uncover solutions through in person design/dev pairings.
In-progress design reviews
To keep front-end polish and quality up, I moved the design review process earlier in the development framework — putting it before a handover to code review and merge to main codebase.
This helped me catch mistakes before they moved into a long cycle to land at the bottom of a backlog and be de-prioritised.
Design system to code parity
Translating designs to code is difficult at the best of times, and in past projects I struggled to understand why our design systems created arbitrary values — then needed defining in whatever codebase/framework was being used.
These systems have been re-invented over and over again, so we decided to use Tailwind CSS v4.1 as our front-end framework.
The My First Car design system was built around Tailwind and shares identical naming conventions which means designers and developers are speaking the same language. This helped us immensely from early context pairings to me design reviewing in inspect windows — all working towards doing things right the first time and driving the final fit and finish.
What I'd do differently next time.
Sharing my thought process
With our team having ownership and autonomy, we made a lot of exciting progress with deep context of decisions made — but we still needed sign off from our client and their stakeholders at major milestones.
I found we had so many ideas and decisions to share either async, or in short remote meetings — getting our deep thought process across was really difficult.
Ultimately I think this meant when their PM was sharing my work internally (sometimes for final sign off), my rational wasn't translated across well enough to get buy in.
Break down key features and milestones into smaller, more manageable parts to help comprehension and bring stakeholders along on the journey.
Empowering developers to own front-end decisions
Mid way through development of My First Car, I noticed a recurring problem with how components were structured in the front end differently to the design spec.
Through design reviews and debates, we realised I designed in a certain way through Figma which didn't translate directly to divs and front end practices — developers were trying to stay too close to the Figma spec and not respecting their own expertise and opinions.
Lean into and empower developers to interpret, change and own the front end as experts in their field.
Communicate my design intentions without prescribing implementation.
Knowing when done is better than perfect
Pushing towards our 'most loveable product' with a strong focus on front-end polish, it was easy to spend time on a pixel perfect production site. With time and budget running out, it's easy to get distracted and prioritise the wrong things.
On the final push of building a product, it's easy to focus on micro details when you should be thinking about the macro — always prioritise around the big picture, not just what you're looking at.