Birth of our new design system-Part1

Image for post
Image for post

#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.

https://media.giphy.com/media/xTiTnJ3BooiDs8dL7W/giphy.gif

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.

Image for post
Image for post
Image for post
Image for post

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:

Image for post
Image for post

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!

Image for post
Image for post

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.

Qubole Design

Stories from Qubole’s design and research team

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store