Saying the design team in Zalando has grown in the last few years would be an understatement: it has exploded, jumping from around 10 to over 40 designers in an 18-month period. With this comes many challenges, one of which is making sure our interfaces stay coherent and cohesive, no matter who designed or coded it.
Dress Code is a pattern library and style guide created by the Brand Solutions Central Services team to address these issues in the scope of Zalando’s Solution Center – a central repository where our business partners find everything they need to work with the Zalando Platform. In this article, we’ll talk about style guides, why we needed one, how we created it, and how it’s helped multiple teams on top of it going above and beyond its original scope.
What’s a style guide and why use one?
In the context of User Interfaces, a style guide is a set of components -- from basic building blocks such as typefaces, shapes and colors all the way to more complex ones such as buttons, images, and menus, including their interaction and behaviour -- that allows one or more websites to maintain a sense of branding, unity, and coherence. Using a style guide brings different benefits to different kinds of people involved with the website.
From a user experience perspective, the main advantage of a unified design style across related websites and applications is that users can keep using the same mental model; they don’t need to learn a new interface language every time they open a new app or site. This reduces cognitive load, and helps users be more efficient and feel more confident during their usage of an app or website.
Developers strive to solve difficult problems, develop efficient algorithms and write quality code. They shouldn’t need to reinvent the wheel each and every time they build something. A style guide with reusable components gets design idiosyncrasies and details out of their way. They simply reuse the components of the style guide and focus on assembling them to solve a greater challenge.
There are two phases to design: one is exploratory, where it pays off to play around and be creative; the other is production, where it pays off to be straightforward and repetitive. Having a style guide affects both these phases: it sets positive constraints for the first and speeds up the second.
A design system for autonomous teams
Zalando’s Solution Center was started back in 2014 with the idea of creating a unified hub where our business partners can find all the tools they need to work with Zalando. Professionals from brands, retailers and other partners can use several web applications to help them in their daily tasks, such as publishing content, advertising, asset management, managing orders, and much more.
At around the same time, Zalando Tech launched a new way of working and organizational structure where small product teams of around 5-10 people work autonomously, and have full ownership of their project and product.
Creating and growing a hub like the Solution Center under Radical Agility meant that the multiple web applications within it would be designed by different designers and developed by different development teams, each of which might be using completely different technologies.
Before Dress Code
In the beginning, the Solution Center started with two interconnected applications -- Brand CMS and Brand Analytics -- which were built by two different teams. Together, the UX and UI designers in each team agreed upon common UI patterns and a common look and feel.
While this might seem enough, it meant that every change or update made by one team had to be communicated back to the designers and developers of the other team, to ensure consistency.
To improve this situation, Tom Nägele, one of the designers, created a simple style guide based on Fabricator. This was then made available internally to the teams so they could check if their UI matched the reference. Still, this meant Tom had to tell people whenever he had updated the guide, and they had to manually change their code to match Tom’s guide.
At this point, work was starting on another application and on the Solution Center portal itself, which would better connect all the applications. Were the teams to continue the process used at the time, they would each create their own version of the interface components, on their own codebase, all over again. This would bring the total implementations of the same components to four.
This is when the idea of having a centralized, deployable style guide started to be taken seriously.
Our first idea was to go for a components API, inspired by Lonely Planet’s Rizzo. However, we soon realized this wouldn’t fit our use case as each different team might be working with different technologies – one team might be using Angular 1, the other Angular 2, while the third might be using React.
With the help of very dedicated Frontend Engineer Ruben Barilani, we decided to integrate Tom’s demo library directly into his production code so he could stay on top of any changes.
For maximum tech compatibility, we kept Dress Code itself as a set of SCSS files that could be imported, customized and built by each team, no matter what their technology choice was.
Dress Code was then transferred to GitHub, first as a private repository on GitHub Enterprise. Using tools like npm and gulp to set up a build system, Ruben made it easy for other developers to link Dress Code into their workflows, making sure they would always get the latest Dress Code files in their own development environment.
Once deployed to GitHub, Dress Code quickly became a collaborative, distributed project. New features came at a quick pace. Tom pushed for organizing the elements into Atoms and Molecules, following Brad Frost’s Atomic Design Principle. We all worked on refactoring much of the SCSS to adhere strictly to BEM conventions. Sambhav Gore, a new Frontend Engineer who had just joined Zalando, developed a responsive grid system based on flexbox. I designed new components, new icons and improved the existing ones.
Currently, Dress Code is used by around a dozen different teams at Zalando, building products for businesses and employees – and the list keeps growing. Contributions from new people are showing up more and more often.
We’ve had pull requests from the Advertising Team, the Customer Benefits Team, the Merchant Center team, and others. Even teams whose products will not be integrated into the Solution Center -- our original scope for Dress Code -- have started using it as a starting point for their standalone projects.
And those are only the internal teams -- since the project is available to anyone with a GitHub account, many other people may use it in their own projects.
Find me on Twitter at @gabrielhl for feedback and questions – I'd love to hear from you.