Toyota Digital Redefined

Building a Lasting Relationship

Project Overview

Toyota’s digital platforms are currently divided into disparate platforms:

Toyota.com - the primary marketing platform for searching existing vehicle inventory and custom building vehicles through dealerships
ToyotaOwners.com - the resources platform for customers who own a Toyota and need to access documents like including manuals or maintenance plan information
SmartPath - a digital tool adopted by a growing number of dealerships to connect buyers with VIN-level inventory and complete the purchase

Our agency was tasked with leading an initiative, known as Toyota Digital Redefined (TDR), to combine these three platforms into one unified ecosystem.

Role

My role as Experience Designer (XD) includes creating annotated medium-fidelity wireframes that consider all the functionality and strategy of the components, balancing business and with user needs and planning the holistic layout of the page and all navigation points to, from, and within the page. Also on my team:

A Business Analyst, who writes the business requirements
A Visual Designer, who updates my medium-fidelity wireframes into high-fidelity comps that are consistent with the style guide
A Client Partner, the liaison between our team and the Product Owner
A Producer, who manages the schedule and assigns the Jira tickets

Vision and Scope

The customer will benefit by managing all phases of their journey, from potential consumers to brand loyalists, within one environment.
The business will benefit by consolidating three platforms into one single code-base which can be built and maintained by one group while updating the look and feel of the site to a best-in-class web experience.

Tools

Design Software: Figma (after transferring mid-project over from Sketch / InVision / Zeplin)
Project Management Software: Jira / Confluence, MS Office 365

goal

The intent is that customers will extend their relationship with the brand beyond the purchase of just one vehicle. The initiative includes redesigns of all pages, new global navigation, and migration of the codebase to a single environment. My team was tasked with the design and launch of a new Owner’s Vehicle Dashboard (“Dashboard”, for short) while considering its place and function within the unified ecosystem, along with the marketing and purchasing platforms.

Project Scope

The scale of this project is huge - eventually, it encompasses every page within all three platforms, and may ultimately inform how the mobile app is designed. As such, it is broken down into various phases, each of which was only loosely defined at kick-off.

My involvement with the project began during the initial exploratory phase and has extended into the launch of the initial MVP by end of the fiscal year. For the purpose of this case study, I will focus on the MVP element, which includes a total re-design of the Logged In Owner’s My Vehicle Dashboard. At the time of kick-off, the logged-in state was the only one considered, as the logged-out state and site navigation was not considered in scope, although this was later changed by the client at our team’s suggestion.

The Current experience

I identified a number of elements to be addressed on the current Logged In Dashboard. I focused on retaining the components that have a high engagement while consolidating or removing components that are less utilized by customers. This includes:

Vehicle Selector - this enables the user to find the vehicle model and year; it historically has a very low rate of user engagement.
Dashboard Marquee - top-level information about the vehicle, and changes dynamically depending upon whether or not the VIN has been entered.
Resources - a menu of links and tools that help the user navigate the site to find the information about the vehicle that they need.
Service History - a record of all services provided to the vehicle, which depends upon the VIN being entered.
Servicing Dealer - a quick link to the dealer associated with the vehicle, or selected by the user.

A screen capture of the current Logged In My Vehicle Page (with a VIN entered), at both desktop and mobile breakpoints

The intended direction

After exploratory work on intended directions had been done prior to kickoff, which set a stylistic framework for the dashboard page, I made a component ID diagram to understand which components will be MVP, post-MVP or removed. I was involved in the stylistic explorations that yielded this design, although it represents a combination of components from other creative directions.

The Global Navigation is to be handled by a different team, but I will ultimately have input into how the dashboard will be implemented within it.
This updated Vehicle Marquee will include many of the same elements as the current one, but with an updated look and feel.
This Sub-Marquee includes vehicle telematics that is not available on all vehicles. It also did not include other elements that need to be accounted for, so this component was ultimately reimagined.
The Search Bar is not included in the MVP, as it will ultimately appear in the global nav, and there are no requirements for an in-page search.
The Quick Tools Menu is something that I suggested during the exploratory phase. Knowing how little traffic in-page resources have and wanting to use page real estate for more valuable components, I consolidated the links to a menu, which also helps reduce the number of links in the navigation.
The Recall Banner is a legal requirement, as well as important information for customers, although the information displayed here does not accurately reflect the actual data feed behavior.
Toyota Financial Services, which includes such functions as Pay My Bill, is a branch of the experience that had yet to be integrated into the current Owner’s site and is too complex from a dev perspective to be MVP.
Service History is one of the more highly utilized tools on the current site, so is a must-have component for MVP.
As with item 7, this Financial Service is backlogged for future release.
This is an example of content considered during the exploratory phase. Ultimately, the Owner’s experience could help extend owner loyalty over time, so Conditional Marketing Components such as this one which might display toward the end-of-lease, personalize the content of the page.
As with item 10, this Marketing content is backlogged for future releases.
This Marketing content is not actionable, and as I had included links to pages in the quick tools menu (item 5) that direct the user to content specific to the Model / Year, I suggested that it be reconsidered and made more useful for customers in future versions.

Focusing the Direction

Understanding the use cases

As the scope of the page became clearer, I planned how to design and build the page in time for launch. The scope of the Logged-In Dashboard has a number of states that display as a result of several factors:

VIN-entered versus no-VIN-entered: If a user enters a VIN, they will have vehicle-specific data feeds that display on the page, in addition to generic Model / Year content. As the number of users who input a VIN is relatively low, I identified VIN-entry as a KPI to target and track.
Connected Services capable and/or enrolled: Some vehicles offer connected services, and others do not. Those Connected Services will only display in a VIN-entered state and can be managed via the mobile app.
Model / Year: As Toyota offers a wide range of vehicles models, trims, and years, I have to create a page experience that will be flexible enough to account for every possible Model / Year combination, in both VIN-entered and non-VIN-entered states.

To understand the context in which a user would engage in each state of the page, and track the dependencies, questions, and assumptions along the way, I created a flow chart to map out what would have to happen in order for each use case to be met, and what would display on the page in each case.

Toyota.com > Owner’s Dashboard User Flow, Part 1

Toyota.com > Owner’s Dashboard User Flow, Part 2

Shifting Scope

Timeline: 6 weeks (3 Sprints) of design in order to hand off in time for development and QA

4 weeks (2 Sprints) for XD to leave enough time for VD to finish and revisions prior to hand-off

Proposal: I proposed that we design each component independently and build the pages like Lego blocks.

Each component will account for variations and enable me to think in more detail about functionality and make improvements along the way.

Building the Page

Component highlights

I designed each component separately at five breakpoints, ranging from Mobile to Desktop XL, and annotated each for functionality and technical requirements before handing it off to the visual designer to make stylistic revisions. Subsequently, we collaborated to iterate and make updates according to stakeholder feedback and additional scope. Some components were not drastically altered from current production, while other examples were more involved.

sub-marquee

One complex component is the Sub-Marquee, as there are dependencies on a number of variables with regards to what will actually display per instance. Some key efforts include:

The data-feed cards each function independently, so that if one updates, it will not impact the others. This modular approach enables us to consider more specific and useful information for the customer, such as subscription expiration warnings, which are not currently in production.
I suggested that in future testing, users give feedback on the prioritization of these cards and express what else would be helpful. The modular approach makes the component flexible to iterate in future versions with additional data feeds and re-prioritization without breaking the component, in contrast to the fixed and static approach currently in production.

An example of the QR code generator that would appear on larger breakpoints to faciliate downloading the mobile app.

quick tools menu

The Resources section of the current site is utilized by relatively few users. Rather than display this content on the page and have it clog up the site architecture, I designed this Quick Tools Menu so the links can be contained in one spot contextually within the page. I proposed seeking user feedback about the effectiveness of this idea and tracking the analytics to see if there is an increase in usage. Highlights include:

As users can only manage subscriptions via the app, including AppStore and GooglePlay links on desktop breakpoints is not particularly useful. I designed a QR Code generator that a user could scan to their mobile device to open and access the appropriate page to rectify this potential pain point.
If a user clicks Vehicle Specs in a non-VIN-entered state, it will open a VIN-Entry Modal without making the user leave the on-page experience.

A look at the current VHR: on the left is the default Chart View, and on the right is the List View

Vehicle Health Report

The Vehicle Health Report (VHR), available via a connected service feed on select vehicles, is another component I applied the same modular card approach to, as over time more telematic services are introduced to the ecosystem, the card design will be scalable. Revisions include:

The updated VHR comps for desktop and mobile breakpoints.

Removing the Graph, which our strategic advisor agreed with me to be ambiguous and a potential ADA violation (especially at mobile breakpoints), and defaulted the tool to a collapsed chart view
emphasizing Dashboard Alerts as cards that identify the specific alert type and direct customers to the appropriate page to learn about addressing the problem, as opposed to a generic message
including a Schedule Maintenance Service card and CTA, which has been identified by both users as a primary reason for visiting the site, as well as dealerships as a primary source of revenue
implementing the Horizontal Scroll so the component occupies less vertical space while offering potentially more services

A view of the Logged In My Vehicle’s Dashboard > VIN entered > enrolled in Connected Services

Full Page Layout

This is an example of the full page layout exemplifying how the Dashboard appears for a VIN-entered > enrolled in Connected Services use case. All other use cases are variations of this, with each component molding itself to the designated need. By approaching the page in this fashion I met the deadline established by our dev partners with time to spare and could make revisions to components prior to dev hand-off while better capturing post-MVP goals and user research opportunities for upcoming sprints.

A: Marquee and Sub-Marquee. I worked closely with the VD to ensure that both 3-up and 4-up variations function properly at all breakpoints, including:
- the amount of text and space required for the vehicle name and trim
- the number of cards that would display in each use case
- the vehicle image, as some Model / Year vehicles, will show trim-level data while others will use generic images
- recall status, per alignment with strategy, remains in the marquee to reassure customers or inform them they need to take action
B: Quick Tools Menu. By creating a single source for all Model / Year contextual links, I could explore removing links from the crowded navigation and consider how the owner’s environment fits into the new global nav.
C: Vehicle Health Report. The modular approach makes the VHR flexible for future releases and more relevant for current users.
D: Service History. This component is re-designed to make it easier for users to manually add a service instance if they visited a non-Toyota dealer.
E: Contextual Promotional Content. By utilizing an existing pattern, these promotions, which are conditional to only certain vehicles or instances, can display as needed without disrupting the page layout.
F: Servicing Dealer. Although the dealership meta-data feed is not open to re-design, I added a Google Map API, as analytics indicated that nearly 60% of our customers access this page on a mobile device, and including a map may provide a shortcut to finding the dealership.

Post-MVP

While the Dashboard team delivered the work within the timeframe, ultimately the client decided to pause the launch of the Logged In Dashboard until there is more dependency work done on the global navigation, which gives me the opportunity to consider backlogged items that are now viable for the initial launch, including

User Testing: I am currently working on a proposed user testing plan to help get actual customer feedback about the proposed Dashboard components, navigation, naming conventions, and other insights that will inform better design decisions.
Map Consolidation: the current owner’s experience has four disparate maps for four categories of servicing dealers. A previous exploration I had conducted recommended consolidating these maps into a single experience and applying faceted navigation to enable customers to find the appropriate dealer; additional work needs to be explored for folding selling dealers into the experience, as well.
Global Navigation: I found there is no universally accepted practice amongst competitors for how the Owner space is reconciled in global navigation, so I proposed that we create some models for doing so and hear what our customers think, as well as insight into the consolidated IA and proposed naming conventions.
Logged Out Experience / Benefits of Ownership: Given the extended timeline, the future launch will include the Logged Out experience, which is a great opportunity for exploring “Benefits of Owner’s Account” to give users better context and incentive to create a digital Toyota account.

Conclusion

Reflection

Although this project has not turned out the way it was initially planned, it is refreshing to know that the clients have remained open to suggestions. While our team proposed at the start that the global navigation should be reconciled prior to launching new pages, we have gotten quite far in establishing a direction for our page, and creating it in such a way that it should be relatively easy to add or modify components moving forward as the page develops.

Toyota Digital Redefined: Building a Lasting Relationship