Birth of our new design system-Part1
#quboledesignteam is embedded into persona specific verticals. We are responsible to cater to the needs of the people we are designing for while also looking at the larger picture — the platform as a whole.
Ok, this is how most of the design teams intend to function. But do we spend enough time tackling the issues faced by the people we are designing for? Or are we overwhelmed by just fighting design inconsistencies?
As a team, we wanted to spend more time on the former, but to get there, we had to get the design inconsistencies grown over the years out of our way.
So how did a product being technologically so strong with the best of architectures behind its curtains, with various developments over the years, get so inconsistent with itself on the outside?
The answer was simple — it lacked a common design language, and it was visibly obvious for anyone using it.
Because of the lack of a common language and each team on a different version of the UI stack/design evolution created silos. Even though we did sync regularly as a design team, and the philosophy persisted, the specifics differed at the atom and molecule level.
So, after 7 years of existence with an expanding engineering and design teams in different locations, and after a few futile attempts at creating better designs, the need to introduce a new design language at Qubole was evident.
We started by gathering user feedback which was specific to the design of our platform:
- “Qubole is a good set of tools, but it doesn’t feel like a product.”
- “It’s complex.”
- “The UI is not appealing”
Hence we embarked on the journey of building a design system with the understanding that the product not only needed a redesign but also a new way to build them. We started by defining goals for the project:
- The design system needed to be easily scalable, reusable, adaptable across various development teams, as the product grows.
- Achieve consistency across different teams.
- Make our visual design modern for a more delightful experience.
- Modularity in building each component.
Close the gap between design and engineering by automating components, so as to increase the productivity of both the teams.
By setting these values we had also realized that we were going to disrupt the way things get built here. But what made it easier for us to battle this was that the internal teams building our product understood the values of having a unified system. We just didn’t have one!
Aligning our thoughts
We started out by creating mood boards to study how visuals can be designed to reflect our product’s capabilities. It helped us set the tone, appeal and various other elements that add to the overall look. Here’s a couple of explorations:
The design cycle
It all started with what should we build first?
With a whole gamut of things to consider in the process, we decided to split it into chunks within the team than asking one designer to take a top-down approach. The idea was to cover more ground in less time. So every designer had a set of interface elements to come up with and use them to redesign some of our critical pages.
By working on these individual blocks, we had achieved a level of consistency at the atom and molecule level with which we were able to sync, iterate and unify styles across verticals. At this point, we built a visual library that was carefully crafted in such a way that things were still customizable but without deviating from the styles originally designed and shipped it to every designer’s toolkit.
Using elements from this library automatically made us more productive by not allowing us to spend too much time in finding references to that “ideal” design element and the urge to toy around with it every time.
Finally, the shift we envisioned:
Once our designs finally felt like they belonged to the same product, we started involving other stakeholders in our design reviews and we noticed our conversations slowly shift towards our users, than just picking on design details. This was the birth of our new Qubole Design System — Space!
This is the first post in our “Qubole Design System” series. In our future posts, we’ll talk in detail about the process, learnings, growth of our design language, the adaptation of it in recent projects and more. If you have questions for us, let us know in the comment section below.
Thanks to Girish Krishna, Ankita Gautam and Kumar Mayank for helping me in the journey of building my first design system.
