September 9, 2024

Your UI Sucks and You Are Wrong—You DO Need a Design System

How do you scale the UI for your product when the code is spread across different repos, using various technologies that aren’t compatible with each other?

In a previous role, I worked at a mid-sized company where the UI was built using Angular, React, .NET MVC, .NET Web Forms, Telerik UI, jQuery UI, KnockoutJS, and a mix of custom CSS and jQuery plugins accumulated over 15 years. Most features were tightly coupled.

I suspect many codebases that have been around for a while look something like this. I’d even go so far as to say that FAANG codebases might be no different. It’s a mess, and solving it is tough because a rewrite would be extremely expensive in an already competitive market where your major competition is lightyears ahead. Most SaaS companies aren’t engineering-driven. While they have engineering departments, it’s seen as a necessary function, not the core offering of the business.

It’s easy to imagine this scenario and realize there’s no consistent user experience across features. Implementing a new user experience requires writing the same UI code over and over, leading to inconsistencies, bugs, and rework. It’s also likely that most small to mid-size companies hire mostly full-stack developers who lack deep UI expertise. In the short term, this might seem efficient, but it eventually leads to diminishing returns, and the deeper they go with this model, the bigger the tech debt hole they dig.

How do we solve it?

A rewrite isn’t an option, and there’s likely neither the will nor investment from the board. Remember, most software companies don’t view themselves as engineering-driven; they see engineering as necessary but not their core strength. In my opinion, the solution is a Design System.

I’ve noticed through many online interactions with designers and front-end engineers that there’s a misconception about what a design system should be. There are many beautiful systems built in public, but that’s not what I’m talking about. When I say a design system, I mean the simplest version that solves your organization’s UI and user experience challenges. Of course, if you have the resources and leadership support, you can go for a more robust, open-source version.

Adopting an open-source design system

If you’re starting fresh or your tech stack isn’t as complex as the one I described earlier, adopting an existing system might be a good option. If your entire codebase is a single-page application (SPA) built on React, there won’t be many issues adopting something flexible for your team and brand.

But that’s not the case for the scenario I described. If you find yourself in that situation, you’ll know what I mean. If you have to descope UI features that would improve the user experience, then you have a problem with your tools.

Start small and build on that. Real agile.

You need a design system, and starting one isn’t the big, expensive ordeal it’s made out to be. It can be, but it doesn’t have to. Start by identifying your requirements and constraints. In the tech stack I mentioned earlier, your system needs to be compatible across different technologies. You likely don’t have a dedicated roadmap for it, so it needs to start small, prioritizing reusable UI elements that fit into the existing development process. Another constraint: you can’t rewrite legacy code.

So how do you do it?

Here’s what my team and I did to solve our issue. It wasn’t fixed overnight, but it put us on the right path:

  1. We started by creating an inventory of our UI. Brad Frost, author of Atomic Design, suggests collecting screenshots of all the UI component variations you can find.
  2. Identify the technology each component is built on.
  3. Find an approach that will give you the broadest support and early wins. In other words, what are you going to build, and with what technology?

You don’t need to start with a full component library before you can use it. Think simpler. Start by building a set of design tokens as CSS variables to be shared. This small step will normalize your brand across the product, and it’s compatible with any stack

In our case, we took a hybrid approach. Given the diversity of our UI, we decided to build our own UI components using Web Components. To ensure compatibility across our stack, we chose Stencil JS, a web component compiler built by the Ionic team. It allows you to create web components that can be integrated with any framework. We didn’t start by building every component we thought we needed. Instead, we began with a button—something simple yet essential, with all the variations we needed across the system.

With each new feature, we added additional components that were high priority.

This approach worked for us. I’m not suggesting it’s the solution for everyone.

I don’t know your challenges. We had the front-end expertise to build this kind of solution. It solved many of our UI compatibility issues across applications. You can start smaller—by writing reusable CSS, for example, and later integrating it with components. Find your path.

Your UI sucks, and you need a design system.

Let me know your thoughts. Have you worked on a similar solution? How would you approach it differently?

For more follow me on X @TheJoseFromSJ.