Building (and Maintaining) a Design System
Coming up with a consistent design system is quite a challenge in itself. Add more designers or even multiple teams and locations into the mix and it becomes more of a headache. And that’s not even taking into account the vast amount of design tools and the preferences of each individual designer.
“If you want to go fast, go alone; if you want to go far, bring others.”
At car2go, the product design team consists of six people across two locations: one manager, one UX researcher and one web designer in Stuttgart as well as three app designers in Hamburg. While this setup is very small compared to other successful design teams, it can still be a struggle to speak the same visual language, even within one platform. Over time, though, we managed to come up with an efficient design system that works well for us. Needless to say, getting to where we are now required a lot of time and iteration. And this isn’t even its final form.
The Heart of Our Workflow
Sketch is the centerpiece of our design process and where most of the magic happens. Not only do we use the tool for illustrations and screen designs, but also for wireframes. We tried dedicated wireframing tools like Axure or Balsamiq in past but eventually always found Sketch to be most efficient.
Abstract for Version Control
Another essential and relatively new part of our workflow is Abstract. In short, it’s version control for Sketch files which makes working in a team incredibly efficient and makes sure you don’t mess up your files. The coolest thing for us are the shared libraries that Abstract introduced with one of the latest updates. It’s basically a Sketch file which contains all your type styles, icons and UI templates and you can be linked to any other Sketch file in your Abstract team. It’s amazing! To ensure high quality (and not break anything), every merge has to be approved by at least one more team member. Sounds a bit like a developer workflow, doesn’t it?
Our master project—which includes all the screens we have—actually consists of multiple Sketch files to ensure a modular system. In our experience, performance, maintainability and integration with other tools is much better this way than storing all the screens in a single file.
Zeplin for Smooth Handover
Providing screens and assets is happening via Zeplin. As a designer, you can easily import your Sketch files there. As a developer, you can easily download the assets in the format you need. It’s a win-win situation and huge time-saver for everyone really. Generally, it just makes the handover highlyflawless and efficient. And it gives our product owners an overview of every detail of the story that will be implemented.
Bringing things to life with Framer
On some occasions, we also do small prototypes to preview and evaluate our designs or to simply try an animation. For this, we’ve tried a number of tools but ultimately stuck with Framer. Since you can wactual code, it gives you a lot more freedom to implement depth and logic where other prototyping tools reach their limit.
So we’re done now, right?
The current setup works reasonably well for us. Due to our design library (which we will introduce in more detail in another article), we’re able to produce designs very quickly and hand it over to the developers fairly easy.
But since the design world is changing quickly, it will affect our workflow as well. With the recent announcement of InVision Studio, our toolbox and workflow might be shaken up. Not only could it replace Sketch, but also Zeplin and Framer since InVision itself already has a big ecosystem of design tools. It has to be thoroughly tested, though, if it really is a suitable tool for us.
All in all, a design system is never complete and will always require plenty of iteration—including of course wrong turns. In the end, there’s no one-size-fits-all solution. Every team needs to figure out what works best for them on their own and the setup might need revision from time to time.