Over 600 changes are being pushed daily to Wix's codebase. How can we make sure that Wix still feels like Wix while maintaining our development velocity? The answer is “Design Systems”.
Listen to Asaf Yonay and Liron Cohen explain more on organizing order out of chaos.
You can also listen to this episode on Apple podcast, Spotify, Google or on Wix Engineering site. And you can also read the full episode here:
Hi and welcome to the Wix Engineering Podcast, I’m Ran Levi.
INTRO: COORDINATION
140,000 people work at Google. 150,000 work at Apple. That’s more than the populations of half of the United States’ capital cities. It’s about as many people as live in Greenland, Lichtenstein, and Monaco, combined, plus thousands more. That makes for a lot of divisions, groups, and teams, a lot of different people, each with their own unique ideas, preferences and habits. And yet, in the end, Google has to feel like Google, no matter what page you’re on or what you’re using it for. Every bit of your iPhone has to make sense, and it has to align with the design and functionality of your Macbook and your iPad too. How is this possible?
The answer is “design systems.” Design systems are how we organize order out of chaos.
But they’re a bit complex. So let’s start with a very simple hypothetical.
Asaf: My name is Asaf. I’m leading the Components group inside Wix.
Asaf is a design systems expert.
Asaf: So let’s imagine, we’re both in a team or in different teams, and I’m working on a dropdown.
Two dev teams, one dropdown menu.
Asaf: And I want it that when a user hovers over the dropdown, the entire Options menu opens up, and then they can select whatever they want. And then I implement it and users are getting used to that experience. But then Team B moves in and decides that the hover experience is not good enough. They want to make sure that the user clicks on the dropdown - and then the Options menu opens up.
Team B implements their change. Users who got used to hovering now have to click.
Asaf: The same system that looks and feels the same, it’s still Wix, but in the end, a user has to now adopt a new behavior. And they don’t really understand why - it looks the same, but it doesn’t feel the same.
The example Asaf is giving here may seem very minor. It is minor, granted. But it’s annoying. Too many little discrepancies in a user’s experience can make a website frustrating and unintuitive, and, really, just weird. It no longer feels right. So users start to go away.
#1: GROWING COMPANIES
Every software company needs to provide a consistent, quality user experience across their products and services. Generally speaking, though, there are two kinds of companies that need a lot of help in doing so.
Liron: Hi, I’m Liron. I’m leading the Design Systems group within Components.
A few years ago, Liron Cohen was working at a startup.
Liron: A different company than Wix, a much smaller one, but one that grew rapidly in terms of scale - we’re talking about growth from 30 developers to over 200 in less than three years.
Growing like this requires some fundamental restructuring. 30 people can work closely together to build, say, a software application. One person takes care of this, a few people take care of that and, when conflicts crop up, you talk it out. Everyone, after all, is working from the same small office. But when you have 200 people? That’s a different kind of company altogether.
Liron: Putting everybody on the same team is not feasible, therefore you split them into separate teams. And therefore, you have to start allowing them to work in parallel on the same system.
Now, suddenly, the company needs to coordinate projects at multiple levels: among the members of each individual team and among each team within the company. But it’s easy for miscommunications, errors and conflicts to arise when there are so many variables at play.
Liron: Every time we face a new challenge, it’s suddenly OK, who is now owning this shared code that everybody started to use? And then who is taking more feature requests? And then who is going to really develop that feature request? Do we contribute it as an open source model? Or do we dedicate the design of the component team just for that?
A lot of time was wasted over these kinds of logistical issues. Perhaps it was a failure of leadership. A startup growing faster than it knows how. An established company wouldn’t have this kind of problem--they’ve got things figured out. Right?
Soon Liron left his startup, and joined one of those larger, more established companies that knew what it was doing.
Liron: I’m coming to Wix after that period of time, and I see exactly the same thing happening - just on a different scale, on a different timeline, on a different magnitude.
#2: LARGE COMPANIES
Like growing startups, large companies can run into problems delivering consistent quality software to customers, because coordinating between devs and dev teams is such a challenge at this scale. Wix, for example, has 5,000 employees working across seven countries on four continents. Imagine all the miscommunication, all the variation that could arise if everybody isn’t all pointed in the same direction.
Interviewer: How many people and how many different teams in general does it take to get a software product from an idea to launch?
Liron: I think that it really depends on the type of the project. Some projects are purely product-oriented, where you really have a specific goal that you want to reach, a value you want to provide your customers. That can go form one, two teams on the smaller ones, to four or five teams on the bigger ones.
Asaf: With big projects in Wix, we saw involvement of about 50 to 60 frontend developers at once.
Liron: However, you have some type of projects where sometimes you need to do a horizontal change to a technology or to a way of work. And these types of projects sometimes involve the whole company, like really the whole company, even when it’s a company as big as Wix.
When four or five teams, 50 or 60 developers, an entire company are all working on the same thing, the final product is going to have all kinds of discrepancies and clashing ideas and glitches--one team doing hover dropdown menus and the other doing click dropdowns, and probably much worse than that. No cohesion.
SOLUTION: DESIGN SYSTEMS
Asaf and Liron are the buck that stops this from ever happening.
Liron: We are that unifying unit, the one that by design needs to look at the whole picture and make sure that decisions that have been made in teams that we collaborate with correlate to each other, in order for the user to get a good experience.
Asaf and Liron are the ones coordinating Teams A and B and C and D and so on--all those thousands of developers, in order to build more consistent software across Wix in a more efficient manner. They do this using a design system.
Asaf: Design system comprises two moving parts. The first one is the UX guidelines, the core and the mind behind the understanding of what is the language you want users to experience in a specific platform and specific area of your product.
What should it be like, from the user’s perspective, to interact with the company’s software? UX guidelines determine the look and feel that’s characteristic to Apple products, or Wix services.
Asaf: And that usually is accompanied by the second part, which is a component library. That is where you write the code. This is where you implement the restrictions and capabilities that you want accessible for developers that are using those components. And using the component library, you basically build entire projects that adhere to your design system.
Components are prefabricated pieces of code that developers can use to help build what they’re building. Code for a button, for example, that somebody else has already written for you.
Asaf: We want those pieces, those UX pieces, to build a puzzle that’s very reusable. You, as a developer, can come and create a button that someone else created and you’re sure that it’s robust and that it adheres to the design system, that it makes sense to the user. So basically, it’s reusable components that have a theme.
As an analogy, think of Legos.
UX guidelines for Legos would define the nature of the blocks--their look and feel, how different blocks interlock with one another, the kinds of things you can do with them.
Now, have you ever had one of those themed Lego sets? Harry Potter, Star Wars? The unique pieces that come in those sets are like components. So whereas with an ordinary Lego set you might build just about anything--there is no structure, it’s all your own imagination--the themed sets lead you in a certain direction so that your final product looks extra Harry Potter or Star Wars-y.
That’s design systems.
CHALLENGES
If you’re running a growing startup or a large company, this kind of thing might sound useful. For one thing, it can help your developers build faster and more efficiently. UX guidelines provide a roadmap for all their new projects, and a components library removes the need to program every little detail into a new product or feature. Even more importantly, by giving all developers the same guidelines and the same components, a design system can ensure consistency and quality across all your company’s products and services.
But actually building out such a system is its own challenge, as Asaf and Liron faced when they did it at Wix.
Arguably the greatest challenge to design systems is building out the component library.
UX guidelines, after all, are just guidelines. A set of instructions, rules for developers to abide by. This aspect of our websites should go like this, and that other thing needs to be like that. It’s not simple or easy to create these guidelines, but Asaf and Liron and their teammates could do it on their own.
A component library, on the other hand, requires a massive amount of time and input from as many developers as humanly possible. A library is only a library if it has lots of content within it--components for buttons, for dropdowns, for every little thing. And who’s going to build all that? The design systems team can’t do it on their own.
Asaf: And so the initial concept and the initial buy-in of the company as a whole to the design system is not something easy, because the value is not immediate. When you begin working on that then you start contributing, you’re basically asking people to contribute even the smallest pieces, or pieces that they don’t think will be reusable.
Developers have to contribute to a project that isn’t necessarily their direct responsibility, all the while thinking in a characteristically different kind of way. It’s a lot to ask.
Liron: We understand from the get go that it’s not easy.
Asaf: You can’t train everyone to be a design system expert. You can’t expect everyone to build components in the same open mindedness that we try to train our own developers to. So the Meta of expertise becomes more and more prominent. And when you’ve just started, you’re making a lot of mistakes.
You need to think about the bigger picture. You need to make sure that the component is not only tailored to do one specific thing, but to also serve someone else. Again, if you’re creating a button, then you want to make sure that the button doesn’t just serve the specific UI that you’re working on right now. That it can also be adopted and changed just a bit to make sure it solves other issues in other products - but it’s still the same button that the developer doesn’t need to develop from scratch.
Liron: I will just add up to that, to those aspects that Asaf mentioned the fact that developers eventually work in a certain ecosystem, certain way, certain style, and now they’re being asked to go to different place, and nobody likes to go somewhere else, where they’re already used to a certain pattern. And so that’s naturally something that brings some kinds of friction. And in order to attend that, if you’re already going to manage a design system, you need to take that into consideration with peripheral services that will ease that friction for developers.
And I’m talking about a lot of documentation, a lot of examples, a playground that the developers can play with, a good Slack channel with high availability for questions - everything that surrounds the dev experience of our users.
A design system is essentially its own service, where the customers are the developers at your company. That creates a characteristically different kind of relationship between Asaf and Liron and their colleagues.
Asaf: You need to adopt a support mentality, I think that’s the key. When you understand that, basically, your users are now developers inside the company, which all have the same goal, then you need to find the balance between making sure that the standards are right, and everything is working as you expect, and to also be empathic and understand that they are here for their own reason. They want to create the best product in the market. And I think that empathy and knowing when to be adamant about things that are important for the design systems, as opposed to when to let go a bit.
Over time, hopefully, more and more developers come into the fold, take on the design systems mentality, and the project begins to reap rewards.
Asaf: It takes, I think, a few iterations on the product itself to make sure that you do get some value. So this is one of the biggest hurdles that you get when you start a new design system in any field.
And then, over time, when the design system matures, then you see more and more usability, you see more and more value, because more and more products become aligned.
At Wix, the evolution has been obvious.
Asaf: When someone comes to us for a review and we look at the very big project and they say, “Oh, I estimate it will take me about a month or two.”, and then we strip away all of the needs to create their own components (because we have them in our design system and they just need to build the flows and deal with the product problems and not the creation of components), then we drastically reduce the amount of time they need to develop.
SUCCESS
As the value in the design system becomes apparent to everyone, it encourages more developers and teams to buy in.
Liron: We even see some winning success stories in the form of teams that early on in the beginning saw this concept and completely ejected out of it and didn’t want to work with us because they were afraid of that gradual evolution that the design system will have to go in order to serve them well.
However, now after showing such a proving offering of components in a service, so we see them coming back and requesting actually to onboard on the design system, and asking how we can start and what should we do in order to realize our project over the design system.
Asaf: When I look at the platforms that are using the design system and I feel like we have a coherent experience, this is for me a very big win. Because I know just how many people are working on those, how many contributions are being done daily to this platform, to our design system, and still to see it all function as one unit - I think this is one of the key goals inside any design system.
Liron: So that really gives us a good confidence that we’re heading in the right direction.
That’s it for this episode, thank you for listening. For a full list of our previous episodes, visit https://wix.engineering/podcast. The Wix Engineering podcast is produced by PI Media, written by Nate Nelson, produced by Yotam Halachmi and narrated and edited by me, Ran Levi. Special thanks to Moard Stern from Wix. See you in the next episode, bye bye.
For more engineering updates and insights:
Join our Telegram channel
Visit us on GitHub
Subscribe to our YouTube channel