Introducing Solv bud-e’s new design system.

All new bud-e’s design language system (DLS) to create a simple, smooth, and amazing experience.

Say Hi to Solv! bud-e’s in-house design system that we’ve built from the ground up. It’s not just a design system for us, but more than that it helps us provide a new and enhanced experience for our users using the bud-e app.

Let’s take a deeper look at how we built and scaled Solv.

The Problem:

In the beginning, We designed a decentralized system that allowed us to innovate and experiment. This gave us the power to introduce innovative design patterns.

But here are some of the problems this approach caused –

• Customer confusion — Different patterns or components responsible for the same action confuse customers. One of the major problems we were facing was that a lot of features and components were not in sync with each other in terms of UI and UX. This happened because all these parts of the apps were designed at different times, having different contexts. There was no unifying design philosophy or principles to guide them.
• Slow design and development process — A lack of reusable design assets slows down designers and developers as the elements must be created from scratch.
• Onboarding difficulties — The onboarding of new designers and developers is an unexciting process, and does in fact become more time-consuming with elaborate training.

Today, bud-e is a platform and we’re introducing bud-e’s features at lightning speed. This kind of scale puts our designer, developer, and product teams under tremendous pressure.

All our products were created under tight deadlines to deliver what our users needed. This meant the designers & developers didn’t have the time to sync with each other and keep things consistent.

So, We needed to fix this.

The big question was:

As bud-e’s products scale, the landscape of users that we design for also evolves. With over 4000 rides happening a day, how can we ensure an easy collaboration between designers, and developers and also a positive, reliable experience for customers?

The solution was:

In order to optimize our designs and bring consistency across all our products, we decided to create a design system.

How did we come up with a brand new system?

With that idea in mind, we set out to research to get a sense of direction, we read many articles on the process of building a design system and Part of our exercise also involved looking at what other organizations were doing to tackle the same problems. We looked at design-driven companies like Google, Apple, Gojek, Airbnb, Atlassian, and IBM.

After weeks of research, we realized that a framework or methodology is what we needed to craft an interface design system.

This led us to look at & follow the Atomic Design methodology by Brad Frost in 2016 and mapped it in our design system spectrum.

The atomic methodology was developed by taking inspiration from the chemistry field. Where smaller elements, or atoms, can be combined together to create larger objects or molecules.

Parallelly in the design world, we use many small elements to construct our designs.

The atomic design methodology is composed of five stages. Each stage builds on the previous, acting as an aggregate of items from the preceding stages. By the time you reach the final stage, you have a fully developed design.

So without further ado, let’s get into each part of the process🚀!

Foundation:

Foundations are digital brand guidelines, which define typography, color palettes, icons, spacing, shadow, and information architecture of our design system. This helps in formulating consistent components.

Instead of starting from scratch, we took a deeper look at what we had created in the past to make the foundation. We sat down and went through every flow of our app. Sifting through a month’s worth of XD & Figma documents was not pleasant, but it was necessary.

When we started, this is what we had 😅:

In our designs, we found some redundant hidden layers, no grid structures, and no fixed naming conventions. We had files with almost ten different ‘brand’ colors on one artboard. You get the idea.

But somewhere a pattern began to emerge. We could see common colors, typography, and shapes that formed the base of most of our designs.

Here are some of the modifications we made:

• We removed the 50 shades of grey (maybe more!) and settled with just 5 grey variants for the background, separators, and text. In the end, we reduced the color palette to a total of 13 colors.
• For Solv, we decided to use Urbanist — An open-source geometric typeface. The line-height, letter spacing, and font-weight were well defined, and HIG or Web standard guidelines were followed.
• When it comes to icons, we decided to use an open-source icon library Iconsax to ensure a uniform look and feel. for all our platforms (iOS, Android, and Web). If we need a new icon, we are adjusting the existing one according to our requirements.

Components:

In the components stage, we take our foundation atomic design elements and begin to bring them together into new groupings to form molecules or (components).

These components are used repeatedly throughout the development of a product — normally actionable or sometimes just to convey meanings.

A few examples include buttons, inputs, form controls, toggles, lists, ratings, tags, etc.

All these components are stored in a shared repository called the library, which is a great way to build consistent UI and speed up the design & development of the app.

Patterns:

As we enter the pattern stage, our collections of foundation elements and components are now becoming more complex reusable, and scalable snippets called patterns.

The pattern is not yet a complete design but is a component that can be reused across designs or layout templates. Patterns are the same as components but there is a fine line of distinction between the two.

Templates:

A template is where we begin to curate our organisms and other elements into a cohesive design.

You saw in the pattern stage that elements began forming into usable blocks of content, and those start coming together into a template of patterns that can be used as a screen.

Features:

Features are the final stage of the Atomic Design methodology. Once you have templates, you can create features from them by grouping templates.

The features stage is essential as it’s where we test the effectiveness of the design system. Viewing everything in context allows us to loop back to modify our molecules, organisms, and templates to better address the real context of the design.

What’s Next?

We’ve already been able to rely on our design system for future requirements and will continue to do so. It makes it an easy collaboration between designers, product managers, and engineers. The design system provides us with a shared understanding of our visual style and enables all of us to prototype and experiment with ideas in high fidelity faster and at a much lower cost.

The effort required to build a design system is tiny compared to the effort required to maintain it.

Good Design Means Good Business

We also know that building a design system for one’s own organization can turn out to be a very exhilarating process. If you are attempting to build one, feel free to try some of the steps we followed at bud-e to get as close to the system as we had imagined creating.

Documentation and assets:

In the past, we’d created documentation in PDFs that featured our style guide, but this required risks to maintain the document update. Today, we write our documentation right into the tools.

We turned to Figma as our main design software for its powerful collaboration features. Because this means that our work files live exclusively on the cloud, we can maintain a single source of up-to-date documentation. We manage a comprehensive library where we not only publish and update our UI components but also write supporting guidelines, build lists of Dos and Don’ts, and showcase good examples. One key benefit of a live system is that we only need to maintain a single file: a single place designers can turn to for everything they need.

Conclusion:

The ultimate goal of our design platform is to make every designer a little better at thinking of everything in terms of systems — grids, typography, language, motion, accessibility, and so on. This allows everyone to design together, learn from a common source, and have a shared understanding of product quality across the company.

Lastly, Solv was built on the belief that we can never predict all future requirements, Building a design system is an endless job. This design system gets optimized version by version as we continue to ship new products and features.

We hope this article gave you a better insight into the brand new design system of bud-e.

if your ideas are different than ours or there are other benefits or drawbacks you’ve come across that people would benefit from knowing, don’t hesitate to share in the comments. We’re excited to hear from you!

Have a rice day! 🤤