Overview
Background
My team was asked to build a custom design system for our client ArcBest. ArcBest is a large shipping and logistics company that has been in business for several decades. As a result, their software systems at the time were outdated and fragmented; they planned to upgrade their systems to create something more modern, streamlined, and easy to use.
The design system my team needed to build would be the first step in the client’s overarching plan — it would enable ArcBest to apply a cohesive look and feel to their improved software tools, and make those tools align with their branding.
Results
My team delivered a fully custom design system in 3 months; I specifically contributed 24 components (60% of the design system) from scratch, as well as supporting documentation for each to support the client's dev team.
Our work led to four contract renewals over the course of 2024, totaling $500,000+ in revenue for our agency.
My Team
I was one of three designers: two of us did the bulk of the execution work, while the design lead provided higher-level guidance and leadership. We also had a product manager to liaison with the client and plan our sprints.
Tools Used
Figma
design system library and documentation
Sketch
initial starting tool, replaced by FigmaNotion
documentation drafts, meeting notesGoogle Slides
client presentations, sprint demosSlack
internal team communications and client messaging
Phase 1
Assessment
When my team first joined the project, our client immediately shared several issues they were having with the design system. First off, the project was almost two years behind schedule. The client had previously been working with another vendor on the design system, but felt that the work produced so far was not robust enough for their developers to implement, nor was it complete enough to constitute a functional, usable design system that could be used to build software products. My team was given several Sketch files that the previous vendor had created, but the client expressed frustration that the files were so poorly organized to the point that even they weren’t sure where to find the most up-to-date designs.
The file from the previous vendor was disorganized and lacked complete states for components. There was no documentation, with most components seeming to be conceptual in nature and not standardized for usability.
We started by auditing what already existed to identify gaps between the current state and desired future state. At the same time, we conducted research into existing design systems, such as Material and those published by Atlassian and Shopify. I collaborated with my team and the design system owner on our client’s team to establish a list of all the components the client wanted to have in the design system. From our review of other design systems, my co-designer and I recommended an organization structure for the design system that would make it easier to find components; rather than having everything on one page, we suggested splitting components into their own individual pages and placed those pages into sections grouped by function. The client was on board with our suggestions, and we got started by creating a new library file in Sketch so that the distinction between the new library and the previous work was clear.
Examples of how my team brought order, robustness, and organization to ArcBest's new design system in Sketch.
Phase 2
Implementation
Throughout the initial stages of the project, the client’s team members that were most involved were the design system owner, a design team manager, and the developer who worked on implementing design system components. I had set up a daily sync with the designers on my team, the client’s developers, and the design system owner, which enabled our team to move quickly while also responding to requests from the developers. We knew that using an established design system as a baseline would help the dev team implement a custom rethemed design system on top of existing components, so we had recommended using Material as a starting point and applying the client’s branding to that. The design manager and design system owner agreed with this plan, so we carried it forward in our design work as we set up the component library.
My team was able to create in-library documentation once we moved to Figma. Here are samples of two documents I wrote on some of the design system's foundational elements.
With the library file in place, my coworker and I started by expanding upon the components that the previous vendor had already created. Our starting point was more like a sample set of a components than a full set of variants; our goal was to flesh out definitions for states, sizes, icons, and so forth for those components. Before we could do that though, we needed to define foundations of the design system. My coworker expanded the color styles and typography, while I refined the elevation styles and spacing definitions. From there, we moved on to basic atoms such as buttons and chips.
Here's one of the component documentation articles I authored. I also created all the variants and styles for this component.
Since we knew the project was behind schedule, my team worked as fast as we could. Since the previous vendor had used Sketch, the client had continued with Sketch, and we also used Sketch on behalf of the client. However, we quickly realized that Sketch’s features simply were behind-the-curve compared to Figma’s; our velocity was lower than anticipated due to the toolset limitations. I put together a document comparing Sketch to Figma and outlined barriers to high velocity that Sketch was causing. I shared this with our team’s PM and escalated it internally, and my team shared our findings with the client.
Our pitch for Figma was accepted; luckily, the client had already considering moving away from Sketch and was happy to try out Figma instead. We had no problems importing our work from Sketch into Figma, and the move away from Sketch increased our team’s velocity by 3-4x. After the switch, I was able to complete a total of 18 component sets in one month: buttons, checkboxes, radio buttons, select fields, text fields, text areas, modals, popover menus, tables, pins, toggle switches, breadcrumbs, tabs, alerts, file pickers, pagination bars, scrim layers, and snackbars. I also lead our design documentation effort, and completed 70% of our library documentation in two weeks. The client team members who attended our sprint demos were thrilled and impressed with the speed at which my team was making progress.
Phase 3
Visual Pivot
At the time, the primary stakeholder on the client team was not attending our demos and we were primarily interfacing with his direct reports, as we had been told that he was too busy managing other projects. However, this became an issue about halfway through the project. Although my team had buy-in from his reports and the engineering team to use the Material Design System as a base, and the rest of the client team was happy with our speed, the primary stakeholder felt that things were proceeding too quickly and that the visual design direction had shifted too far away from the previous vendor’s work. This information was provided to our team quite abruptly, and we had to make a fast pivot to accommodate the primary stakeholder’s needs.
The images above show a mock screen using components from the design system. The image on the left shows the styling that my team had started to implement, while the image on the right shows the styling from the previous vendor. Neither of these screens are representative of a real product, but were created to show design system components in the context of a UI.
This meant cancelling the daily syncs with the engineering team and setting up a twice-weekly call with the primary stakeholder instead. We learned that while we had been directed to work with the rest of the client team, none of those team members had final decision-making or approval authority over the design system. While he was pleased with the depth and rigor that we had introduced to the design system library, the primary stakeholder was unhappy with the use of Material Design as he had wanted something truly custom, not a reskin of another design system. To that end, my team revisited our previous work to integrate the previous vendor’s visual design on top of our more robust framework. I revised the components that I had previously worked on earlier in the project, and took on work where my teammates needed help.
This image shows the unification my team achieved between the pre-existing visual style from the previous vendor and the robust functionality that we introduced to the design system.
We learned that the stakeholder preferred to see components in-context of wireframes to get a better understanding of how the components paired with each other, so we began to create dummy mockups for presenting the design system components. To give us feedback more often, the primary stakeholder made more time for collaborating with my team in his schedule. After working closely with him, we were able achieve the visual look and feel from the previous vendor while expanding the design system to cover components that were not previously and simultaneously preserving the extensive variants, interactive states, and robust documentation that we had created for the library.
In closing
Final Thoughts
Reflections
This project was quite eye-opening in terms of client relationship management. A major takeaway here was that my team should have checked in with the primary stakeholder more frequently, not only the team members we were told to talk to. Just because the reports are happy with how something is going doesn’t mean their leader is.
I realized there often may be business knowledge or internal politics that I am not privy to that impact certain requests or decisions from the client team. It is important to understand what drives stakeholders in order to support them most effectively. Furthermore, it is extremely important to directly communicate with everyone involved in a project even when you’re told someone is too busy or otherwise unable to talk to you. Interfacing directly with key stakeholders, even if those people aren’t involved daily, is critical to understanding their desires and their preferred level of engagement from their own point of view.
Additionally, I would recommend being more open to modifying standard ways of working, as something that works for one person may not work for another. The agency I work for has a standardized process that follows Agile methodology; typically we employ this on projects to great effect, as many clients need the guidance for project management. On this project, however, our typical ways of working and collaborating closely with engineering counterparts caused friction with our primary stakeholder. We had to reassess what delivering successfully on this project meant, and reorganize the way we worked both internally and with the client.
Outcomes
Although the primary stakeholder started out quite unhappy with the direction that my team had gone in, our flexibility to change and our adaptiveness to executing his vision changed his sentiments from negative to very positive. My team was able to make changes very quickly once he was involved and sharing his opinions openly with us. Through being willing to revisit all of our work and revise it, we built trust with the primary stakeholder that we could do exactly what he wanted quickly and effectively.
The project was initially slated to end in December 2022, and if we had performed poorly it would have. However, the client was happy enough with our quick turnaround to correct the visual design that they extended the contract four times, once per quarter in 2023.