Design Systems Sprint 0: The Silver Bullet of Product Development.
A brief introduction: I’m Marcin: a former UX manager and now co-founder and CEO at UXPin — the full stack UX design platform. In this series of posts, I’m reporting on UXPin’s journey of creating our own design system. We’re starting by discussing the fundamentals of design systems (why? what?) and then we’re moving sprint, by sprint, through the entire process of building and maintaining a complete system.
If you’re wondering why or how to build a design system, this series is for you.
Like with every project at UXPin, our design system journey started with a series of user interviews.
Between July and August 2016, I interviewed 40+ enterprise designers, developers and product leaders about their most pressing challenges. I wanted a clearer picture of where design and development was heading. Nothing paints a clearer vision of tomorrow than the pains of today.
While these generative interviews are meant to inform our product roadmap, they also improve our own product development process. That’s an added benefit when you’re working on a platform for design and development teams. We can learn a ton from our own customers.
This time, the end result led us to an unexpected revelation.
Every interview revealed a problem we’d faced ourselves as we grew over the years. A problem so big and powerful that it can cripple product development at feisty startups, weigh down user experience at mid-size companies and completely prevent the scaling of design and development in enterprises.
That problem is the lack of design consistency. The menace of every great product.
Lack of design consistency: the biggest issue in product design?
Design consistency was clearly a prevalent issue. And our interviewees were very vocal about what that meant for their teams and users:
- User confusion. Different patterns responsible for the same action confuse users,
- Slow design process. Lack of reusable design assets slows down designers (‘everything is created from scratch’)
- Slow development. Low number of fully reusable components bogs down development.
- Difficult onboarding. Introducing new designers and developers to an undocumented ‘system’ is impossibly difficult.
We wanted to learn more. We also wanted to validate the findings.
So a couple of weeks after our interviews, we ran a large-scale survey on the state of enterprise design. Of the 3,175 respondents, 59% pointed at ‘improving UX consistency’ as the challenge they currently face in the UX process:
The verdict was unmistakeable: the lack of consistency is constantly on designers’ minds — and rightfully so.
Good design, by its nature, is systematic, yet growth of the team and of processes, unless meticulously managed, inevitably seem to lead to inconsistencies. Karri Saarinen, Lead Designer on Airbnb’s design system, probably put it best:
“Software is often built by incredibly large teams of people. The challenge to create coherent experiences multiplies exponentially as more people are added to the mix. Over time, no matter how consistent or small a team is, different people will contribute new solutions and styles, causing experiences to diverge.”
The more inconsistent the user experience, the slower product development becomes and vice versa. In my past experience as a UX manager in the enterprise, teams unable to identify design standards eventually default to building everything from scratch. And so the situation worsens.
It’s a vicious cycle.
Of course, users suffer the most. A Google Research study from 2012 showed that users prefer simple interfaces, which seem familiar. They seek out experiences consistent with other experiences on the platform. We crave familiarity. Every new pattern responsible for the same action, or visual inconsistency, creates an unnecessary pause and an eventual burden.
Consistency introduces feelings of safety and familiarity. Inconsistency creates chaos and confusion.
Governing the chaos
So how are these teams working to minimize inconsistencies?
Participants of our study were very consistent in their answers: building and maintaining a design system. The enterprise segment (B2B products) of the design market seems to already be there:
69% of enterprises either have a design system or are currently working on one. Companies such as Saleforce, IBM, Airbnb and Atlassian lead the crowd with very mature implementations of living design systems.
It certainly makes sense. At that size and scale, the problem of inconsistency is too painful and expensive to ignore.
Deconstructing design systems
So far in this short post I’ve mentioned the term ‘design system’ over 20 times. So what exactly is a design system? After all, it’s not a self-explanatory term. And it’s easily confused with style guides or UI pattern libraries.
Let’s build our definition off why companies decide to build a design system in the first place.
Design systems increase design consistency and code consistency (every reusable design pattern should have a corresponding reusable piece of code). With a design system, pieces of the system are reusable across multiple parts of a product and even across multiple products.
By approaching product development with a LEGO-like process, we get more time back in our day to focus on bigger product problems. We minimize the redundant conversations and the one-off solutions.
So if this is why companies build systems, than the following can serve as our working definition:
A design system is the architectural core of a product(s) for ensuring design and code consistency and product development efficiency.
It’s a little bit easier to understand if you’d take a look at the typical structure of a design system.
What is a typical structure? To find out, we analyzed 39 publicly available design systems.
Design systems are quite consistent in structure. We definitely see a lot of similarities across different systems. Typically, we have a library of interface patterns with corresponding code references, a definition of high level styling or structural elements (grid, colors, typography) and a set of design principles.
If you’d like to further structurize it, here’s something I found really useful in explaining design systems to others:
The design system is truly a gold standard — from the general building blocks of every piece of design, through the UI patterns, and building up the high-level rules defining the future of the product.
A design system isn’t set in stone however. It should evolve with the product and always reflect the truth.
Building and maintaining a design system is definitely a big challenge, but one worth facing. After all, it can break us out of the vicious cycle of unscalable design. To me, it sounded like a dream — one that we really needed to realize at UXPin.
Design consistency at UXPin: why we really needed a design system
Our own research hit us right in the face. We’ve tried to fight inconsistency in our interface with a set of design principles and rudimentary libraries, but we’d never moved into a full design system.
While I wouldn’t call our experience fractured or completely inconsistent, we definitely had quirks which needed standardizing. Take these primary buttons:
They’re visually different, yet hierarchically identical. Both buttons are responsible for the most important action in a given context. It might seem like a small thing, but great experiences are built out of small things.
After doing some spot-checks of our own product and marking up the inconsistencies, we decided to do a complete audit as part of building out our design system. We needed to build a scaffolding for future product and team growth.
Interestingly enough, a certain modular environment already existed in UXPin. Our development team moved to React.js over a year ago and the web development team started to build and maintain their Less files in a highly structured and modular way.
Meanwhile, design needed to play some catch up. Together with development, we’d need to expand this approach for both disciplines to scale in harmony.
The journey ahead
By the time you’re reading these words, our Design Operations team (led by yours truly) is already multiple sprints ahead. It gives me time to reflect on what we’ve accomplished, so I can share all the hard lessons with you.
Parts of the system already exist, parts are gradually being worked on. Here’s our current roadmap:
In the next post, I’ll share how we created an inventory of UXPin design and how that helped create our design system.
Stay tuned!
Are you looking for all the articles in this series? Here they are:
- Design Systems Sprint 0: The Silver Bullet of Product Development.
- Design Systems Sprint 1: The Interface Inventory
- Design System Sprint 2: One Color Palette to Rule them All
- Design System Sprint 3: Managing the Basics
- Design System Sprint 4: Design Principles
- Design System Sprint 5: Managing Typography
- Design System Sprint 6: The Fastest Icons on Earth
And you’re into more in-depth thoughts on Design Systems:
