While it’s rare that building a thing in the most correct way also gives the fastest result, at bitcrowd we’ve achieved exactly this by building our clients’ component libraries on a solid design system. As a bonus, even backend developers get totally on board with what used to be seen as a niche design or frontend wish.
What’s a design system?
They were seen as something that only the largest companies with a big brand to protect would invest time into. If you follow design blogs you may be familiar with PR-packed breakdowns of the philosophy behind a new logo, the color branding, and typographic styles of some corporation.
The documents these corporations publish for their internal staff are called styleguides. In some ways, it’s the kernel of a design system.
Designers specify the colors, with lighter and darker variations, that are allowed in branded materials. They specify which of those colors may be used for a highlighted background color, which for borders, and which for text. A typographic scale shows which font with specific font-size and line-height is to be used for headings of different levels, and which for body text or footnotes.
For business documents with mainly text content, that’s maybe as far as you need to go. For interactive products like a web application, these specifications form the basis of a set of UI components like buttons, dropdown menus, and modals. This is a component library, built on top of a design system.
The component library (sometimes called a UI library) lives in your UI design software such as Sketch, Figma, or Penpot. Unlike Photoshop, these apps are laser-focused on building UIs composed of encapsulated components. They also mimic the layout mechanisms and CSS properties available in web technologies, and make this information directly available to developers, which really speeds up implementation time and increases quality.
How is this fast?
Building designs in the same way that you implement components in the frontend sounds like a lot of extra work. We could just not do and instead get straight to designing, implementing each new design as it comes. That must be faster!
For the very smallest products, maybe it is, in the short term. If it’s a product you want to see have a long life, this is not an approach you should take beyond the prototype stage. The time saved when building screens using structured and well-architected components quickly overrides the up-front cost of implementing them.
What’s the FE story?
When building the components in the frontend, implement them as they’re organised in the designs, following the structure, and using the same design tokens. If you have designs for a card component with three different variants of color or size, implement a card component with exactly those variants. Render the component in a structured component library, showcasing each of its variants.
This component library is an environment isolated from the logic of the app. It’s organised and documented to aid product owners, designers, and developers, in finding components and the information they need. Just through the process of rendering the components in this simplified and isolated environment, we get components that are less interwoven with the app and with each other. This means simpler and more reuable components.
Which component library software we use is dependent on which tech stack the components are implemented in. Commonly for JS-rendered components we use Storybook. This is currently the big player in the space, that all others copy. It has a big extension ecosystem that makes building great UI easier. For Elixir Phoenix we use phoenix_storybook, and for ViewComponents, Lookbook.
Building components in a library like these means you can directly compare them to the components in your designs. For every component and variant in the designs, there’s a viewable and clickable example of the live component, right there in your browser.
Having a direct 1-to-1 comparison to the designs makes it more straightforward for the developers and designers to QA the components. The goal is that given a component in your designs looks as you need it to, that component will look the same in the live product. This increased self-assessment and the feedback loop created between the designers and developers really raises the bar in UI quality, and vastly improves the developer experience when using your components.
Keeping the backend happy
Styleguides, design systems, and component libraries all used to get pushback from backend teams. There was a feeling that they were extra work for little payoff, increasing the dependencies and the maintenance burden, and perhaps even that they were a somewhat frivolous request from “design types” that shouldn’t be taken too seriously.
Perhaps the mindset of backenders has shifted, or the convergence of UI design software, frontend component library software, and CSS layout power has hit a sweet spot. In my experience, backend teams are now often very receptive to organising components this way.
With a component library and the well-structured components they engender, backenders are able to find out which UI components are available, and get example code that they can copy/paste and edit to fit their needs. Views and templates that would formerly be cluttered with HTML and boilerplate layout classes are now composed of a limited set of clear and understandable components. The names and usage of these components is consistent and quickly-learned, making UI work a lot less fraught than it used to be.
The result is that backend developers that maybe don’t have a designer’s eye, or lack the specialist knowledge of building accessible and usable UIs, can safely put together a page from scratch. This saves time because you’re not doing work twice, and PR reviews are quicker. For your frontend team it means they can work on other things, like making refinments and adding polish they didn’t have the time to do before.
Backenders get to feel good about building new views from the components, and not be worried about knowing exactly what the current accessibility best practices are, or which classes need to be applied to which elements to match the designs. Building new UI can even be satisfying when it doesn’t bring critical frontenders into your PR mentions.
Closing the loop
No loop is ever finished; by definition they continue forever. There will always be more feedback from either developers, designers, or the product team. Like all tasks in a ticketing system, there’s no end. The big improvement of designer to developer workflows using design systems and component library software is that giving feedback and implementing improvements has less friction than ever.
Our goal is to create a feedback loop that is more actionable and auditable. With this, we can improve the workflow for designers and developers, and give our users a better experience.