10 lessons learned building SumUp’s design system
How hard can it be?
So many teams start out thinking a design system will help solve a lot of the challenges they face while scaling development and design teams: consistency, efficiency, re-inventing the wheel.
While a design system is a modern and scalable way to address these kinds of issues, there are a lot of lessons to be learned from what introducing a design system looks like on paper — and what it looks like in production.
We started working on our design system at SumUp in January 2018.
Our goal was to introduce a scalable way to harmonize the experience across multiple frontend applications and amplify developer and designer productivity.
…all while simultaneously performing both a rebranding and a technical migration from Angular to React.
It was an ambitious project.
In the meantime, our team grew from 3 to over 15 frontend engineers and the number of cross-functional teams using the system multiplied as well.
Over a year and a half later, we finally feel ready to label our design system, called Circuit UI, version 1.0. We still have a lot of work ahead of us, and big plans for version 2.0, but we’ve also learned a lot along the way that we think is worth sharing.
Here are the key learnings from some of the designers and developers who helped us reach this important milestone.
1. “Making the design system part of your business requirements is key”
My biggest learning is it’s extremely hard to balance the amount of effort you can put into the design system versus feature development. Most of the time when building such a solution, you still want to actively work on new features, not totally halt development. This is especially true if you are doing this while being part of a team that builds product features, and not part of a dedicated “Design System” initiative.
My advice is to avoid handling the design system as a side project, because it’s important for people to understand that a design system is a constant part of product development too. By ensuring everyone is on board and understands the value of such a tool, it’s way easier to push the design system forward in smaller increments, and even fit it into your regular release/delivery cycles, such as a sprint.
This is one of the secrets for a healthy growth.
— Fernando (@fernando_fleury)
2. “Take the time to get it right”
One of the things I enjoyed the most about building Circuit UI was the opportunity to do in-depth research for each component. I learned so much about obscure HTML elements, weird CSS quirks, best practices for accessibility, and good API design. Now when we use the components in an application, we can feel confident that the component displays consistently across browsers, is keyboard and screen-reader accessible, and generally works well.
However, building these benefits into the component library is often not enough. Let’s take accessibility as an example, as it’s a topic that is particularly close to my heart. Often a user of the component library has to take extra steps to ensure that components remain accessible when integrated together in an application. A good component library makes it easy to do the right thing through good API design and education in documentation.
When you build your own component library, make sure you take the time to get it right. The initial investment might seem high, but it will pay off manifold over time.
— Connor (@connor_baer)
3. “Creating the design system is only the beginning”
Probably my biggest take away from building out our design system is that creating the system itself is only the first step. The harder part is actually applying it to an existing codebases, especially if the design system is also introducing a redesign and changing frameworks like it was for us. That makes it more challenging to adopt gradually, and slowed down the process a lot.
On the flip side, the benefit was that when we finished, we had a very clean setup in the application: both on the technical side and the UI side. Introducing a design system was an effective and systematic way for us to revamp our biggest application from top to bottom.
— Monica (@monicalent)
4. “Deciding what belongs to the design system can be challenging”
Being a part of a product company means constantly working on new and exciting features. This inevitably leads to teams reusing existing components of the design system or building new ones. During feature development we were sometimes struggling with deciding if the super cool component we are implementing should live in Circuit UI or not.
My takeaway is that when it comes to this, it is really important to communicate with the rest of the team and involve people from design as soon as possible to assess if the component could turn into a UI pattern in your design system.
Of course, this could slow you down and be a bit stressful, especially if you are on a deadline.
But at the end of the day, UI consistency is a key factor in product development so you should do your best to help people from business and other stakeholders understand that investing more time in making a component generic could be really helpful in the future.
— Mariela (@marielakas)
5. “Having a design system will not solve all your consistency problems”
One of the most direct benefits of having a design system is to gain consistency throughout the user experience. However, during Circuit UI’s development, we still experienced some of the same issues that justified its creation in the first place.
For instance, having two developers/designers working on the same new component or discovering areas that weren’t originally covered by the design system (one example from our side is iconography).
This led us to reflect that consistency is a never-ending mission. We need to continuously push our behavior and shape processes that allow visibility and ensure that we are pushing the best possible experience for us, as designers and developers, and for our merchants.
— João (@joaovictortg)
6. “Efficiency is the most tangible benefit of the design system approach”
After our design system was available as a beta version, I started to create a new application with Circuit UI and this opportunity showed me the benefits of having it in our lives.
For example, our product designer was using only the components of the design system and this meant he could create the first prototypes of our application very quickly.
When I started the implementation, I was able to worry more about the business logic than making sure all components will have the right CSS. In one day, we were able to build our first “login” screen and deploy it. The only thing I needed to think about was how to make the page interact with existing components.
This opportunity makes everyone feels more confident about the components and focus more on about the value we deliver to our merchants. Of course, sometimes we find out we need new components in Circuit UI because of new cases that appear in our new project!
And this is related to our first learning: we need to start working on our requirements and consider creating new components for Circuit UI (and not only our project) so we can enable more people to benefit from the new components we create.
— Herbert (@herberth3nrique)
7. “The strong sense of community made us stronger”
One of the greatest things about working on Circuit UI was the collaboration with great designers and developers from all over the world. In the beginning, I couldn’t even imagine the number of lessons and knowledge I would gather from people with different backgrounds, expertise, ideas, and styles.
Circuit UI became much more than a design system, it became a community where we could share experiences, new ideas, learn from each other and become better engineers and designers.
I truly believe that our team became stronger when working together on something that would benefit not just us, but the whole community.
— Afonso (@kdsopasir)
8. “Design systems are the living, breathing part of the collaboration between design and development”
You want a fig tree. You buy some seeds and you put a lot of care into making that baby grow. After weeks and months (How long do fig trees take?) of TLC you have your beautiful, leafy child and you’re proud as punch. Then you ignore it. You start growing new plants that need more attention and you forget about that once beautiful fig tree in the corner of the room.
The fig tree is your design system.
Our job, as designers & developers, is to keep the design system proper, healthy and up to date. It’s not a full time job (yet) but it takes meaningful time and effort to maintain the dream of a consistent experience throughout our platforms.
— Matt (@majahoughton)
9. “Onboard new comers to the design system as soon as possible”
As more developers join our team, it is important for the new team members to spend time familiarizing themselves with the design system in detail and getting to know its capabilities and limitations from the start. Having this tool in your pocket can be a huge timesaver and being able to use it with certainty makes developers more productive.
To facilitate the “getting to know the design system” phase, well-written, up-to-date and detailed documentation certainly is a plus. Communicating clearly when a change is about to be implemented is also a big part of it.
Having an open discussion about potential improvements helps get everyone involved and invested in the project.
— Iva
10. “Even the biggest changes can and should be delivered in increments”
We started work on Circuit UI because we knew we needed a more consistent way to design and deliver our products. A design system and an implementation in React seemed like a great fit. We also knew we were a team of three frontend engineers in all of SumUp at the time. So how do you create a component library from scratch and rewrite the entire frontend using it? Short answer: you do not, at least not with a team this size.
But what do you do instead?
You come up with a plan to do it incrementally.
We started with a limited set of components, only what we knew we would need. The rest was added as we rewrote or created other products. We had a simple bash script that would generate some boilerplate files so creating new components would be quick. Nowadays we have a complete CLI with support for different types of components. When we started using Circuit UI in our web products we installed it as a dependency from GitHub. A build was added much later. Circuit UI still does not have working static CSS extraction. We only built a proof of concept because we knew we might need it down the road.
The point here is: if you want to make big changes with a small team, you have to find ways to do so incrementally so people can continue quickly and continuously deliver value to users.
The amazing thing I learned over the last year is that this actually works. It feels slow. Sometimes it is painful because you know you could do so much more.
But you just put one foot in front of the other and after some time, when looking back, you realize you have made it incredibly far.
— Felix (@feju)
Does working on Circuit UI sound like something you’d enjoy?
We’re hiring both engineers who will build and maintain our design system as part of our new Web Platform team, as well as product designers who will use and extend the system.
Check out our open roles for:
- Web Architect (Berlin)
- Senior Frontend Engineers (Web Platform) (Berlin)
- Product Designers (São Paulo, Berlin, Sofia)
Follow us on twitter @SumUpEng for future updates!
