Designed for Growth
Technology companies are expected to move at an incredible pace, and building software is complex.
Alex Schleifer, VP of Design at Airbnb, wrote those words in his article, The Way We Build. It’s a wonderful read of how Airbnb rethought their approach to design.
At Etsy, we had a similar revelation. Understanding how to design in a way that anticipates the inevitable future of change requires a paradigm shift in the way we design.
Dealing with Debt
As tech companies grow and age you begin to feel the debt you’re acquiring, not financial debt, but technical and design debt. Debt is acquired by building for the short-term. The interest accrued is the amount of time to manage, repair, rewrite, and build upon the poorly written and designed code.
Design debt is acquired by design teams creating non-reusable solutions for isolated problems. Design debt is made up of an over abundance of non-reusable and inconsistent styles, treatments, and interactions and the interest is the impossible task of their management and modification.
We have seen our design debt impact usability and performance of our site. Inconsistent interface conventions hinder usability, the CSS for those unique interface elements increases page weight, and conflicting CSS creates a QA nightmare.
It also greatly slows us down.
Below is a diff of Jessica Harllee’s work when updating the styling of buttons on etsy.com. The red is the code deleted and the green is the code written. Entirely too much code was touched in order to make a simple visual change.
The act of creation is not what builds debt. It’s the creation of non-reusable code and designs that adds to debt. But when you build things to be reusable you’re effectively creating a system. And systems is what we’ve found to be the best way to manage our design debt.
Like so many other companies, we created a Design Systems team. The mission of this team is to build systems and experiences that express Etsy’s brand in a creative and usable way. But prior to the creation of this team, which isn’t even a year old yet, our system was built and maintained by a group of lovely volunteers led by a few designers from our Seller Experience team. This work was in addition to the volunteers’ other projects and things progressed, but slowly. After a period of time we decided to form a team dedicated to our systems full-time. Thus the Design Systems team was born. We now have toolkits for web, iOS, Android, and email.
What we call a toolkit some others call a style guide or pattern library, but it is a resource of reusable UI components designers and front-end engineers use to create any number of design solutions. Many teams have built systems and made them public to inspire and educate. The Etsy toolkits aren’t public yet, but we hope to make them public in the not so distant future.
In future posts we’ll dive more deeply into our toolkits, but here’s a few tricks we’ve employed to keep our web toolkit flexible without losing consistency in conventions or aesthetics.
Atomic Design is a book written by Brad Frost. The concept challenges you to think of your UI in its most elemental forms or “atoms.” The atoms can be assembled in any number of ways to create anything. This keeps consistency while allowing flexibility for any use case.
Object Oriented CSS or OOCSS changes how you write your CSS. In theory, it is similar to Atomic Design. It’s a flexible solution for writing minimal but reusable CSS. It has two main principles: separate structure from theme and containers from content.
Sass variables are a fantastic way to keep your CSS manageable. Instead of repeating the hex for a color in 1,000 different classes, you add a variable in those 1,000 classes and the variable references a hex written in one place. This makes modifying really easy.
Design Tokens add another layer of abstraction to make variables easy to modify. Instead of using a variable like $orange to add color to a button, you use a design token like $primary-button-background. Then in a separate tokens file, $primary-button-background references $orange and $orange references the color hex.
All Design is Systems Design
Convention over configuration is an engineering term that is also applicable to design. By yielding to the conventions of the system, decision-making is focused on things like information architecture and user flows. We don’t want our design team re-solving the same design problems over and over again. This is wasted time. We want them to focus on the unique challenges of their projects. The system should provide the necessary conventions to solve the recurring design problems.
But what happens when the system is found lacking and configuration is needed? This is the paradigm shift.
Instead of creating more custom solutions, which adds to our debt, create solutions to be fed back into the system. If everything we create uses the system or feeds back into it then all design becomes systems design.
The Design Systems team is the caretaker of our toolkits but it is not a walled garden. All our designers are expected and empowered to contribute to our toolkits, making them more adequate and robust. The best work of our Design Systems team is advocating for the use of our toolkits, educating teams on its benefits, and ultimately cultivating a design systems mental model throughout our entire company.
The benefits of being debt free
Though we are very far from being free from design debt, we’ve already felt the benefits from the work that’s been done. Over the summer we redesigned our convos tool that allows buyers and sellers to communicate with each other. It was an ancient tool that had multiple desktop and mobile web templates that used different code with different design treatments. The redesign was entirely built using our web toolkit. It’s responsive, accessible, and consistent–all benefits inherited for free from our toolkit. It was also incredibly fast to build. From kick-off to launch, it took 8 weeks to redesign and rebuild the product.
Debt is a weight around your neck. Its existence cost time, resources, and risk which prevents quality products from being built at a timely pace. By having a system, and yielding to it, we’re able to move more quickly and build better products.