Behind the scenes of animating a design system component

A short guide on the process of adding motion to a design system component from scratch.

Rama Krushna Behera
Razorpay.Design

--

Hello,

Almost an year back I published an article on behind the scenes of designing a design system component. The article briefly covered about how motion is baked into design system components (and I also mentioned this 👇🏼👇🏼)

In this blog post, I’ll take you on a journey behind the scenes of animating a design system component. As a member of the Blade Design System team at Razorpay, I’ve had the opportunity to dive deep into the intricacies of creating engaging and functional animations that enhance the user experience.

I’ll share my insights on the process, from initial concept to final implementation. We’ll explore the challenges, the triumphs, and the lessons learned along the way. Whether you’re a seasoned designer or just starting out, this post will provide valuable insights into the world of animation in design systems.

You can check out Blade Design System on Figma Community for more information.

Here’s a brief outline of what I’ve covered:

  • Component animation audit
  • Component animation research
  • Internal discussion
  • Understanding the motion token structure
  • Creating and testing the proof of concept
  • Gathering feedback
  • Finalising the animation
  • Documentation
  • Dev Handoff
  • Time to go live

📑 Component Animation Audit:

The process starts with auditing the animation of 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 in setting context on how to shape the motion of a component.

Audit of Modal animation on Razorpay merchant dashboard
Audit of Modal animation on Razorpay merchant dashboard

🔍 Component Animation 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 is done to analyse and understand how other products are doing it and what we can learn from them. There are three ways in which secondary research for component animation is done:

  1. Open-source Design Systems — this involves going to open source design systems and analysing how their components animate when triggered.
  2. Interacting with Products — this involves going through products which have really good component animation but their DS is not open source. One can go through the main user flows to analyse how the animation has been added to a particular component.
  3. Dribble/ Behance/ X — the last and the final one, going through these platforms where people post real life examples or conceptual ideas from which inspiration can be drawn.
Modal animation of Shopify’s Polaris DS
Modal animation of Shopify’s Polaris DS

💡 Internal Discussion

Based on the research and audit, a small brainstorming session is done to understand what are the different animations that would be required for the component in our DS. Mostly, the things discussed in this step are:

  • Do we need animation for hover, click, etc. interactions?
  • What are the various edge cases that we might need to take into consideration?
  • What should be the interaction pattern of the component?
  • What should the entry and exit animation for the component look like?

⚜️ Understanding the Motion Tokens Structure:

The next step is creating a proof of concept. But before that let’s understand how the motion tokens have been structured at Blade DS. The motion tokens comprise of three primary parameters:

  • Core Actions — the properties that can be animated(scale, rotation, etc.)
  • Duration — the time it takes for transition to happen
  • Easing — the curves that determine how the animation progresses

There are scales and values defined for each of these parameters. These tokens are followed while implementing motion in any of the components. You can check out the motion tokens on Blade Storybook.

P.S.: Curious to know how the motion tokens are setup? Will be covering this in a future article.

Different motion foundation tokens available in Blade DS
Different motion foundation tokens available in Blade DS

📐 Creating and Testing the Proof of Concept

Based on the insights gained from the audit and research, multiple proof of concepts of the component animation is created using the motion tokens. This is an explorative step where various options are created to gather feedback on. At this step technical constraints are not taken into consideration and the focus is on try out various ideas.

From tooling perspective, Figma is used to try out various ideas and create the proof of concepts. As of now, Figma doesn’t have any feature to directly apply motion tokens. One has to refer the motion token values and manually apply them in the animation.

Few things to take into consideration at this step:

  • The component animation should feel on-brand. For example: A very bouncy and slow animation might not work well for a brand like Razorpay.
  • The animations should not slow down or distract the users from their primary action. For example: Majority of Razorpay products are B2B, if very slow or fancy animation every time user interacts with the UI, then that would be frustrating for the user.

Once the POC(proof of concept) is created, it is tested on various UI screens where the component will be used. Why is this done? Sometimes a component animation seems good when viewed separately but when the same component animation is viewed in context to other elements inside of an UI, it might not look that good. To cater for cases like these the animation concepts are tested on real UIs.

Screenshot of different explorations for Modal animation
Screenshot of different explorations for Modal animation
Testing out Modal animation in real UI
Testing out Modal animation in real UI

🎙️ Gathering Feedback

At this stage discussion regarding the component animation happens within the design system team. The POC that was created earlier is used at this stage. Both, the Figma prototype and screen recording of the prototype are shared async for feedback. At this stage feedback is gathered from both design and engineering.

  • Design Feedbacks— this mostly comprises of feedbacks around how the look and feel of animation, it’s usability, if it is on brand or not, etc.
  • Engineering Feedbacks — this mostly comprises of feedbacks related to technical implementation of the animation, if the animation is feasible or not, if it would effect the performance of products, etc.
Sharing different animation concepts to gather feedback
Sharing different animation concepts to gather feedback

🎬 Finalising the Animation

The feedbacks are processed and final component animation is created at this stage. Most of the time Figma is able to handle the animations and that is the go-to tool. But if the animation or the component is complex then Figma becomes bit jittery at times. In these cases, After Effects is used to create the final version of the component animation.

📝 Documentation

Once the final animation is ready, the motion values and the interactions are documented for handoff and future reference. Internally, there is a motion spec that is being used to document the motion values. The spec contains all the details specific to the animation. It comprises of the following:

  • Initial and final state of the component
  • A GIF of the animation
  • Interaction triggers
  • Duration and easing tokens
  • Value changes for core actions on animating layers

Don’t worry, to make it easy we’ve created a dummy Figma template on how to organise your design system towards the end.

Documentation of motion implementation for Switch component
Documentation of motion implementation for Switch component

👨‍💻 Dev Handoff

Most of the time, the motion spec is used by the developers to implement the motion in the components. There are few instances where the details and intricacies of the animation cannot be conveyed in the spec itself. In cases like that custom handoff docs with illustrated diagrams are used for handoff.

Custom documentation of motion implementation
Custom documentation of motion implementation

🚀 Time to Go Live:

The animation is implemented into the components and once the component has been tested and reviewed, it is published on both dev and design side for everyone to use.

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.

Go Live Announcement for Skeleton component
Go Live Announcement for Skeleton component

Much like other design processes this is also not a linear process, back and forth happens at various stages before finalizing and shipping the 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.

That’s a wrap; I hope you found it insightful. If you have any questions, feel free to reach out to me on Linkedin, Twitter, Instagram, or Website.

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.

--

--

Responses (2)