A lean, scrappy approach to developing a design system
Learn how Josh Baron of Dell brings consistency and speed to one of the world’s largest digital enterprises.
Design Diaries is our ongoing series featuring conversations with design leaders from some of the world’s most innovative companies.
Josh Baron has been a senior principal product designer at Dell since July 2018. Josh is helping the technology giant adopt a lean-startup approach to build its design system quickly and cost effectively. In this interview, Josh talks about the challenges of design consistency in a worldwide operation and how Dell's system has married design and development to drive better efficiency.
Design Diaries is our ongoing series featuring thought-provoking and candid conversations with design leaders and luminaries about the future of design.
What’s it like to work at Dell? How would you describe the company’s culture?
Dell uses a balanced team approach. It’s kind of part of our digital transformation — and believe me, I know that phrase is cliché at this point — but we have this concept of a balanced team where designers, developers and product managers work together on the same team. It’s a very product-focused and problem-solving focused team.
Why did Dell develop a design system?
In a company this size, you have a lot of different digital applications owned by a lot of different teams. If you don’t have a firm set of design and development guidelines, then your digital products can seem like the Wild West.
At Dell, our designers and developers kept recreating the same UI components over and over, which wasted lots of time. We also had a lack of consistency between different digital products and even within those products.
My team did a root-cause analysis that included interviews with designers and developers. We found out they were often silent, isolated and unaware of UI components that other teams were building, so they kept rebuilding components and didn’t always know the proper specifications. After a lot of brainstorming, testing and synthesizing our data, we decided we needed a design system with a website documenting our principles. I’m also building UI kits and evangelizing the system.
What’s the primary role of the design system?
We need a reliable platform that creates consistency across all of Dell’s digital experiences and digital assets. That will make the creation process easier, faster and more scalable, which is crucial because we’re a global company and the traffic to our digital products is enormous.
We want designers to stay focused on the user’s journey through our digital products. They shouldn’t have to worry about little things like, “oh, what was the padding in the primary button on the left and right, versus the top and bottom?” And we don’t want developers retyping the code to create a button, carousel or accordion every time they build something.
A design system helps as long as it has those consistent code and UI components.
How is your design system driving results for Dell?
We’re in the early pilot phase of our design system now, so we have a long way to go.
We have met some skepticism. But when we sat down with a few developers and let them use it on a sales app they were building, they found they could build a page of their application in a week that used to take several weeks. That success triggered more interest and less hesitancy to adopt the design system.
What does it take to get leaders to fund a design system?
First, you identify the problem, like inconsistency or inefficiency, and you communicate that to management. We used the lean-startup/MVP (minimum viable product) approach to show we could put something together really fast on a very low budget. When you get a product into the hands of users, start getting feedback and iterating on it, you start to produce success stories that show value to management. When leaders see that value, they’re more likely to give more budget for a bigger initiative.
What have you learned about design systems through this process?
You need a system that meets everyone’s needs, but designers want a system for designers and developers want a system for developers. Both sides tend to forget the other one exists. It’s really important to recognize that a design system is a marriage of design and development. It’s not just for designers, and it’s not just for developers.
A design system also raises tough questions of governance. How do you add components to it? Who determines what gets added and what doesn’t, and what gets changed? We had a committee to answer these questions, but some people felt like it was the design police. We’re still trying to figure out the right process. The design system can’t be a bottleneck.
What’s your advice for implementing a design system in a large organization?
A lean UX strategy can get something in front of a small number of users, iterate based on their feedback and then eventually open it to a wider audience. You don’t necessarily want to say “hey, the design system’s done and here it is.” The MVP approach is to work out problems without causing detrimental side effects to the whole company. Once you’re more confident that the system works, you can start introducing it to more people.
What are some of the pitfalls around communicating and collaborating within a design system?
Once you have a design system with UI kits and guidelines, your coding and components will become a critical piece of every digital product you make. You have to make sure you have policies for support and maintenance in case there’s an error in the coding.
One of our core tenets is trust, so we have a bug tracker and other ways to communicate as much as possible to people without overwhelming them. For now, we’re being very cautious about the people we tell about our design system because we don’t want to open the floodgates of user feedback before we have systems in place to handle it.
What’s one of the biggest lessons you’ve learned from working on this project?
Every company is different. Go out and look at what other companies have done. Just make sure you talk to the designers and the developers who actually use the system. See what their actual problems are and figure out how you can solve that for your company.