Toyota One app

A sprint of optimisation

Topline

How I ran a design sprint to deliver what we could within tight constraints and ship and learn from the output.

About

This project isn’t going to change the world.

This project is a reply to a concern I had from an job interview which was, due to the larger more strategic projects that I had been working on (Tu Help Experience), I may not be able to still deliver quickly and succinctly (a fair concern).

Hopefully this demonstrates a typical sprints output and how I tackle small scale problems within limited timeframes, I hope it serves that purpose.

Problem

Previous research (User interviews, App store reviews) showed users did not expect to find a way to sell their car within the “shop” tab, it had been suggested by members of the design team that changing the copy on the global navigation may help solve this issue.

Brand loyalty is high with Toyota owners in NA, many owners have more than one car and keep returning to Toyota to buy their next so ways to enable and build this loop are a key focus for the business.

My Aproach

With little appetite from stake holders to kick off a big discovery piece and with changing the global navigation out of scope for this work “learn fast and light touch” were very much the order of the day.
We didn't have access to US based App customers directly but through Userzoom we were able to test prototypes and create questionnaires.

Kick off workshop

Workshop

First up, a kick off workshop to list what we need ot learn, what we know, and what's in scope.
How we communicate the feature and where it sits within the experience were deemed in scope, and changing the gnav was seen as something much bigger than this work.

Userzoom testing

Current

Updated Gnav copy

Discovery Testing

Testing the current experience to learn where people expect to find the feature as well as testing the proposed copy update (from the existing team) to see if that results in a change of expectations

Neither performed wildly different, in fact taking margin of error into account I'd call this a draw.

However, what it does give us is 3 entry point possibilities (discounting the high score for "start" as error):
Finance
Shop
Account

So what do we know now? Not a whole lot more than when we began, but at least we know we don't know, and we have some direction…

Component design

Designing a reusable component

The current entry point was an odd layered custom design, while it did look nice it failed to communicate the benefit of selling within the app as well as failing colour contrast checks, two things I felt strongly about changing.

I picked a couple of card like components from within the app to use for the entry points and came up with a few copy options explaining the benefits to hopefully A/B/C test.

Flows

Inserting into flows

The Min and Max versions of the entry point were put into the "most logical" flows suggested by the testing.
Finance and Shop are more propositional and browse experiences so the Max version was used for them while the Min version was used in the utilitarian Account section.

Next steps

With a sprint being the amount of time this ambigious project deserved we are done for now, designs handed over to engineering (Toyota had a very "hand over" culture sadly).

In a company with a higher level of UX/Product maturity I'd expect the new elements to be tagged up for tracking and depending on how much risk/value involved in this feature we could do multivariant testing on the copy to measure any increase in interaction while the future vision team (which I was also a part of) plan out what the next gen experience will be (with more research and less limitations).

How we could measure success

Interaction rate / Leads generated

Cars sold through Leads generated

All content © 2024 | It’s been wonderful

All content © 2024 | It’s been wonderful