Design as more than just guideline/artwork in UI/UX development
Tags: designsystem, figma, ui, development
Published: 2023-10-09 12:41:30

UI development can be tough with many open questions: component libraries, component organization, testing, style reusability...
In this post I'll guide you through an approach we used on latest project I've been working on. I'll use React as code snippets, but this should stand for any library/framework that supports composition of UI components.

**Me**:
Looking at a new design hand-off
![Info Table component design](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8ls69f3zfprw70lw0asj.png)

_"Aah InfoTable I know this one, we already have it in our library... A border? Do we need a variant for this border around it, where did the label above come from? Why are you always making things hard?"_

**Smug designer**:
_"There's no new stuff here. The border and title come from `Section` component which wraps the InfoTable in this case.
Sections are already used elsewhere, we just did not combine it with the table yet. If you click on it in Figma it will show this on the left side. More clicky clicky less thinky thinky."_

**Me**:
_"That's great!"_ Chugs coffee mug at designer's head to hear the clicky sound.

```tsx
export const InfoTableSample = () => {
  return (
    <SectionContainer>
      <SectionTitle left={<SectionTitleText>Info Table Sample</SectionTitleText>} />
      <SectionContainerContent>
        <InfoTable>
          <InfoRow
            left={<InfoRowLeft>Rate</InfoRowLeft>}
            right={<InfoRowRight onClick={action('onClick')}>$1 = 0.91 EUR</InfoRowRight>}
          />
          <InfoRow
            left={
              <InfoRowLeft>
                INO fee (0.3%)
                <InfoTooltip tooltip='lorem ipsum' />
              </InfoRowLeft>
            }
            right={<InfoRowRight onClick={action('onClick')}>$4,19</InfoRowRight>}
          />
          <InfoRow
            left={<InfoRowLeft>Yo momma's weight</InfoRowLeft>}
            right={<InfoRowRight variant='error'>StackOverflowError</InfoRowRight>}
          />
        </InfoTable>
      </SectionContainerContent>
    </SectionContainer>
  );
};
```

## More than guidelines

Designers were fed up from hearing their stuff being referred to as artwork and guidelines. To make their work more resemble technical spec, design decided to own the components and compositions. This means they were the ones to come up with UI component names and how they compose into larger components. Similar like the InfoTable example above.
We followed the [Atomic Design Methodology](https://atomicdesign.bradfrost.com/chapter-2/). UI consisted of:
- **Atoms**, smallest pieces of UI (Button, Label, TextInput, Tag)
- **Molecules**, larger pieces combined mostly out of atoms (Navigation Item, Portfolio List Item, Section, Select Currency...)
- **Organisms**, large components that make the page (Navigation, DashboardWidget, Info Table...)
- **Templates**, shallow layout components which handle placement of passed components.
- **Pages**, instances of Templates using exact organisms passed to templates.

Arguably this makes sense. If product and design are in fore-front of feature discovery, knowing which components are there and how they combine should improve feature discovery experience. Development on the other hand can focus on lower level technical details that are not relevant for design.

## Design Tokens

To improve workflow we started using [design token studio figma plugin](https://www.figma.com/community/plugin/843461159747178978/tokens-studio-for-figma-figma-tokens).
Design tokens are a collection of style values that can be reused across the design system. We used 3 layers of tokens:
`core tokens` -> `semantic tokens` -> `component tokens`. Similar to how it is [explained here](https://bootcamp.uxdesign.cc/what-are-design-tokens-828c67410069). Tokens were used for spacing, colors, typographies, borders, shadows...

Token studio can export tokens as JSON. This was a huge win for UI development. Devs did not need to maintain the theme anymore. We could just take the JSON directly from design and make CSS variables out of it during build time. This was _:mind-blowing:_! We could remove the mess of colors, shadows, typographies that was scattered all over in theme files in code.

Once the generated tokens were in place styling components with Typescript was like connecting dots:

![How to use design tokens](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6q5vy46dj5p1qxubtsd6.gif)

## New workflow

![UI Development workflow](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/18iew4x6uyk2wwzwzezs.png)

Under the hood UI team has to maintain [Storybook](https://storybook.js.org/docs/react/get-started/whats-a-story) and [Vanilla extract](https://vanilla-extract.style/documentation/styling/) in our case. Vanilla extract is great for this use case as it generates a CSS in build time from type safe Typescript code. This reduces JS runtime speeding up initial load time for apps.

## Final words

After introducing design tokens and detailed design hand-offs UI development became the least mental stress position. Process was surprisingly smooth.

Design was pleased because they didn't get any more design-guidelines/artwork talk and were more integrated into the development.

What is your design-development workflow? Do you use similar process?

I omitted details like component libraries for brevity. Let me know if you are interested, I'll do a follow up.