A responsive visual component library for FactSet's design system, created using atomic design principles.
Factset is a financial tech company that works on software for financial data. Being a large, well-established company, they had an existing design library with strict guidelines for each component. My project for the summer was creating a visual library using atomic design principles with the intention of creating a new design system. I also built a tutorial/demo file to showcase the library and teach the visual team how to use it.
I created a quick five minute video to explain some context & demo the component library. I walk through a tutorial of how to use the library (& some handy Figma features) and break down how some of the components were built. Further explanation can be found below!
When I joined as a UX Design Intern the summer of 2018, the visual design was in a period of major transition. For much of Factset's recent history, the visual design team used Adobe Fireworks for UI design. The existing visual library was built in Fireworks; however, the software was discontinued by Adobe in 2012.
The existing library had guidelines and specifications hosted on a Wordpress site, but in the form of hundreds of screenshots. As a result, it was a slow process to propagate changes to our Wordpress library and to our engineers to implement into our applications. This, coupled with a visual redesign resulting from our recently signed contract with Bank of America Merrill Lynch (BAML), presented a need to move away from Fireworks and rebuild the library.
The contract with BAML included a modernization of our visual design, so this transition period served as a good opportunity to make the switch. But switch to what?
We landed on Figma as our software of choice. Some of the advantages Figma offered follow:
The team had actually already begun to make the switch, but each new project meant every component had to be built from scratch every time. This is where I came in!
I researched and based our system off of the principles of Brad Frost's Atomic Design. I also did a deep dive of well-known design systems like Google's Material Design, IBM's Carbon Design, and Microsoft's MorningStar Design Systems for inspiration.
As a team, we began breaking down each component of our library and mapping components to each level of organization and determining which components were more complex and could be built out of smaller atoms or molecules. The library needed to be structured such that future editors of the library would be able to easily understand it and make changes.
Some logistical questions we tackled during this phase of planning included: how do I group components intuitively? What kind of naming conventions do I use to become the team standard? How granular should each atom be? (E.g. is the background of a button too specific of a component? What about a text label?)
An ongoing discussion we had was about the engineering handoff; the existing flow required a lot of manual labor. We worked in conjunction with our frontend engineering teams to create a more standardized, dynamic process. Our vision was that any small design change could quickly propagate to all of our applications with minimal need for extensive communication.
I experimented first with Zeplin. Previously, I had worked with a Zeplin and Sketch workflow, and thought it would adapt nicely for our use case; however, Zeplin wasn't very well integrated with Figma at the time and the handoff process did not see much improvement. Instead, I looked toward Figma's native capabilities in their "Code" tab — it was more similar than I had anticipated to Zeplin. Due to time constraints and other projects, we left this particular discussion at this stage for the remainder of my internship.
Each component had multiple states — what happens when I want to mock something with a hover state? How will the engineers in charge of the frontend library know what the hover state is? For this (and many other variable pieces like icons), I used the power of Figma's nested components. Nested components allowed each UI pattern to be dynamic and flexible, and each state (hover, active, disabled, focus, etc.) could be built into the layers of an individual component. I referenced this article by Thomas Lowry frequently as I built.
I was also very stubborn about not wanting users of the library to have to "unlink" each component from the master library to properly customize them. If each component had to be unlinked, then any changes to the master component would not reflect in their mockups, effectively diminishing the purpose of having a master library. I made it a personal goal to make every component as responsive, resizable, and reusable as possible.
I accomplished this with a combination of some incredibly powerful Figma features — between constraints, grids, and nested frames & components, about 95% of the system was fully customizable without the need to sever the connection to the master library.
By the end of my internship, the "atoms" and "molecules" had been built into the component library in full. The most frequently used "organism" UI patterns had also been integrated into the library and demo. Many more complex patterns could be built by mixing and matching.
The visual design team began integrating these components into their daily workflow. Some of my biggest challenges came from understanding how components were used on the platform as well as how the visual designers build them, then integrating this thinking into my system designs.
I learned a good deal about systematically creating a reliable and reusable design system. Moving forward the team's primary objectives were to work further with our developers to implement the visual redesign in a streamlined, scalable way. Regretfully, my internship came to a close at this point and I was unable to accompany them in the next stages!
If you're interested, you can check out the demo file in Figma.Peruse the Demo File