ZenBusiness - Design Libraries

Overview

Goal -

Partner with the Senior Manager for UX in continuing to maintain, expand their libraries (Enzo) and usage throughout the organization.

Ongoing Responsibilities

As I joined ZenBusiness as a Staff Product Designer mid-2022, I was asked to take this work on as a part of my responsibilities.

• Primary ask -

  • Working collaboratively with the Senior Manager for the design group, support them in maintaining and growing the library.

    • Identify areas of need in the dashboard.

    • Create responsive versions of components in Figma.

    • Work with engineering leads on developing and maintaining the library.

    • Participate and lead office hour discussions.

• Secondary ask -

  • Grow the library while increasing its usage, influence and direction.

Process

Discover -

As someone new to the organization, I set out to work with the senior manager in understanding the libraries that were currently in use and what those processes were for intake to design to delivery. As this was a relatively new way in thinking about design at the organization, I had a tall task ahead of me. I’d start out by, first, cataloging all of the various libraries and placing them in context of how they fit together.

Define -

On the surface, this system seemed to work well enough. In practice, designers were able to add libraries to their Figma design files through the asset panel to pull in various components for their use. And while designers used them, albeit sparingly in their designs, there continued to be a need for normalized (consistent) components and a better understanding of where, when, and how to use them.

As it relates to current versus deprecated components, there had been some progress in indicating, in the file name, a color coded system (red - deprecated, yellow - in process, and green - live) and appending “(LIVE)” at the end of each file names. This, however, did not indicate that components were finalized (in production).

When a component was design complete (in most cases not “dev complete”), an announcement would be made in the relevant Slack channels to communicate to the design team that it was ready for use.

In summary:

1. We simply were not keeping up with the pace of change at the portfolio level.

   1. Designers were creating bespoke components, often based loosely on components in the library, to solve for their needs.

   2. Bespoke components, by their nature, consisted of custom “one off” code which then created inconsistent experiences in the dashboard. Each portfolio experience would look and interact with the user in unexpected ways.

2. Storybook, the source of truth repository for completed components, was several versions behind the current iteration of the dashboard experience.

   1. Having a single repository for codified components creates value in efficiencies for engineering processes and customer-facing UX.

   2. Components that look and work similarly when a user interacts with them is critical for great experiences.

Share -

Requests for new or changes to existing components was conducted, primarily, through ideation sessions, office hours, and/or direct requests in the relevant Slack channels to either myself or the senior manager.

Design -

Further examination of our libraries showed a disparity of what was currently in production (and Storybook) versus in Figma.

I would set out to locate and prioritize designs for these missing/incomplete components so that our designers would have a component to pull into their designs, enabling consistent experiences for each of the portfolios.

The example above displays the process for an existing global navigation pattern in where I would start at the atomic level (iconography, primary and sub-level categories, labels) to build up to a component (molecule) and the various states for each of our portfolios for light (default) and dark modes.

To solve for issues around availability (what is a component design versus what is in production), I would include a component and leverage a Jira ticket status plugin to capture overall readiness. To ensure that component builds would be considered for prioritization, I would schedule a meeting with our engineering manager and principle engineer to discuss moving component work forward (and into Storybook).

In parallel, I created documentation in ZeroHeight to provide guidance and direction on usage (video below) for design, product managers, and (later) engineering.

• Description

• Usage

• When to use

• Anatomy

• Container

  • Orientation

  • Widths

• Destinations

  • Active indicator

  • Icons

  • Label text

  • Badges

  • Info

• Responsive layout

• Behavior

• Accessibility

Publish -

As mentioned, when a component was design complete, the news would be communicated through library and design Slack channels.

However, in order to realize the potential of the design library and its benefits to the organization from the standpoint of efficiencies and consistent user experiences and expectations, we would need organizational “buy-in” to get the resources we needed to get this effort off the ground. I, as well as my senior manager, had several conversations at the VP level (including the VP of engineering and the VP of product) where we pressed the need to build our library of components to levels sufficient enough that designers would be comfortable enough to using these library components and engineers could access the very latest components in Storybook. In practice, the availability of these finished components in Storybook would create efficiencies and downstream impact.

The ongoing challenge, that I would need to solve would be in convincing our VPs the importance of this work, the need for additional resources and further prioritization of this work.

The Future Roadmap -

Despite the struggles to grow the library and the acceptance by the organization of a broader design system, I had planned out a future roadmap to show how we can improve on the existing model with greater efficiencies in mind. In, largely, keeping to the existing baseline structure, I could move the library work forward without disrupting the flow that our designers had become accustomed to. These improvements would consider scale, simplification of our libraries, and better guidance through documentation.

Tokens (or Variables)

At the start, our design library was focused on speed. As time passed, our library grew in complexity as new components were added. We also saw opportunities to merge native app and web patterns into a single library to provide visibility to component designs/states on separate platforms. Third party partnerships would also begin to take more of a priority increasing the need to manage different design systems for our partnerships. Perhaps, there would be a need in the future for a headless design system. In any case, I needed a better way to organize our design system to enable greater efficiencies.

Enter tokens. Design tokens would enable these efficiencies and become the new foundation for our design system’s visual style. We would replace adjective-based color naming schemes with easy-to-understand names while providing a centralized way to control and update designs. This approach would enable greater efficiencies and scale! With the advent of variables in Figma, we found the opportunity we would need to follow this path.

With the inclusion of primitive (base-color) variables, I was able to introduce massive efficiencies in the way we delivered dark mode variants of components in the library. When mapped correctly to their light mode counterparts, dark mode palettes could be “switched on” as needed, removing the time consuming need to design separate variants and using a boolean logic, as has been done in Figma until the introduction of variables, to switch between them.

With variables, our design process mirrored what our developers had been able to do within the MUI5 framework, reducing lead times in design spec and delivery. Using variables would also allow us the flexibility to globally change colors and/or change our palettes for our 3rd party partners.

Taking variable usage further, I would standardize design output for responsive web accounting for columns, margin, and viewport. In effect, this standardization would eliminate inconsistencies in our comp deliverables to engineering while maintaining consistency in the dashboard.