IBM on assignment at Toyota
OVERVIEW & TARGET AUDIENCE
Designed a feature for Pricing in Toyota's Supply Chain Internal Cube Platform. The feature I designed allows power users to easily view and manage incentive program Accounts for specific goals.
Below, I’ve adjusted the UI concepts and information to protect my client. While I can’t provide exact details, I’m confident my designs still communicate my skills as a Product Designer.
MY ROLE
Product Designer for Pricing.
Work alongside the Pricing Product Lead to clarify design requirements with the client.
Reviewing design with different stakeholders including Pricing's client product owner, technical product owner, and the Cube chief product owner.
Handing off the final design for development and overseeing development quality.
GOALS
Users want to be able to create new Accounts, modify or even terminate existing Accounts.
When modifying, users need full control to be able to change effective timelines in addition to changing specific amounts in existing programs.
Allow users to define the date/state of Accounts getting applied.
CHALLENGES
Reducing the long learning curve for new users
Making the system less restrictive and rigid (10+ years old)
Create user flows and components that fit business needs across a rolling release cycle.
Harmonizing goals among diverse stakeholders.
roadblocks in place:
This feature had multiple different layers of organization needed and many multiple different actions required by the user.
It was easy to get lost in the complexity of the data and hard to decipher what was happening at a glimpse.
There were many different stakeholders on the team from our Chief Program Officer to our core Pricing Team to our Technical Product Owners and they all had different opinions and preferences on layout.
Low-fidelity Painpoints
I was asked to step in during the low-fidelity stage to accelerate and finalize designing. The main ask was for me to make the final design cohesive and straight forward. I worked with the core pricing team to understand their users, business needs and scenarios. Our cross-functional team brought together diverse perspectives, from our product owner to the original legacy engineers. By collaborating closely, we ensured the new design preserved core legacy functionality while addressing user painpoints.
Snapshot of complexity from a single Requirements meeting
I ultimately decided that the landing page needed to be simple data table of all the Accounts and focused on high level summary information. This way users won't be overwhelmed with information but can click into each Account to view more information and take actions. To organize the data and prompt actions I added KPI tiles for users that will easily filter the data table. I also replaced the dark filled chips with outlined chips instead to accommodate user feedback on how they found it distracting.
Landing Page
The biggest shift I added was a landing page of all the Accounts. This allowed users to see all the programs at a high level and easily expand each Account to see any exceptions.
series view page
Users requested to have a dedicated series view. This allowed them to easily see all Series and mapping of relevant Accounts for each of those Series.
Account Details Page
From the landing page users can click into a specific Account to see further details. There they can take all their actions to manage the Account details and values by the Series level.
As development progresses I will review and run QA testing across all development environments. I'll continue to iterate on the designed experience as dependent features are built and additional user testing occurs. Most notably, this landing page structure has set the standard for subsequent Pricing features — reaffirming our users value concise, summarized information and streamlined navigation.