Enghouse is made up of a diverse set of products, some of which are native to the company, while others are a part of acquisitions. When I came onboard, one of my primary directives was to create, document and oversee the implementation of the UI design system across the product line-up. This was essential in order to create a unified, consistent user experience across the product portfolio.

Additionally, it would also streamline new product developments if engineering & product teams had an ‘easy-to-consume’ guide in order to build, and test new product features.  

Goals & Objectives

• Build a UI design system for design, product and engineering teams.

• Create a glossary of commonly used terms in products.

• Create a catalog of complex components (Ex: Chat elements, Sign in pages)

• Document how to use and when to use components

Phase One

The initial approach was to scope out and use a common framework / front-end stack across every product. When I came onboard the initial plan was to use Material Design, along with ReactJS. Establishing this area of the development stack would allow the team to create a consumable, ‘single-source-of-truth’ set of components which would live in StorybookJS.

The Pivot - Going 'frame-work agnostic'

After the first set of components were released, we decided to test it with 3 product teams. 

The first team was building a brand new web application, so it was easy to implement the design system. The other two teams tried to make the pivot to the new system, but rewriting the front-end just wasn’t feasible. To completely rewrite the front-end just to adhere to using the new design system just wasn’t worth it.

The goal of having the various products in the company implement and abide by a design system established using a common framework which differed from the existing technologies in their respective stacks just wasn’t going to work. 

By the end of 2023, I made the decision to pivot direction on how to create and implement a company-wide UI design system. The highest priority was not to be limited by a technical stack. As a result of this the UX team designed a library in Figma unbound by any framework. 

Why use a Framework-Agnostic Design System?

Adopting this approach offers several significant benefits, especially for large organizations:

1. Consistency Across Technology Stacks

Instead of maintaining separate component libraries for React, Vue, and Angular, the team primarily maintains a single source of truth for the HTML, CSS, and component behavior. Framework-specific wrappers can then be built on top of this core, reducing the maintenance burden.

It allows different autonomous teams to choose the framework best suited for their specific project while still enforcing a consistent and unified UI/UX across all products, whether they're built in React, Vue, Angular, or even a static site generator.

2. Increased flexibility and reusability

The components can be deployed across a wider variety of platforms, including mobile apps (via technologies like React Native or Flutter), content management systems (CMS), and legacy applications, maximizing the return on investment in the design system.

3. Future-Proofing

It insulates the design system from the rapid evolution and churn of JavaScript frameworks. If a team decides to switch from one framework to another, the core design and UI components remain reusable, reducing the need for costly and time-consuming rewrites.

Phase Two – Complex Components

With the foundational UI system in place, the focus shifted to documenting complex, frequently used components, and their underlying user experience behaviours.

This second phase involved creating a catalog for components (like "Sign-In" screens, chat widgets, and navigation headers etc). By documenting these common patterns, the team aimed to ensure a consistent experience for users, when interacting with different products across the portfolio.

Conclusion

The design system is being successfully, and systematically being integrated in various products at Enghouse.