In 2018, I led and initiated an effort to implement a design system for a flagship product called Ford Commercial Solutions.
Each product team was implementing custom styling and recreating elements that contributed to an inconsistent user experience. Valuable time was wasted that could have been leveraged to enhance our platform and provide value to our users.
We knew we could solve this problem with creating our own system and establishing new practices amongst our frontend teams.
Ford Motor Company, Ford Commercial Solutions
Lead designer
March - June 2018
Ford Commercial Solutions creates tools and services to help fleets of vehicles optimize, adapt, become more operationally efficient, and more deeply understand the health of their fleet. Our integrated tool helped fleet managers increase vehicle uptime, reduce maintenance costs, manage compliance, and understand business impact on a per-vehicle and per-driver level. Ford Telematics™ data allowed fleet managers to monitor their vehicles at all times to understand where they go, how they’re used, and how they’re running.
Our customers included fleets for non-emergency medical transportation vehicles, police, plumbers, construction groups, and more.
For example, our table component, one of our most heavily used UI elements, had been implemented vastly differently across four different pages. When we were building out our live map feature to provide realtime updates of vehicle location and status (e.g. stopped, idle, moving), we needed a table that listed out the events. My team found it was difficult to rebuild and that the other teams all implemented our tables differently (across 8 different pages).
For the system's visual elements, we also had several differently defined colors, icons, and type styles and didn’t know the power of design tokens.
Here’s an example of a UI page that displays the various vehicles, customers, and their pricing package. This page, along with several other pages in our app, had its own implementation of a data table. The design and layout is different as seen below in the Fuel UI page example. We wanted to streamline one of our more complicated UI elements by providing a component that accounted for the various needs of our table, like displaying custom columns, expanding and collapsing rows and sorting columns.
In February 2018, the product teams came together for a goals workshop. We had learned over the previous few months that the users' experience was being negatively impacted by the lack of cohesion from our UI inconsistencies, causing confusion and frustration.
Rather than sweeping these issues under the rug, our team decided to prioritize addressing these inconsistencies to help build trust and improve the way we built our product.
Our goal: Our design system helps us work together to build a great experience for all of our FCS customers.
To uncover the issues in detail, I organized a UI audit exercise with our Product Manager, developers, and another designer to identify the disparities in the design and code at micro and macro levels.
We printed off screenshots of every product page and put them up on the walls. By seeing everything in one place and side by side, it helped us quickly find the variability.
The audit helped us...
We printed off each page and workflow of the application to more clearly visualize the inconsistencies. We added post-it notes of our observations, questions, categories, and possible solutions.
Yolanda was the product owner for the team. She had been a long time Ford vet and this was her first foray in agile software development practices. I helped teach her about systems, user experience design, and more.
Here’s one of our designers, Lauren, looking at some components and finding their inconsistencies across the pages.
Ford had an established brand and styleguide for its digital products. But the library it lived in experienced serious neglect. Being a designer who had been using the Sketch file and site for a few months, I had seen and experienced it firsthand. The sketch file alone had a slew of inconsistencies, redundancies, and one-off components, which contributed to the greater problem of UI inconsistency in the product itself. At the time, our designers didn’t have enough capacity to maintain or add to it, so it was not as tended to and cared for as it needed to be.
With our findings from the audit, I got to work on the Sketch UI Library and system, “FUI,” which stands for “FCS User Interface.”
Our library was laden with messiness, redundancies, and inconsistent styling choices that contributed to a poor user experience.
Icons were a mix of Font Awesome and one-offs that didn’t stylistically relate to each other. There were also different icons implemented that represented the same concept.
The symbols in Sketch had too much variability in the styles applied to them, like the spacing, text sizes, colors, and more. I wanted to simplify our components and group them logically, while providing enough flexibility for variants and states.
Our colors were previously duplicated with our SASS variables over and over and over again. We wanted to reduce the amount of times we defined our colors and associate them with our global color palette better.
Our previous living “styleguide” was difficult to parse through and find a needed component to reference. There also weren't code snippets, documentation, or guidelines for proper usage.
I experimented with updating and streamlining components and styles by implementing them across various product pages. We continued to use Sketch, and its (“new" at the time) Sketch shared library. I was able to create a library of UI components with corresponding “how to use” documentation and guidelines. With learnings from the audit, I also simplified and systematized our typography and colors, like removing too many similar neutrals and reducing type styles that were too specific to features or components.
When the library was in an MVP, shareable state, we made it available to our designers via Sketch Library. By utilizing the editable and flexible Sketch symbols, our designers could focus on UX, and not re-designing the product over and over. I also taught the designers how to contribute new components and styles.
Additionally, we evaluated the needs for adding new components together as a team. I ran workshops to determine how we could define those components and patterns visually to continue enhancing the experience of our product.
We also created a site to see live components and learn how to implement them. We were a Vue based app, so our components were all written in the framework.
This gif is a quick tour of the Sketch file containing all the patterns, components, and styles for FUI. Within the other pages of the Sketch Library file, I included detailed documentation for each of the components and styles for how they were to be implemented and used in the product. We eventually used some of this documentation for the FUI living site as well.
We simplified our color system, particularly our neutrals, to follow a better naming schema as well as reducing the number of different colors previously used. We had several grays that were so close in color that it didn’t make sense to have them all. We also made it easier for designers to access the color palette by employing a color plugin and sharing the palette with the designers in our shared Google Drive. Nowadays, it's much easier to embed color palettes into a UI library, but this was not available a few years ago!
What I wish we could have done differently was incorporate accessibility color needs. At the time, the priority was to incorporate the already branded color system and I did not have as deep of a knowledge base in A11y as I do now.
We also simplified our typography styles, as they were too specific and each page was using their own sizing, line-heights, weights, colors and more.
For each of our components, I detailed their instances, design, and some guidelines for usage in the Sketch UI Library.
Our team translated each of our components into our newly minted living styleguide site to make the components easily accessible for our developers and designers to view when building their UI experiences. This is an example of our "Tables" component. Each component page included the component's code, the different variants or instances, and guidelines for usage.
As we added components to FUI, our teams adopted them as they came, starting with tables and dialogs. Teams were eager to use the new system as it was simpler to adopt than recreating elements on their own or finding external third party libraries, as they had been doing previously.
Designers began to use the Sketch Library in their designs and were also contributing new patterns and components as needed. It was encouraging to see the system working to align our UI within the teams and across the product.
FUI is still used by the FCS product teams today, 4 years after we launched the initial version. It’s great to see the FUI system continue to be useful in delivering value to the internal team members at Ford, but also the end users at large.
