Birth of our new design system-Part2
Who is it for and why?
This is the second post in our “Qubole Design System” series. Check out Part 1 here.
In the first part, we discussed about why we need a design system. Now, let’s look at what to do with a design system, who is it for, and how do we sell it.
Are you worried that your specifications didn’t get translated into the perfect pixel? Is that button of the right color and at the right place?
Designers need to be at the top of their game when it comes to making sure that their work is not diluted in the implementation phase.
Design Systems allow products to scale rapidly through effective inter/intra team collaboration and reduced time to market while maintaining quality and consistent user experience. This article from here on will help you successfully productionalize a design system. I will also dive deep into the process of creating a design system, from ideation to implementation.
What is a System?
A set of principles or procedures according to which something is done; an organized scheme or method.
Extending the above definition to the design world brings us the amazing concept of Design System.
What is a Design System?
A Design System is like a mysterious hero.
We know we need it, we know we want it, we know it’s important, but we don’t know how to use it as a tool and what it is supposed to solve.
Design System is like a gym, everyone wants to go but not everyone ends up going.
When you check online, there are so many things written about the design system and it can get overwhelming! Let’s break it all down to smaller bits for easy understanding.
Here are a couple of quotes from around the web,
“The complete set of design standards, documentation, and principle, along with the toolkit (UI Patterns and Code Components) to achieve those standards.” by Uxpin
“Design System is essentially a collection of rules, constraints, and principles, implemented in design and code. These 3 attributes serve distinct functions and provide coherent systematic order in systems from buttons to single page applications.” by Usemuzli
A bit of research on the internet will give you ample examples of how others have worked out their design systems. Let’s take a look at a few of them below.
MailChimp
MailChimp used a design system to formalize their communication and how they write their content. A design system just to do this! How many of us have ever really thought of having a design system for voice and tone?
Material Design
A visual language that synthesizes the classic principles of good design with the innovation of technology and science.
Looking at the above examples, you can see how they both are basically design systems but are used to solve different things. In the case of MailChimp, they simply wanted to standardize the copy that they are using throughout the product, right from the marketing team to the product team. Whereas, in Material Design, they talk more about the visual behavior that the product needs to support in an end-to-end product building cycle, around documenting the end-to-end UI Guidelines.
Understand your pain points by finding your Villain
In our case, there were 3 villains that we wanted to tackle.
1. Inconsistency
We got a lot of feedback about inconsistency in UI and since there were parallel products under one roof, we wanted all of them to look similar and follow same Visual language, and inherit most of the things from different parts of the product.
2. Inefficiency
We were in a situation where the design and dev teams were spending too much time on reinventing the wheel, which led to inefficient use of time and resources.
3. Collaboration
Our team has been spread across different geo-locations and we sometimes saw slight variations of the same components. So, there was a lack of a single source of truth, and we were having a hard time creating a set of similar looking deliverables.
Do you face the above-listed issues? If the answer is yes, then you definitely need a design system and we’re glad to present what we did, which we hope will help your product as well.
Now, Characterize your Hero
Now since you know all the pain points and have a wide understanding about why you need a design system, and what are the goals or metrics that you want to achieve, it’s time to shape your Design System character and write it’s value proposition, and what your design system is going to solve.
We call our design system Space. Here is a small proposition quote or summarization of what our design system solves for us:
Qubole provides enterprise-grade solutions to big data problems across engines and multiple platforms for varied personas.
To cater to such a large audience and different use cases, we have faced the challenge of reducing complexity and providing a cutting edge user experience.
As we grow further, it becomes necessary to minimize complexity and enhance intuitiveness.
Space, as the name suggests, is conceptualized with the aim to add space to the complexities to designing for such complex workflows.
The purpose of this design system is to provide uniform set of guidelines for all varied interfaces of Qubole. Space is designed with the mission of adding breath of fresh air to the everyday UI, turning even a mundane task to a delight for Qubole’s customer. — #quboledesignteam
Get things moving — Start Selling your Idea to a Producer
Once you identify the needs, the next logical step is to get buy-in from all the stakeholders in your org. This is crucial and can be run parallel to the regular product roadmap. Giving assurance on keeping the rest of the things on track is key!
Who should you sell this to?
- People with Budget
- People with Authority
- People in Need
People with Budget are those who help you get the resources. It could be leads in the product team or people making decisions on investing resources or budget to get things done.
People with Authority are the people who are managers of different teams who can help you evangelize the idea of design system within the team and help you take a fly within there particular teams.
People in Need are the folks whom you are building this for, the design and dev friends in your company. If you can sell your design system to them, then you have successfully sent an adaptability note throughout the company.
Here are some ideas about how you can sell a Design System to different sets of people:
How do you sell it to the business stakeholders?
Show them how a design system will add value to the product by fixing the below issues, and corroborate it with actual findings,
a. Customers frustrated on being asked to behave differently on different platforms,
b. Project timelines getting affected or even dropped just because there’s always a developer who’ll say ‘this will take very long to build’ and so on.
These are the folks who have the budget and authority and can arrange resources as required for you to move things forward.
How to sell your Design System to your dev team?
We had seen that our devs spent a lot of time in refactoring code for each component, every time it’s written. This is a threat to the productivity of any org that wants to ship features on a regular basis. Our goal was to make them more productive.
So, a design system would
1. Help in setting up reusable components, so they don’t have to be reviewed each time they’re written
2. Any change done on a particular element should change it across all the products
3. Less time to figure out how to implement a design
4. Consistency across all front end teams
How to sell your Design System to your design team?
Irrespective of the team size, whether on the same table or on different geo-locations, a design system will help in creating consistent designs.
The gradual growth of design system = gradual decline in inconsistency + gradual increase in the speed of software development (by UXpin)
That’s all for this article! I’ll be back with the third and final part of the series, where we’ll look into how to create processes, operationalize, and come up with your own Design System.
