<- Index

How I created a design system that doesn’t generate more work

Designers love to design. That’s what we’re good at! When tasked with creating a design system, we go off to infinity. Of course, we need ten shades of lilac and twelve shades of green. We need fonts, colors, buttons, inputs, tables, calendars, chips, tags, illustrations, guidelines... The list goes on and on.

But let’s go back for a minute. What is the reason we need a design system?

Is it because of the lack of consistency? Then, these endless choices won’t help.

Is it because it is too much work to design features from scratch? Supporting a large design system won’t necessarily weaken your workload.

Maybe you’re going for a design system for better communication between design and development. But reading a wordy manual about each of those 15-button variants won’t make it easier for devs.

Most companies would be better off with a minimal design system that answers most of the hard questions but leaves room for creativity when it comes to specific features.

That’s what we did at CFT. CFT is a medium-sized fintech enterprise. We build systems and tools for banks in the CIS region. We have a lot of SaaS B2B products, most of which are web apps.

We had all the problems I mentioned: lack of consistency, long iterations, and suboptimal handoff process. Let’s explore how we changed the situation for the better.

I joined one of the teams as their first designer in 2019. After just a few weeks, it was obvious that the processes in place could be significantly improved.

I started by discovering what caused the shortcomings. I found out that the company already had a repo with UI kit code, but it was abandoned and not used in recent projects. Most of the design work was done by a separate team of designers. They were jumping from project to project and did not have time to focus on them.

Next, I talked to front-end engineers. They were excited by the idea of not figuring out new design logic for every new app.

My solution was to put together a system that is easy enough to learn and use. Next, I needed to promote it to as many people as possible: internal workshops, 1-on-1s with product owners, and online webinars for colleagues from different cities. I offered my time and resources to anyone who considered trying the system for their product.

But what about the system being easy to use? First of all, if you’re building something minimalistic, it won’t be as flexible as a more generic solution. It had to be pretty opinionated when it comes to the basic layout, navigation, and even some of the smaller components. Sharing these design ideas between projects means we can refine our approach based on the experience of multiple teams.

I partnered with our design director to work on this project to better understand company values, processes, and legacy. Most of the products used some version of Google’s Material Design for their apps. We decided to reuse some of the Material patterns to avoid needing our customers to learn everything from scratch. After all, Material Design is a good place to start.

I did research and looked at a lot of released and unreleased projects. The goal was to identify the critical building blocks we absolutely must have. I also did a quick-paced review of UX standards and patterns. It would be nice to spot easy-to-fix obsolete patterns to fix then by introducing a ready-to-use solution.

The results of this research were not unexpected but still quite interesting. The primary outcome was not a list of things to build but rather a list of things not to build.

My favorite example of the latter is a date picker. I initially designed it but did not include it in any of the Javascript libraries. Why no date picker? Our clients deal with a lot of data and use the keyboard to fill in the forms nearly 100% of the time. Focusing on perfect keyboard input for dates, document ids, and card numbers was more important than spending time building a decent date picker.

This approach worked out for us well. If you look at the design system code repos on GitHub, you’ll see that the last release was over a year ago. It looks like the project is unmaintained, right? In fact, we keep building new projects on top of the system, and the system doesn’t need to be updated.

Figuring out the exact reasons why you need a tool, doing the research phase to tighten the scope, taking responsibility by making the calls, and most importantly, talking to people will leave you with outstanding results.

Do you have experience with design systems and want to discuss creating a sustainable design system? Feel free to drop me an email. I appreciate any feedback.

<- Back to index