(Forge) Bridge over troubled water

Photo by Chris Becker on Unsplash

So how can design and engineering communicate more efficiently to enable rapid development of frontend components?

At Harry’s we wanted to extend this “shared language” of design and code components that helped put handoff in the rear view mirror. Starting with our brand-agnostic library of React components known as “Forge UI”. This consists of many of the common components used across all of our brand websites like Buttons, Badges and Tabs. Because they are brand-agnostic they are un-opinionated on how they are styled and displayed to the user, but they check all the best-practices-boxes: they’re accessible, secure and functional. These components get their styles from a “ThemeProvider” wrapping around the entire page.

<ThemeProvider theme={$theme}>
<ForgeButton>Click me</ForgeButton>
The color picker component styled in three different themes. This component allows the designer to specify whether the color label should be displayed, the type style and color, the padding between the label and the color targets, the spacing between the colors, the color chip height and width, the color and width of the “selected state” indicator, and the radius of the color chip (square, round or anything in between). Even space between the color and selected state outline can be specified!

Where does the brand theme come from?

The design team specifies styles and properties in a Figma-based “Brand Starter Kit”, which includes all of the designs for each component and all of their respective variants. Variants are an awesome way for a brand to have multiple styles of a single component (think “Primary” button, “Secondary” button, etc.). A designer can change how an accordion component looks on different pages just by using different variants (for example, one variant may have a grey background which opens with an icon on the top left, while another may use an off-white background which opens using an icon on the top right).

colors: { map of available colors and ranges },
typography: { available typographic styles },
components: {
button: {
variants: {
'default': {
backgroundColor: 'rgba(0,0,0,0.5)',
...other properties...
...other component definitions...

How are the variants specified?

When building a new component for the plugin, the design and engineering teams decide what style properties can be changed between variants. A component definition is created within the theme provider package detailing the properties and we run a script to generate typings for the plugin to pick up.

displayName: 'MyNewComponent',
properties: {
state: ['normal', 'disabled'],
styles: {
typography: {
displayName: 'Typography',
backgroundColor: {
displayName: 'Background Color',
The Forge Bridge plugin showing properties that can be changed for the button component
The blue areas represent “inherited” properties, while the orange is an override for the selected variant

So what has this solved?

By working together to define the styling properties, designers and engineers develop a common language for describing a component’s parts. Typically teams have different words for the same thing; are the words near a text box a “Label” or a “Hint”? Is the component we are working on called a “Hero”, a “Module”, “Banner” or even a “Full width image”? By creating components and defining properties collaboratively, the shared language adds value well beyond the process of creating the component itself.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store