Toyota 

2024
IBM x Toyota

While at IBM I lead visual design for a product called Vehicle Configurator Gateway (VCG) at Toyota. In essence, IBM had taken on a broad re-organization and re-design of a large group of digital products used internally by Toyota, bringing them all together under the moniker Cube. The scope of these products covered everything from pricing to supply chain to manufacturing instructions; the long term goal was to bring all of Toyota’s software needs to a centralized application. We had a dozen or so designers working on various parts of the account, unified in our approach but each focusing on a particular product. 


s.  01

Intro


While at IBM I lead visual design for a product called Vehicle Configurator Gateway (VCG) at Toyota. In essence, IBM had taken on a broad re-organization and re-design of a large group of digital products used internally by Toyota, bringing them all together under the moniker Cube. The scope of these products covered everything from pricing to supply chain to manufacturing instructions; the long term goal was to bring all of Toyota’s software needs to a centralized application. We had a dozen or so designers working on various parts of the account, unified in our approach but each focusing on a particular product. 

Although I did some work to help unify the design choices across products the majority of my effort was dedicated to VCG, an application meant to handle the enormous amount of data coming to the US from Japan, containing details of all of the possible combinations of vehicle parts that could be configured, built, and ordered by plants and customers alike. Although the application itself is used internally the technology it is founded on will serve as the engine for Toyota.com, allowing customers to get an idea of the realm of possibilities when ordering a Toyota vehicle. 

s.  02

mutliple products, one system


Toyota Cube 

The vision behind the Cube was to unify nearly a dozen workstreams under IBM’s watch in the same global application, using common visual themes to tie them together. Each shared the same design system and the system was designed to be flexible from the start, allowing new products to be added through an app switcher. Global functionalities like SSO permissions and the ability to search across products took away the headache of dealing with multiple data sources.

s.  03

Vehicle Configuration Gateway


In short, Vehicle Configuration Gateway aims to manage every aspect of the (very complicated) vehicle configuration process, from product planning to production. It serves as a source of truth for what can and can’t be built within the Toyota lineup at any given point, constantly receiving updates which a team of analysts is currently breaking down manually using spreadsheets translated from Japanese. We were able to automate a large part of that manual work load and simplify the daily tasks for these analysts. The application itself is more or less a series of tables, the crux being in how best to display the data and empower users to resolve conflicts between sources in more complicated scenarios. 




s.  04

Approach 

To successfully transform and reimagine a new configuration experience, it was important to understand the current state and map the end-to-end configuration journey. User research was integral throughout the process to identify areas of opportunities and to develop a clear vision for a future state. 

User interviews, discovery sessions, and co-creation sessions allowed the team to iterate and align on the future vision for VCG while maintaining a consistent reference to the users and their goals. 

Understanding the workflow of analysts was essential to redesigning their tools.  



Site flow and architecture mapping.




s.  05

Pain points with the existing experience



Time-consuming Processes


• manual process of inputting specs from the external documents

• difficulty coordinating between PPD and Marketing to clarify conflicts and retrieve approvals on configurations.

 conflicts and resolution


• manually digging around in spec sheets for all the rules and conflicts to identify conflicts or rule issues.

• complex and confusing conflict messaging when conflicts are present

Delayed Validation


• users load an external spec report to view if configurations are unbuildable.

• it is difficult to view if two specs are valid together

• in existing software users submit configurations to see if a workspace is valid, no immediate feedback

Data management


• positive reactions to the ability to duplicate or copy configurations of similar models/series.

• carried over unrelated specs from previous models leads to irrelevant data for new series. (PASS)


s.  06

VCG Features and functionality


Katashiki List View

A katashiki is essentially a vehicle frame. This screen allows users to track the incoming frame modifications from the source data in Japan.
Katashiki Detail View

A katashiki is essentially a vehicle frame. This screen allows users to view all of the data related to a vehicle setup, make changes, and approve for building. Things like specifcations for sun roof, headlights, trim, paint colors etc. are found here. Users are notified as changes come in and in the rare case that there is a conflicting piece of data the resolution process is made simple for them.
Accurately notifying users of changes and errors was one of the biggest value adds we were proposing.
Statistics allow analysts to keep track of their active workload across model years.



s.  07

A note on the design system

Throughout the project we adhered closely to a design system that was actually of our own creating as IBM had gotten in early on this work. Despite a robust starting point we found ourselves constantly adapting and expanding the work that had already been done, sending changes to the global UI team in charge of developing the components. Our team at VCG being one of the most mature products in the ecosystem we found oursevles with the responsibility of setting standards for the other products both in ways of working and in terms of the design decisions being made that would have a global impact on Cube.

A quick look at some of the components pages.


This modal is an example of a big deviation from the system due to its complexity and the idiosyncracy of its use case.



s.  08

Closing thoughts


This project presented many of the usual challenges with this type of work. The amount of industry knowledge required in order to meaningfully contribute to the design process was enormous and thus the onboarding cycle was protracted for months. To be honest it was only as I was leaving the project that I felt I had a hold on what was going on behind the scenes. As a designer in this scenario it’s easy enough to memorize the rules and design to them without understanding what underlies them, and when working with companies on this scale that have deeply engrained rituals and ideas about how things should be done (often determined by shortcomings in the original software they were forced to use) it can become difficult to effectively challenge beliefs in order to offer a better experience. I was lucky to have some great pre-cursor work on this project completed by Sam Taylor, under his guidance a lot of the initial questions had already been asked and when it came to testing some of our ideas we had already built a slight rapport with the team we were designing for. Unfortunately the nature of projects like this is that they usually drag on for so long that you never get to see how well they work in the end. When I left the team we had implemented most of the UI work and all that remained was to hook it up in the back end. If anyone at Toyota is reading this, let me know how it went.




INdex
Next Case study
Nomenclature Typography

Toyota North America
Nomenclature typography
EIA Africa Geo-Portal
Discount Tire
Google
New York State D.O.H.
Shell Polymers



Alex Sweet 

© 2024 
Hello@alexsweet.design
Instagram
Typography Site

Available for full time + Freelance!