Embedded Files
Summary
Summary
Overview
Overview
Over a course of 14 weeks, I had the opportunity to work on Modus, Trimble's design system. The purpose of Modus is to unify Trimble's digital products under one cohesive brand. For context, Trimble is a global company that has 4 main sectors in contruction, agriculture, transportation, and geospacial technologies. Since Trimble is built from various acquisitions, there are several design systems within the company that have unique styling for each team, product, or sector. A design system like Modus promotes scalability and efficiency.
My role
Throughout the duration of the project, my primary role was a UX designer working under John Bacus, the head of the UX department, and Ewa Nowak, the product manager of Modus. I worked with several internal designers, researchers, developers, and product managers.
My responsibilities involved:
Auditing and making updates to the Modus design components in the web and mobile Figma UI kits
Spearheading the redesign of the Modus desktop UI kit
Working on a tiger team to build a new wizard/progress stepper component
Building high fidelity prototypes to validate the design system
The problem
The Modus style guide contains all of Trimble's design components, and it is posted online for public view. While developers often reference this resource to code up components, designers use the Modus UI kits on Figma to design their interfaces.
When I started, there were several inconsistencies between the online style guide and the Figma UI kits for web and mobile. This frustrated several internal employees, especially developers who were coding up the components after handoff.
Additionally, the desktop Figma UI kit was relatively new and did not match with Modus styling. As a result, designers rarely used these desktop components.
Auditing components and making changes
Auditing components and making changes
In order to fix the inconsistencies between the online style guide and UI kits, I had to identify them first. Both web and mobile platforms had about 30 components each, so I made a spreadsheet to document the differences I saw. Once I was done with my audit, I scheduled meetings with Ewa and senior designers Eric Gunther and Randall Stillwell to go over each component and determine which styling was correct.
After my audit was completely reviewed, it was time to make changes to the components in the UI kits. I would create a new branch on Figma and update a few components at a time. Then I would schedule design reviews to go over my work and apply feedback as needed. This was an iterative process, and I ended up merging in several branches into the main UI kit.
Attending the accessibility forum
Fixing the mobile and web components meant that I had to design for accessibility. Therefore, I attended biweekly meetings, in which we would figure out how to make the components WCAG compliant. Many of our discussions pertained to colors and proper contrast. After agreeing to a plan, I would incorporate the changes, schedule a review, and then merge into main.
Redesigning the Modus desktop UI kit
Redesigning the Modus desktop UI kit
The major project I spearheaded was redesigning the desktop Figma UI kit. It wasn't touched for almost a year, and the styling was quite outdated. While the web and mobile kits matched Modus styling more closely, the desktop kit deviated the most and therefore remained unused. My job was to update the kit so that other teams would use it to design for desktop applications.
The initial state of the desktop component kit
The desktop kit was based on a beta Windows UI kit, and it had minimal changes. In fact, some of the components within the desktop kit directly referenced external files that I couldn't access or edit. This meant I had to rebuild some of the components in order to make the kit self sufficient.
Stylistically, the components in the Windows UI kit was marked by the following:
Font icons, which rendered to look like radio buttons
Discrete pills, which made it difficult to distinguish variants from each other
Poor color contrast, which didn't meet accessibility standards
Aside from reworking the desktop components to better match Modus styling, I had three main objectives for my new component sets:
Create reusable atomic structure
Apply auto layout for easy handoff
Condense redundant variants while maintaining robust options
By following these objectives, I was considering how to impove the experience for other designers and developers as they use my redesigned components in the desktop UI kit.
Creating reusable atomic structure
Over time, a person's mental model of how an interface should look or function will change, which means that designers will inevitably have to make adjustments to their components in the future. The idea of creating reusable atomic structure is breaking down a component into smaller pieces (atoms) and reusing those pieces in all of the component variants. When a change needs to be made, a designer can just edit a single atom, and the change will apply to all of the instances of that atom. This allows designers to edit dozens of component variants in a short amount of time.
Applying auto layout for easy handoff
Part of being a UX designer is handing off finished designs to a front end developer, and developers naturally have to code under contraints. Therefore, a component is well designed when the designer builds it under the same constraints a front end developer has to follow. Auto layout is a feature on Figma that allows designers to design under the contraints of containers in relation to each other. This makes handoff seamless and gives designers confidence that their components are feasible to code.
Condensing redundant variants while maintaining robust options
A notable issue with customizable components was that they had way too many variants. This cluttered up the page and prevented the components from being scalable and easy to edit. If a designer wanted to add new features to a component, they would have to make dozens of new variants to account for every custom combination. Even finding a specific variant to change would be difficult because of the sheer number of variants to search through.
The solution for reducing the number of variants was adding all the features to each variant and utilizing show/hide properties to essentially allow designers to toggle on whatever feature they want in any combination. With less variants to edit, adding a new feature to enhance component customization would take less time and effort.
The final desktop UI kit
While updating the web and mobile kit was an ongoing process with many senior designers involved, I came the closest to a finished state for the desktop UI kit. At the end of my internship, I merged in changes for all 30 of the components. In terms of the workflow, it was more or less like what I did for the web and mobile kit. I would work on a few components at a time, schedule a review, and repeat.
Mocking up an interface with the desktop components
In order for a design system to be useful, its components need to be used to build interfaces. SketchUp is one of Trimble's digital products, and it is used for 3D modelling. After I updated the desktop UI kit, the SketchUp team was interested in utilizing my redesigned components to update their desktop application. I took a screenshot of the original interface and mocked up what SketchUp would look like with my desktop components.
The original SketchUp experience on desktop
A mockup of the SketchUp experience with redesigned desktop components
At the review, I met with Kathy Davies and Jeremy Kerbs from SketchUp to show the redesigned desktop UI kit and my mockup. I was happy to hear their appreciation for my work and intent to use/build upon the components I made.
Creating the wizard component
Creating the wizard component
Before I joined Trimble, there was a need for a wizard stepper component, so I was able to join a tiger team to build the new component and establish guidelines. Every week, I would meet with senior designers Sara Farhat, Carlos Cuellar, and Carlos Rodriguez.
Conducting design research
Since a wizard stepper didn't exist in the Modus style guide or any of the Figma UI kits, we conducted some design research and competitive analysis to evaluate existing designs and their usage.
Experimenting in a component sandbox
After examining existing wizard/progress steppers, I started building drafts of the wizard component in a sandbox. At the same time, each member of the team made their own respective sandbox and built their own drafts. This allowed us to rapidly ideate designs.
Iterating on component guidelines
When we were done ideating, we sythesized our ideas together to make a final stepper component design. The next step was to specify the component guidelines, which included usage, anatomy, layout, behavior and accessibility. Over several meetings, we discussed which guidelines would make sense for Trimble's use cases.
The final wizard stepper component
The final wizard component was ready to use for prototyping and customizable with plenty of options. Along with the component guidelines, the wizard was presented to Ewa, Eric, Randall, and developers on the Modus team. It was rewarding to see the component approved and merged into the Modus UI kits. Developers then made a ticket for implemention.
Building prototypes to validate Modus
Building prototypes to validate Modus
It turned out that for some components, static designs weren't enough to understand their behavior or determine if they were useful assets in the Modus design system. Therefore, I utilized Figma's prototyping feature to animate component interactions for various use cases.
Evaluating the side navigation on Trimble Connect
One particular component with complex behavior was the side navigation. Ewa was interested to know how users would react to the side navigation specified in Modus versus the existing side navigation in Trimble Connect, one of the company's digital products. I worked with user researchers Finn Kuipers and Michelle Ma on a weekly basis to prepare for A/B user testing.
First, we evaluated the existing side nav in Trimble Connect. It did not follow the same behavior as the side nav in Modus, as the interactions resembled that of a nested accordion menu.
After we established the scope of the desired prototype and confirmed the behaviors to animate, I prototyped a recreation of the original side navigation experience. Then, my job was to prototype the exact same experience with Modus side navigation.
A prototype of the original side nav on Trimble Connect
Screen Recording 2024-07-16 at 9.16.05 AM.movA prototype of Trimble Connect with a Modus side nav
Screen Recording 2024-07-16 at 9.28.15 AM.movOnce both prototypes were finished, Ewa, Finn, and Michelle reviewed and approved them for A/B testing. Finn and Michelle proceeded with determining what tasks users would perform during the tests and what data to collect. While I was not able to find out about the results, I was glad to know that my prototypes would be used for real user testing.
Prototyping component behavior for developers
On a regular basis, I would meet with front end developers on the Modus team, and we would discuss which components were ready for development, which components needed design updates, and any action items for the components in progress.
For some of the components, the static designs on Figma did not sufficiently communicate component behavior. Developers didn't feel sufficiently prepared to code these up or even questioned what they were for, as the animations were not specified. To resolve any uncertainties, I made high fidelity prototypes of these components. Some examples included the indeterminate progress bar and critical action button.
Critical action button
This is used for important actions that are not reversible. These kinds of actions can be extremely problematic if done by mistake
The button requires users to hold it down for an extended time before the critical action is performed
A color sweep shows users how long they need to hold the button for
It gives users time to change their mind and prevents irreversible mistakes
static critical action button
prototyped critical action button
Indeterminate progress bar
The component is used when there is an unspecified amount of wait time, especially when progress isn't detectable or necessary to know
Users get feedback that something is loading and still working
static indeterminate progress bar
prototyped indeterminate progress bar
As a result from my prototypes, developers got the clarification they needed to proceed with coding up the components.
Reflection
Reflection
What I learned
Design systems at a large scale: With such a large design system, updates are a collaborative effort with multiple editors and design input from cross functional professionals
Agile design methodologies: I gained experience working in branches and merging design changes on Figma. As a whole, my design system updates were broken down into small pieces to streamline reviews and continuous improvement.
Technical Figma/design skills: I was able to format my components using auto layout and utilize component properties to create robust and customizable options. This makes my components readily available for prototyping and handoff.
Iterative design process: From conceptualizing components to launching designs into development, I have learned what it takes to form and maintain the building blocks of digital interfaces.
Moving forward
If I had more time to work on Modus, I would want to focus on how to futher promote its adoption within the company. This could take the form of continuing to update the Figma UI kits and style guide or establishing strategies to get cross functional teams on the same page. While I made great contributions in making the design system more cohesive and pushing component designs for development, brand unification is an ongoing process. Each team and sector at Trimble has its own needs, so Modus needs to account for all of them. As a company, Trimble is still integrating its teams together, and there is more to be done before it reaches unification.
Page updated
Google Sites
Report abuse