top of page
dreamstimemaximum_198500883.jpg

TOYOTA

​Digital transformation of disparate legacy Dealer and Agent/Finance B2B/Enterprise apps using Salesforce Lightning (SLDS).

​

Brand tenants included: Mazda, Toyota/Lexus, and Bass Pro Shops.

BACKGROUND

Large-scale, high-profile digital transformation of legacy Dealer and Agent enterprise apps using Salesforce Lightning (SLDS)

​​Toyota Financial Services (TFS) is the finance and insurance brand for Toyota and Lexus in North America. While TFS is a separate business entity, it is an essential part of Toyota Motor North America (TMNA). Within TFS, TFS Digital encompasses customer, dealer, and team member interaction channels.

​

Only within the last couple years did UX have a proper seat at the table at Toyota. Prior to this, "design decisions" were routinely made by Product and Engineering ("scary", I know). Having UX embedded within Digital Factory Teams enabled an unprecedented level of digital transformation. I was assigned to Enterprise apps for Dealer and Agent/Finance, given my extensive B2B/Enterprise apps experience. Other design teams worked on Consumer-facing apps.

 

Legacy Dealer and Agent enterprise apps had been in existence roughly a decade. Problems included:

  • Disparate & disconnected. Sometimes users needed to login to 2-4 different enterprise apps to complete a task plus having to re-enter information repeatedly as the apps didn't communicate with one another.

  • Cumbersome user interface

  • Built with older technologies

 

Digital transformation of Dealer and Agent enterprise apps (based on Salesforce Lightning) offered:

  • Interconnected; seamless communication between apps

  • Improved performance and UX

  • Latest technologies

 

Goal: Digital transformation of legacy Dealer and Agent enterprise apps using Salesforce Lightning, with releases rolled-out in phases.

​

Brand tenants included: Mazda, Toyota/Lexus, and Bass Pro Shops, each with varying business requirements.

​​The Dealer apps are used by Internal team members at Dealers (Sales, Service, and Finance) enabling over $54 billion in annual earnings (EBITDA) for TMNA.

​

This high-visibility endeavor comprised an expansive team, from Toyota employees (including Product, Engineering, UX, Executive Management, etc.), to outside consulting firms (Infosys, Photon, etc.), plus highly-experienced consultants (like myself).

HIGH LEVEL TIMELINE
1-year of longer-term project. (Budget freeze amid supply chain turbulences on quarterly profits; revised full-year guidance.)
MAKE OF THE TEAM
Sole UX Designer assigned to specific Digital Factory Team.
KEY GOAL
Digital transformation of disparate legacy Dealer and Agent/Finance enterprise apps to Salesforce Lightning (SLDS).
dreamstimemaximum_109227961.jpg

MY ROLE

UX Design Lead Consultant on Dealer Digital Factory Team

I was a Lead UX Designer Consultant on a Dealer Digital Factory Team--digital transformation of legacy Dealer enterprise apps using Salesforce Lightning Design System (SLDS). By extension, I was also part of a larger UX Design group, however those designers were with a different vendor working on consumer-facing apps, so I only interacted with them intermittently.

​

My UX Director was fairly new himself to Toyota; started a month or so before I did. He was astute enough to recognize that while the consumer-facing designers were skilled at what they do--B2C/Consumer is a completely different ballgame than B2B/Enterprise. He knew that he needed someone heavily steeped in enterprise apps. The fact that I also had firsthand Motor City Automotive OEM experience (Ford, prior to Silicon Valley) was "icing on the cake"--a match made in heaven! :-)

 

Our UX Team were scattered coast-to-coast; ditto for Engineering. Executive Management and Toyota staff were local to Plano, Texas HQ. We were fully remote with phone/video conferences. When Toyota started embracing hybrid in Spring '22, it was only one day/week and only for those local to the Dallas/Ft.Worth/Plano, TX area. Being on the West Coast, I was remote the entire time.

 

Occasionally there were early morning meetings, but being remote, it was never an issue. (Honestly, easier than getting-up super EARLY to be on the freeways by 6am to shave a half-hour off my morning commute to Silicon Valley so it would be "only an hour" instead of 90min.) Central or even Eastern Time Zones are no issue when remote! ;-)


​Established GREAT rapport with my colleagues on the Dealer team! One colleague in particular--we "took care of business" and got business DONE! :-) More on that later... 

​

My deliverables were primarily UX Design (wireframes), plus negotiating critical buy-in from Business stakeholders, and collaborating with the Dev Team.

dreamstimemaximum_163149401.jpg

UX STRATEGY

Open to Change

Negotiating critical buy-in from stakeholders & establishing trust

Open to Change:
  • Negotiating critical buy-in from stakeholders
  • Option A + Option B
  • "Think it over..."

During the course of migrating disparate legacy Dealer enterprise apps into Salesforce Lightning...if there were opportunities to make strategic improvements to the UX--within the real world constraints of time and budget--I absolutely pushed for it! I understood the Business stakeholders, and knew how to talk to them.

​

Automotive and Tech are two very different worlds--and that's not meant as any disrespect to either of them. Automotive isn't like "The Wild West in Silicon Valley" where tech companies release "buggy" software all the time (and they know it's buggy!). "Oh, we'll issue a bug patch within a few months; customers won't even have time to notice." This happens ALL the time! But Automotive isn't like that. They can't "throw caution to the wind" or "release a vehicle with 99% of its parts". Every "i" has to be dotted, every "t" has to be crossed. Any "change" is going to be deliberate and thorough.

​

I understood the Business stakeholders and knew how to talk to them.

​

In order to secure buy-in on strategic improvements to the UX, I needed stakeholders to be open to change. How did I go about achieving this?

 

First, I often presented variations on how the application could be via Option A, Option B. This way stakeholders felt they had a choice.

 

Second, I'd always leave off with, "Think about it!" "Think it over?"
Very low pressure. Gave stakeholders time to mull things over.

​

My strategy worked!

 

Some time later, one of the other Dealer team members reached-out to me privately and said, "Some of these Dealer meetings that you haven't been a part of, Business stakeholders have had a lot of great things to say about you!"

"Really?", I asked.

She added, "They've said... "Laura comes up with some really great ideas! She's got us thinking about things in ways we've never thought of before!" 

I replied, "Oh wow! That really warms my heart! That's EXACTLY what I was going for!" :-)​

 

Honestly, half the equation was the actual UX Deliverables (wireframes), and the other half was having strong business acumen and the ability to negotiate critical buy-in from stakeholders. That's how design is achieved in the real world.

dreamstimemaximum_48056415.jpg

UX DESIGN
EVOLUTION  ​

Before & After

Payment Payoff:
Mazda
Toyota/Lexus

UX Design Evolution:
  • Before & After
  • Payment Payoff: Mazda, Toyota/Lexus

Suppose a customer visits a dealer and wants to trade-in their existing vehicle for a new vehicle purchase. Before the dealer is able to sell that trade-in on the Used Vehicle lot (forgive me, "Certified Pre-Owned"), the dealer needs to ensure the vehicle is fully paid-off. Therefore, if there's any remaining balance on the auto loan--that needs to be brought current.

 

This is known as Payment Payoff: When the dealer is paying-off the remainder of the auto loan on behalf of the customer.

 

The legacy version of Payment Payoff...functionally it worked, but wasn't the most intuitive. Form fields were akin to "a wrap-around string of beads" instead of logical placements. I knew we could do better!

​

For the new version, I made sure to have clearly defined sections with adequate "white space" + logical field arrangements, for easy, at-a-glance comprehension. System-generated fields denoted by gray shading; user-entered fields in white.

​

Help Center contained within its own portlet (instead of nondescript links off to the side in legacy). Contact Us portlet adjacent to Help Center for convenience. Background story on the behind-the-scenes making the Help Center a reality, discussed in another section below.

​

Screen variations for one vehicle and multiple vehicles search results for customer trade-in.

 

One vehicle--straightforward as there's only one option.

 

Multiple vehicles--clear presentation of vital information; radio button selection.


With multiple vehicles, it's imperative the user selects the correct vehicle for Payment/Payoff. If the wrong vehicle is paid-off, there's NO "Undo" button. Instead, a second transaction (to counterbalance the first transaction) would be needed, followed by a third transaction (that you hope is correct this time) to payoff the correct vehicle. The old adage, "An ounce of prevention is worth a pound of cure!" is very apt regarding Payment/Payoff. ;-)

STREAMLINED UX DESIGN

 

​Simple, clean, flat design using Salesforce Lightning (SLDS).

 

Action Buttons - Primary in blue; secondary in white.

​

Clearly Identified Sections - Titles, divider lines, and adequate white space. Logical placement of fields.

​

System-generated Read Only Data - Disabled input fields indicated with light gray shading.

​

The Fine Print - Readily noticeable yet not obtrusive.

​

​Info icons - Links and callouts.

 

Help Center + Contact Us - Their own dedicated tiles, off to the side. Help Center contains unique Q&A specific to the particular page/task at hand.

​

Slideshow contains:

  • One vehicle search results

  • Multiple vehicles search results

  • Review

  • Submit

  • Confirmation (Success & Failure)

  • The legacy "before" page

Water trail foaming behind a ferry boat in Aegean sea, Greece, Europe..jpg

UX DESIGN
EVOLUTION  ​

Payment Payoff:
Bass Pro Shops

Edge-case scenario: 
Multiple assets within multiple asset classes

UX Design Evolution:
  • Payment Payoff: Bass Pro Shops
  • Edge-case scenario: Multiple assets within multiple asset classes

The previous example of Payment Payoff was for motor vehicles for the Automotive brand tenants: Mazda and Toyota/Lexus. Motor vehicles have VINs. A single asset class of motor vehicles with search results: one or multiple vehicles. Fairly straightforward.

​

But what happens in the case of brand tenant Bass Pro Shops with multiple asset classes:

  • Marine Packages containing:

    • Boat (HINs or Hull Identification Numbers)​

    • Motors (1-4 possible motors, ID'd by Serial Numbers)

    • Trailer (Serial Number)

  • ATV/UTV (VINs)​

  • Trailer/Other (Serial Numbers)

 

And what IF an SSN search on a "high roller" customer revealed multiple assets within each of the multiple asset classes--how would THAT screen look like?​

​

This is known as an Edge-case scenario: Not likely to happen often, but important to build for when it does.

​

If you can design for the complex edge-case scenario--everything else flows downstream. You have your bases covered! You've built flexibility into the design. 

 

Otherwise, by ignoring the complex edge-case scenario, what eventually happens is the simpler design is unable to accommodate the edge-case and breaks. Then it's back-to-the-drawing-board to re-design (and re-build) a new solution (time, effort, and expense).

 

Build flexibility into the design early on by designing for the edge-case scenario. This was one of the invaluable things I'd learned while at Walmart Global eCommerce. Once you have that edge-case scenario mindset--you're automatically thinking ahead on this to avoid having to revisit the edge-case scenario down the road. 

 

Thus, when it was time to design Payment Payoff for Bass Pro Shops, I automatically designed for the edge-case scenario. The page already needed to show the different asset classes (Marine/Boat, ATV/UTV, Trailer/Other). I took things a step further by showing multiple assets within each of those different asset classes. This forward-thinking strategy worked!

​

For the Bass Pro version, I made sure to have clearly defined asset class sections (Marine, ATV/UTV, Trailer/Other) with multiple assets within each. "View All" within an asset class brings up a modal showcasing detailed tiles for each of those assets--to ensure the user is able to compare asset details and select the correct asset for Payment Payoff. Once selected, blue "Select" button changes to white "Unselect".

 

Back on the main page, selected asset tile appears off to the right (below Help Center and Contact tiles) for easy reference + green checkmark icon appears next to the selected asset (bulleted list).

​

At one point, Engineering suggested, "Why can't we just put a few items of info with a "Select" button at the line level in the bulleted lists? That would be quicker!" I replied, "Look, in the case of ATV/UTV, what if the customer has 4 ATVs, one blue, one red, and two black...and is trading-in one of the black ones. If we display too little info at the line level...user selects the wrong black ATV, it's not saving any time. Extra work for that Dealer employee, we look BAD in front of the customer, Controller is NOT going to be happy with all the extra transactions to fix that! Shortcuts aren't doing anyone any favors here." They understood the point. ;-)


With multiple assets, again, it's imperative the user selects the correct asset for Payment/Payoff. If the wrong asset is paid-off, there's NO "Undo" button. Instead, a second transaction (to counterbalance the first transaction) would be needed, followed by a third transaction (that you hope is correct this time) to payoff the correct asset. The old adage, "An ounce of prevention is worth a pound of cure!" is very apt regarding Payment/Payoff. ;-)

EDGE-CASE SCENARIO

 

​Payment Payoff for Bass Pro

 

Servicing As Dealership - This top tile with dropdown selection appears in instances of dealer owner with multiple dealers.

​

Multiple Asset Classes - Marine Packages, ATV/UTV, and Trailer/Other. Clearly identified sections with small icons to easily distinguish.

​

System-generated Read Only Data - Disabled input fields indicated with light gray shading.

​

The Fine Print - Readily noticeable yet not obtrusive.​

 

Help Center + Contact Us - Their own dedicated tiles, off to the side. Help Center contains unique Q&A specific to the particular page/task at hand.

​

Slideshow contains:

  • Multiple assets within multiple asset categories: Marine/Boat, ATV/UTV, Trailer/Other

  • Focus on Marine Packages (most complex)

  • Select

  • Review

  • Submit

  • Confirmation (Success)

dreamstimemaximum_244885309.jpg

UX STRATEGY
 
Help Center
Making the case for customization

Taking care of business
Without having to involve upper management

UX Strategy:
  • Help Center: Worth making the case for customization
  • Taking care of business: Without having to involve upper management

Recall in the legacy screens, "Help Center" was merely some link(s) off to the upper left of the page, rather nondescript. My initial solution (with only one Q&A link) for Help Center was a lifesaver icon + abbreviated link label in the upper right corner of the main page tile (along with phone icon + phone # for Contact Us). Two tidbits of info--worked fine.

 

Subsequent legacy screens later revealed not one but multiple Q&A links. Clearly my initial solution in the upper right corner wasn't feasible going forward. I then decided upon dedicated tiles (off to the right) for Help Center and Contact Us. By encasing Help Center in its own tile with expand/collapse Q&A, info was readily available to the user (without being overwhelming) + able to accommodate however few/many Q&A links.

 

The Dev Team used the Accordion feature from the Salesforce Lightning library. The Accordion feature is typically used on a FAQ page (spanning the width of the page) vs compressed within a smaller tile. Thus, what happened was the Help Center Questions were cutoff as the font was too large. When I requested the font be made smaller (plus wrapping text IF necessary) the response from Dev was, "We can't do that; that's customization." Hmmm?

​

As with the game of Life, there's "battles worth fighting" and "hills not worth dying on". Pick your battles wisely. THIS Help Center was something worth fighting for. ;-)

​

What impressed me the most about the Help Center Q&A content was how specific and targeted it was to the particular task/page at hand.

​

Unfortunately, Help/Support on most sites is sending users off to a generic Support page with a Search box. Then what happens is getting 2-3+ dozen "search results" and feeling more confused than ever! Conversely, the Q&A legacy content avoided all of that nonsense! Clearly a lot of thought, time and effort had gone into this specific, targeted Q&A legacy content! Very impressive!

 

Keep in mind, these are complex financial transactions and the last thing anyone wants is a user taking the wrong action because insufficient and/or inadequate Help was provided. Honestly, the notion of targeted, specific Q&A Help should be The Gold Standard for Help/Support! Very impressive!

​

The Accordion feature within the Help Center tile was the optimal solution! It just needed the font size of the Questions to be tweaked smaller--that's it! Unfortunately, Dev claimed "it wasn't possible" as that constituted "customization". Thus, I didn't let that Dev pushback deter me, and made the case to my boss--requesting authorization for customization. Fortunately, he totally concurred and we planned to get authorization from higher-ups.

​

Next is where it gets interesting... As luck would have it, my boss was so swamped with back-to-back endless meetings, scheduling a meeting with higher-ups didn't happen right away--which is a good thing! Because in the meantime, my "partner in crime" (Senior Business Analyst on the Dealer Team; shhh, "no names"!) was so impressed with the strides I'd made securing critical buy-in with the Business stakeholders (only to see us hit this snag by the Dev Team) said to me privately, "I'm in charge of the User Stories and the JIRA tickets; Dev needs to get past me!" One day, in a fit of exasperation he says to the Dev Team, "Look, you're supposed to be Chefs, NOT Line Cooks! DO something!!" (Great line!) And with that, all these little things that Dev claimed they "couldn't do"...suddenly got done!! :-)

​

My boss later reaches out to me, apologizing for not scheduling those meetings with higher-ups sooner. I said, "Don't even worry about it! It's a blessing in disguise that didn't happen! Because JP and I have been taking care of business! We've got it all sewn-up! DONE!" :-) My boss was especially thankful at what my "partner in crime" and I had accomplished ourselves! And afterwards, we didn't get the same level of pushback from Dev as before. ;-) Taking care of business!

HELP CENTER

 

Help Center with multiple Q&A required its own contained tile.

​

Issues: 

  • Salesforce Accordion feature: default font was too large, resulting in Questions being cutoff.

  • Dev Team claimed not able to reduce font size, as that's "customization".

 

Solutions:

  • Made case to my boss for authorization on customization; he agreed.

  • Meanwhile, Sr Business Analyst able to put pressure on Dev Team to "DO something!" Voila! Success!! :-)

​

​

Slideshow contains:

  • Optimized Help Center design of its own tile (expanded & collapsed) along with Dev Team's initial results (too large font for Questions).

  • Earlier design for Help and Contact links (with icons) in upper right corner of main page tile.

    • Worked fine for one Help link but better solution needed for multiple Help topics. Thus the Help Center tile.​

  • Legacy screen showing one Help link.​

  • Legacy screen showing multiple Help links.

    • Nondescript links off to the upper left. Hardly noticeable.​

​
 

dreamstimemaximum_113377549.jpg

UX DESIGN EVOLUTION

Vehicle Protection Products

Pre-Paid Maintenance (PPM) 

UX Design Evolution​
  • Pre-Paid Maintenance (PPM)

Pre-Paid Maintenance (PPM) is part of Vehicle Protection Products (VPP). PPM plans vary in coverage and benefits (with certain maintenance costs covered and/or at a discounted cost). 

​

If a customer arrives at the Service Dept and says they have a PPM plan, the dealer needs to be able to look-up how much claim coverage is remaining on that PPM plan:

  • What their PPM plan includes

  • Which PPM benefits are still available

  • What PPM benefits were already used (no longer available)

​​

The legacy version of this feature was sad and in need of improvements.

 

To help facilitate this task flow, I designed the page with a two-tile structure. Top tile is to check/verify claim coverage. Upon verification, the bottom tile appears, containing a tabbed top structure of steps within the claim process, along with the ability for the user to go “Back” if necessary before final Submit.

 

Claim Summary page shows all the details plus a progress meter for handy access to specific steps in the claim process.

PRE-PAID MAINTENANCE (PPM)

 

Two-Tiled Design

  • Top tile is to check/verify PPM Claim coverage.

  • Bottom tile appears upon PPM plan verification.

    • Contains tabbed top structure of steps within the claim process.

    • Ability for user to go "Back" at any time in the process, before final "Submit".

 

Claim Summary

Shows all the PPM Claim details, plus progress meter for convenient access to specific steps in the claim process.

Dearborn Saline Map.jpg

FINAL THOUGHTS

Wrap-up

In January 2015, AutomotiveNews featured an article titled "Motor City in Silicon Valley" of the various OEM Automakers and Suppliers setting-up operations in Silicon Valley. From that moment on, getting back into Automotive was at the top of my wish list!🤞 For a Motor City native like me, 6-years at Ford before moving out to Silicon Valley working at countless Tech companies--this would be coming full circle!😊 Many of the Silicon Valley OEM Automotive operations were fairly new (Ford Lab in Palo Alto officially launched in February 2015) with a primary focus on building core FTE teams before needing contractors. Six and a half years later, that wish finally came true with the Toyota contract, working on B2B/Enterprise apps using Salesforce Lightning!😁 It was a triple-bonus for me personally: Automotive, Salesforce Lightning, and Financial Services!👍

​

Although I'm "about as Ford as it gets"😉 (from "Ford Country" + parents worked for Ford + I did too + have been driving Mustangs😍since forever) I was able to tell my Toyota colleagues that my 1st cousin spent 3-decades of his career at the Toyota Tech Center in Saline (near Ann Arbor). So, YES, I DO have some Toyota in the family!👍😂 Actually, the Toyota people were GREAT!👍😁 Honestly, I'd probably have experienced serious ribbing had I taken something with cross-town rival, GM. After all, "domestic rivalries run deep!"😆🤣😂


Outstanding group of seasoned professionals to work with!👍 Was sorry to see things end prematurely after one year, due to ongoing chip shortages impacting vehicle production levels, resulting in reduced quarterly profits and revised full-year guidance. Our department was cut 50%! That said, would love to return to Toyota someday as I thoroughly enjoyed my time there, making an impact on B2B/SaaS/Enterprise apps.

contact

CONTACT

Leopard Design, Inc.

CALIFORNIA

1547 Palos Verdes Mall #294

Walnut Creek, CA  94597-2228​

PHONE

(650) 259-8080

NEVADA

2248 Meridian Blvd., Suite H

Minden, NV  89423​-8620

LinkedIn_white.png

For general inquiries, please fill out the contact form:

Thanks for submitting!

bottom of page