Choosing a design framework

Designing a UI is hard. Reinventing the wheel each time you need a button adds a tone of technical debt for future maintainers to pay, it also creates inconsistency across your application.

In my experience, the best time to pick a design framework is when you start a new project. The second best time is now. It's similar to a builder who custom builds all their tools for each new house they build, or even for each project they have IN their house! In this post, I’ll go over some reasons as to why it’s so crucial to have a solid design system in place.

Here are some examples of front-end design frameworks that I’d recommend taking a look at. They’re very similar in the problems they solve so I won’t argue which is best, it’s mainly the fact that you have a design framework.

• Tailwind
• Bootstrap
• Material UI

1. Big companies have spent large sums of money on R&D to make their UIs easy to use and to look nice. Having a repository of pre-built components at your fingertips means you can hit the ground running with your new or existing project. You no longer have to write all the logic for how a button operates/looks, simply import it and continue building.

2. Their utility functions / surgical classes are really useful. In bootstrap and tailwind, these are some of the main selling points. Here are some simple examples of what you can do with these frameworks.

Tailwind:

<p className="text-gray-500">{person.email}</p>

Bootstrap:

<span className="text-white-50">{person.email}</span>

Material:

const classes = useStyles();

...

<span className={classes.span}>{person.email}</span>...const 

useStyles = makeStyles((theme) => ({
    span: {
        color: 'rgba(255,255,255,.5)'
    }
}

Why is this useful? There are a few reasons.

• Spacing modifiers provide consistent ways of spacing components in your UI. No more specific pixel margin or padding that makes the UI slightly off at different viewports

• Styling with these utilities becomes faster and faster the more you learn the framework. There will be a bit of a learning curve, but it will pay dividends in a short period.

• The frameworks are usually based on a set REM size, meaning your UI should scale reasonably well when people use different zoom sizes or screens.

• The flex-box utilities are very well documented and make mobile/desktop development EXTREMELY easy. Here’s an example with bootstrap, these three columns will correctly display at any viewport size (within reason).
  

<div class="container">
  <div class="row">
    <div class="col">
      Column
    </div>
    <div class="col">
      Column
    </div>
    <div class="col">
      Column
    </div>
  </div>
</div>

1. Theming is a big thing in these frameworks, just because you pick one doesn’t mean your site now has to look like the base theme. You can add a lot of customization, like primary colours, box-sizing, borders, etc. Most of the frameworks have a tone of documentation on how to do this so I won’t go into it.

2. Mobile AND desktop first. Most of the design frameworks have a bunch of help when it comes to layout. These make it super easy to operate in the mindset of “what does this look like on mobile”. Using things like flex-box and rows/columns are easy to set for different viewports. E.g. making something span 3 columns on desktop but 3 rows on mobile.

3. Firefox or Chrome or Safari? These libraries tend to handle slight differences in browsers and browser standards. Their maintainers will also be constantly checking comparability with a set of standard browsers you may not have the man/women power to do yourself.

4. CSS is a lot harder than people think. I think that’s because the actual hard part is maintenance, not so much adding something in for right now. It gets exponentially harder to manage for each line added to the system. Moving this to the component level means there is a direct link between the functional side and the design side. This means when refactoring components, you won’t be worried about deleting CSS that’s actively used for something else, you’ll just kill the component and the styles will die with it.

OK — adding a design system is all great and all but what about my legacy system stuck in 1990? Never fear, there are some ways to get around this problem.

So the first step would be adding a new repository for your design framework, add the base framework to this and also add storybook. Here you can play around with the themes and try and get some basic components working and looking similar to your existing designs. If you can, package these in a private/public npm package.

If you’re currently not using react / vue / angular you may only be able to leverage the surgical classes provided by the design frameworks. This is still a big win in my opinion but if you then also want to migrate to a new front-end framework I’d look at using a proxy of sorts. Azure frontdoor (or nginx if you’re a nerd like me) is a perfect tool for this migration as it allows you to run your existing system AND new system side by side. Your proxy will just divert traffic to different pages depending on the migration status.

So you have an existing system with the page /contacts. You are looking for this to be the first page you migrate to the new design / functional framework. You’ve used the create-react-app or something similar and added your design library to it and it’s deploying nicely. So far your proxy is diverting ALL traffic to your legacy system. Now you create the /contact page in your new front-end application, get it talking with your existing backend and it’s working nicely. on release day you just need to update the proxy to say — OK, route the /contacts page to the new system, route everything else to the old system. Did it blow up? Just flip it back to the old route. DNS switchovers are still the nicest form of releasing (but that’s probably another topic).

I hope this all made sense, I’ve likely glazed over some harder parts due to me not wanting to write a book but let me know if you’d like clarification on any of the areas. The TL;DR is to get a design system in place, the earlier the better. The time payoff is larger the longer your company is afloat. Developers won’t hate their life maintaining it and feature work will be significantly faster.