Forging a design framework — creating a unified + modular UI framework at a start-up 🏗

Nicholas Vincent-Hill
Forge Engineering
Published in
5 min readApr 1, 2020

To improve our frontend engineering output and ergonomics at Forge we implemented a unified design framework. We’re proud to present our new design framework here.

Why we need unified frontend design

Karri Saarinen, a former Principal Designer at Airbnb, summarizes many of Airbnb’s main priorities for building a universal design system. Here are some of the problems we wanted to address:

  • Standardize UI patterns to improve both design output and code quality (the code and the app should look like it was written by one master engineer/designer)
  • Improve new product features construction, development, and design iteration velocity
  • Create a flexible tool we can iterate on to accomplish our atomic design ambitions 🚀

A unified design language shouldn’t be just a set of static rules and individual atoms; it should be an evolving ecosystem.

Airbnb — “Building a visual language”

Let’s take a look at the nuts and bolts of our solution to these problems.

How did we build it?

Our private package on Github packages

We started by collaborating with our Design team to assemble a bare-minimum list of UI components to implement or refactor/add to the library. After implementing roughly 50 unique components (design atoms or UI molecules) we were able to eliminate the existing Sass from our CRM and market-making internal application; this allowed us to remove MaterialUI as a local dependency and exchange our legacy styling for our new universal design framework.

Here’s the tech we used:

Tech stack

  • TypeScript — Type-safe JavaScript is the top of our full-stack type safety approach to modern ergonomic web development.
  • React.js — The functional front-end framework with hooks (accessing the brand color palette with useTheme, standardized margin and padding with useStyles, sidebar with useSidebar, etc.).
  • Jest — The framework for unit and snapshot testing with Enzyme. All of our design atoms and molecules are snapshot-tested to prevent regressions negatively impacting our users.
  • Github Packages — The package manager and version control.
  • Yalc — The local package development tool.
  • Material-UI — The base UI layer; our design framework is a superset of the Material-UI component library.
  • Docz — The Gatsby.js-based documentation site with interactive MDX-enabled playgrounds. Check it out here.

Here’s an example component in our new design framework which demonstrates our user requirements as well. We provide small atomic components with simple declarative API’s that developers can easily compose into large UI structures/molecules.

Our generic contact information card is a molecule composed from smaller UI ‘atoms’

As a PDE (Product, Design, Engineering) organization, this unified framework allows us to all improve our process in the following ways:

Product

Our product managers are now able to produce high quality mocks without as much hands-on work from our design team. Alternatively they can construct simple wire-frame views of new products/features and feel confidant that the implemented output will be consistent with Forge’s existing product/feature suite.

The example below is a new dashboard feature (a mobile-responsive interactive table view) we were able to sketch, implement, and test in a single two-week sprint due to our existing modular UI library.

A rough wireframe built by product
An MVP implementation using our design framework

Design

Our Design team no longer needs to create high fidelity mocks saving valuable time to create the design vision for our brand and future products/features.

Whenever a new atom/molecule is required Design and Engineering can work together to create a generic reusable solution and add it to the growing library of components — creating a lasting, tested, and documented solution built into the institutional memory of our PDE organization.

We can apply this same iterative process to updating our brand assets, color palette, and/or specific components in the library and have these changes be reflected across all our products and features. This allows our Design team to control the consistent design and palette across all Forge Global applications.

A final benefit from our unified UI — users quickly become familiar with our generic UI patterns and when they encounter a new component they will have an existing intuitive understanding of how that new feature works; we are better able to communicate intent and function quickly and precisely.

Engineering

The third group in our PDE-triumvirate, Engineering benefits through increased workflow efficiency, code quality, and ease of development. We are now able to systematically expand our unified frontend capabilities while responding to new feature requests or design changes.

We can also rigorously practice TDD on small, atomic components and feel confident with them when functionally composed into larger UI structures (a field component in a form in a modal in a flow, etc.).

UI components built with TDD and snapshot testing to ward off regressions

Conclusion

Implementing our design framework has already increased the velocity of our frontend feature development and standardized design patterns across our PDE organization.

The upfront investment in planning, implementation, and coordination between Design, Product, and Engineering is also increasing the speed and ease of onboarding/converting new developers into valuable contributors to our frontend codebase.

We still improving our process (Yalc and MDX don’t offer the greatest developer ergonomics right now) and we continue to add new design atoms and UI molecules to our library daily. Thanks for reading!

Our design framework components in the wild

Nicholas Vincent-Hill is a software engineer at Forge who enjoys building beautiful mobile-first web applications

--

--