Eric Eichbauer | User Experience Designer

OVERVIEW

As I was just starting a new role at Thermo Fisher Scientific (science instruments company), there was global UX initiative to move from one design tool – Sketch, to another – Figma. The group I was under, Genetics, also had a need to build a component library unique to it's products. New to Figma myself, I saw an opportunity to gain expertise in the tool so I volunteered to lead the effort.

Problem
With the amount of digital products and teams Thermo Fisher genetics division has globally, there is a lack of visual and interaction consistency that can have an impact on the brand experience.

Solution
Provide reusable design components and usage documentation for designers and development teams to improve consistency and implementation.

The global (core) UX group had just created a component library in Figma. My group was a satellite brand underneath them. I worked with the global UX group and suggested three types of architecture models for satellite brands with the pros and cons of each. The one I suggested here would have all branding done at the satellite level leaving all components provided at the core level, black and white or brandless.

The core UX group had a brand centered around e-commerce, whereas our needs were product or task based. A button is a simple example of when we needed to deviate aside from just the visual branding. The button supplied at our parent level was 40 px high, but due to our data heavy applications, space economy was always an issue so our button height was 32 px high. Deciding when to break away from our parent group was common challenge.

PROCESS & TEAM

Building the components in Figma was done by me and another designer as a side project over the course of 5 months. We divided the file into three sections – Work in progress, Ready for review, and Completed. I asked the other designers that would use the library to drop screen shots of similar components from their projects into the designated component space. I lead weekly discussions with five other designers and discussed components that were ready for review. I took their feedback and iterated or moved the component to the completed category.

As a group, we did an audit of each component within each of our projects. I would then look at everyone’s needs to determine if a single component could meet all needs. If a project had a particular need that was unique enough or not useful to the rest of the group, that would be a project level effort to build out.

Besides components that would be used in our in product interfaces, I thought it would be useful to add complimentary components like sticky notes and a wireframe kit. I was happy to see that the notes were adopted by the team and took notice that our parent group built a wireframe kit shortly after...hmm, wonder where they got the idea.

SUPPORTING DOCUMENTATION

Once we completed the components, I started to work on supporting documentation that would include Usage guidelines, Examples, and Decision tracking. Similarly to what we did with components, I lead weekly discussions to determine the usage rules around each component. Fun stuff, like should the space between two buttons be 8 px or 12 px. It actually was fun to have these debates and I learned a lot from other's perspectives.

The usage documentation explained what the intent of the component was, basic rules on the components itself, and in common scenarios. All the documentation itself were local components with auto layout applied.

The example documentation was a way to expose the various states of the components that may not be evident when first accessing it.

FINAL THOUGHTS

I very happy to have done this for the knowledge I gained in Figma. I feel very confident with the tool and have since lead small class sessions on the tool for others that are still getting used to it. I lead weekly design critiques and have opened it up to include Figma topics. I'm happy to say that the component library has been adopted and implemented into our group but will always be a work in progress.