PacX Design System

Introduce a thorough, extensible design system for our enterprise and consumer platforms — incorporating current elements and introducing robust, connected components.

Project Description

Rework, expand, and document Paciolan’s design system. The existing design system only included the bare minimum, was not well documented, and didn’t have a coded counterpart. Paciolan needed a comprehensive strategy for how to write new a system of themed react components into its current product and then how to eventually update to the new look at feel.

Goals

• Create a Figma library of the current design components so we can continue to maintain Enterprise pages with their current look and feel

• Create an updated Figma library with a new design system for the future look and feel for Enterprise and Consumer

• Work closely with development to grow a react library made up of themes to support both look & feels and begin their usage across development teams and introduce it into the Consumer product.

Building Our Library Components

First Steps

My first step was to convert the existing libraries to Figma to meet the design teams need as we transitioned from Sketch. The components needed to be expanded to make the design system workable for ongoing projects and documented so we were consistent with usages and patterns.

Strategy

In our Figma library, very component starts with an atom and each variant built for that component is based on that atom. The thinking here is that in doing this we create better maintainability. If ever a change needs to be made to the component, instead of having to replicate that change in each variant, you can simply update the atom and each variant accepts the change at once. I made this decision pretty early in the building process and I would say it has served us well, but it does have a few Pros and Cons.

Pros

• Easier changes and updates, one change will reflect in all variants

• Theming and consistency is also easier

• There is one central point of truth for the component, this is very useful for very robust components with a lot of states like inputs.

Cons

• It can be more difficult to select a variant in use. Using the cmd+click shortcut should select the lowest level component, but when atoms are in place, the shortcut selects it instead of the primary component. Easy enough to get around once aware, but can be a small inefficiency in a designers workflow.

• Components are inherently more complex because the atom is designed to encompass all situations

• There will almost always be hidden layers within

Here is an example of a more simple components atom and variants. All the tooltip components in the right image are built with the tooltip atom in the left image as a base:

Here is a 3,000 foot view of the setup for some of our form components. An example of where the atom system is especially useful.

Lastly, here is an example documentation for building and maintaining the library. We include one-sheets for each of our components, documenting rules and usages as well.

The React Components

The Situation

Paciolans software is converting its legacy code to React. As we work on new features and enhance existing ones, the goal is to implement our library of themed React components across all products. The base components are all based on the same code and can key off different themes that we have created for the various products, I’ll call them: Enterprise Current, Enterprise Future, and Consumer Future.

The themes for Enterprise and Consumer Future are very similar (with only a few differentiations based on need) and can be seen below. The theme for Enterprise Current is primarily being used transitionally (see my Transaction Entry project as an example of it’s look and feel). Basically, we needed to include a theme for the current Enterprise look so that we could intentionally switch to the Future theme when enough of the product has been converted to our new components.

Working with Dev

We work closely with dev to make sure the React components are in sync with what’s in our figma libraries. The current process is that the themes used for react components are styled by YAML files that are maintained by the design team. We maintain the different themes and anytime a new component is added, we work with the developer to provide the corresponding styles to each theme file. We thoroughly documented how this process should work as more teams started using these themes and the process continues to evolve as our system becomes more sophisticated.

Challenges

The Figma libraries are established and are relied on by the design team however the themed React components are still new for many of our development teams. It can be a challenge to encourage their usage and shift the mindset across the org. We are continuing to evangelize the benefits of our reusable components and are getting more and more teams on board to work towards the goal of a completely unified product.

Here is an example of some of the initial Zeplin documents the design team provided as we started building these shared components:

PacX Design System

And finally to the fun stuff, right? Check out the future design system look and feel as well as some of the components I built.