Behind the scenes of designing a design system component
My experience with understanding what it’s like to design a design system component from scratch.
Hello,
It has been over six months since I joined the design system team at Razorpay. Long before working on the Blade Design System, I had the misconception that designing a component would be a quick and simple task. I believed that designing and creating multiple variations of a component would suffice. However, as time passed I came to realize that designing a component is a much more complex process.
In this blog post, I will share my insights and experiences, shedding light on the meticulous process behind the creation of a design system component. Let’s delve into the intricacies and uncover the magic that occurs behind the scenes of designing a design system component. If you are new to design systems or unfamiliar with the concept, you may have pondered these two questions at some point:
- What it is like to design a component?
- Why does it take ‘x’ amount of time to design such simple-looking components?
This article will briefly answer both of these questions and I hope give you some clarity by the end. So let’s dive in and see what takes place behind the scenes in designing a design system component.
Here’s a brief outline of what I’ve covered:
- Auditing products
- Component research
- API decision
- Creating proof of concept
- Internal discussion
- Advocates review session
- Creating the base variant
- Creating the variants in different themes
- Documentation
- Motion design
- Dev review
- Design review
- Time to go live
📑 Auditing Products:
The process starts with auditing existing components in different products across all business units of Razorpay. At an organization like Razorpay, we have a wide range of products. Being aware of different use cases and common patterns is crucial to building components that can cater to all (almost all) use cases. Help from blade advocates (Blade Advocates is a group of product designers from different business units across Razorpay who help audit, provide use-cases and inputs and review final outcomes of a Blade component corresponding to each of their products.) is also taken into account for use cases or problems that we might not be aware of.
🔍 Component Research
No matter what you are designing, a little bit of research always helps. In this context, it is mostly secondary research. This secondary research conducted for the components can be briefly divided into 2 categories:
- Gaining component level understanding — this involves going through articles, blogs, videos, etc., and gaining better context about the component that is to be designed.
- Understanding how other design systems do it — this step involves analysing and understanding how different design systems are designed and structured a component.
You might ask, how this research helps. The insights gained from this research helps to understand:
- Best practices for the component
- Usage guidelines, accessibility, interaction, and behaviour of the component
- How others systems have structured their component
- What are the possible variants that the component can have
- What all props can be offered for the component
⚙️ API Design:
A very major step in the component building process — API design. The Component API generally encompasses all the methods, properties, and events that can be accessed or manipulated by developers or designers when using the component. To put it in simpler terms these are the properties that you see on the right side panel in Figma every time you select a component instance.
One of the x-factors while creating Blade was to reduce discrepancies between design & dev by exposing a set of synchronous APIs on both, so a API on Figma translates exactly into a React prop for a developer to consume thereby reducing any possibility of friction.
It might seem fun to have a lot of exposed props and let users play around with it but in order to drive consistency using components, there should be a good balance of exposed props.
This process starts with creating an extensive list of all the all the variants and props that can be given to users. Post these there are internal discussions with developers and designers to decide which props should be exposed and which should not be exposed.
📐 Creating a Proof of Concept:
Based on the insights gained from the audit and research, a proof of concept of the component is created. Certain things that are taken into consideration while creating the POC (proof of concept) include — how the component should be structured and what all props should be offered in the context of Razorpay. At this stage, the focus is less on the visuals (how the component looks) and more on the functioning (how the component is structured). After this stage, we have multiple internal discussions within the DS team before going to the larger forum.
💡 Internal Discussion:
At this stage discussion regarding the component happens within the design system team. The POC that was created earlier is used at this stage.
1. Design Discussion:
This is a brainstorming plus review session that happens between the design system designers. This is also the first level of review that happens in the component design process. Here, the discussion mostly happens around the structure, styling, props and use cases covered by the component.
2. Engineering Discussion:
Discussion with design system developers happens once the design discussion is done. This discussion gives the developers a brief overview of how the component is structured and what props are available for the component. On the design side, it helps to understand the tech feasibility or considerations that need to be taken into account, edge cases of the component that might have been missed, and receive quick feedback on the designs.
The feedback received from the design and engineering discussion is implemented and then the conversation goes to a larger forum.
🎙️ Advocates Design Review:
At this stage, we have a design review session with the blade advocates. Having designers from different business units across the org in the review session helps to get feedback on how the component would work across different products. This is also where we try to get alignment and sign-off from different BUs before moving into the actual component design phase.
This is not a one-time thing, many a time there is major feedback on the component designs. The use cases are validated, and if the use cases are valid the feedbacks are implemented. And the review cycle repeats in async or sync mode. Once there is alignment and sign-off, the next phase begins.
🛠️ Creating the Base Component
Once the component structure and API decisions are locked, the base component is created. What’s a base component? — It is the structure of the component that is created. No stylings are applied at this stage, it is just the skeleton of the component.
Having a base component comes with its own pros and cons:
- Pros: When having a multi-brand system, base component reduces the maintenance efforts across multiple themes and makes it easier to create new themes if required.
- Cons: It makes the component heavier on Figma and makes it bit slower to use due to nesting of multiple layers.
🎨 Creating the Variants in Different Themes:
Using the base component that was built earlier, the component variants are created at the theme level. This is where the styling of the component is applied. The tokens of the design system are used to define the styling of the component. This is the stage where the aesthetics and accessibility of the component are taken into account. We have 2 themes — Payment Light and Banking Dark. We try matching the tokens on both themes. Why do we do that? — there would be less maintenance effort if the token values are changed someday and it won’t affect the components in 2 themes in different ways.
📝 Documentation:
The next step is documentation. All the components are intensively documented. The component documentation consists of the following:
- Introduction — gives a brief definition and overview of the component.
- Dev Characteristics — contains all the information that developers would need while building the component. It includes the component props details and the tokens used to design the component.
- Variants — shows all possible variants of the component at an overview level.
- Usage Guidelines — has information on what practices should be followed while using the component and tells how the component should or should not be used in different use cases.
- Platform — contains information on how the component should be used across different platforms.
- Accessibility Guidelines — has information about accessibility practices that everyone should take care of while using the component.
- Motion Guidelines — has all the details regarding the animation of the particular component.
Curious to learn more about our approach to organising and documenting components at Razorpay? Dive into Saurav Rastogi’s comprehensive article, where he delves into the intricate details of our component organisation and documentation process.
P.S.: You can grab the free Figma template here to organise your design system.
🎬 Motion Design:
At this stage UI motion is added to all the interactive components. Non-interactive components such as badges or indicators might not need motion but for interactive components like accordion, dropdown, tooltip, etc. motion is required. We have a well defined motion system with tokens which help create animations for components. This is the stage where the following things are designed:
- Animation for components to change from one state to another
- Entry and exit animation of the component
- Interaction pattern of the component
The animation details are handed off to developers post-completion of the component-level motion design.
P.S.: This is a broad topic in itself, will be covering this in another article.
👨💻 Dev Review:
Once the component has been designed and documented, another cycle of dev review happens. Developers go through the component design and documentation and give their feedback. Most of the feedbacks are resolved async but if there are any major feedbacks, it is discussed and closed on a review call. Once everything is good to go, the component moves to the development phase.
🧪 Design Review:
Once the component is developed, there is one last check to see if the developed component and the designed component are in sync. At this stage, we try to fix if there are any discrepancies in terms of visual design, props naming, and motion design of the component. We try to follow the principle —
“What you see in the design is what you get in code”
🚀 Time to Go Live:
Releasing the component on Figma Library is intentionally delayed a bit so that they can be released from both designs on the dev side at the same time.
Why do we do that? Well, think of a scenario where the component is released from the design side and designers have started using it to design their products. But the component isn’t ready on the dev side yet. So when the product design goes for development, developers might end up creating custom components since that component is not available on the dev side. And this won’t be ideal, right?
It is time to go live once everything is good to go from the development and design side. From the design side, the components are published in Figma, and from the dev side, the components are also released for everyone to use them.
Well, this does not end here. Once the component is live there are feedback, new requirements, changes, etc. that can come in at any time. And if the use case is valid, then the changes are prioritized and incorporated accordingly.
Much like other design processes this is also not a linear process, lot of back and forth happens at various stages before finalizing and shipping the component
Shout out to Saurav Rastogi and Abinash Shaw for reviewing and providing valuable inputs on the article.
With new Figma features coming into place we are also working on enhancing the component creation process and the experience of using of using the design system components. But that’s a topic for another day.
Found it helpful? Don’t keep this to yourself, share it with people who might find it helpful. You can hold that clap button for a few seconds to give a maximum of 50 Claps.
