Sharing some recipes and workflows into what it’s like to maintain and scale design system components.

Hello,

Sometime back I wrote an article on what’s it’s like to design a design system component from scratch sharing some of the learnings I had while designing components for Blade Design System. But what happens once the component has been shipped?

In this blog post, I will share my insights and experiences giving a brief overview and process on how to maintain and scale your components with time as per brand, product and user requirements. If you are working or have worked on design systems, often you might have pondered over questions like:

• What happens once the component has been built?
• Do we make changes to it and if yes, what’s the right way to approach it?

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.

P.S.: In this article, consumers refer to the consumers of design system (designers, engineers, and PMs), and users refer to the end users who use the final products.

Here’s a brief outline of what the process looks like:

• Issue Type
• Raising the Issue
• Evaluating the Request
• Prioritising the Request
• Resolving the Issue
• DS Team Practices

💠 Component Lifecycle

Once the component has been built and shipped, it most remains in maintenance mode until a new requirement comes up. The requirements mostly come from consumers based on various parameters that we will discuss later in this article. Once the request has been received, the design system team evaluates it and makes necessary updates to the component. (or in some cases create a new component if needed)

🚩 Issue Type

Issues are generally the requests that are raised by consumers for any component or any design system requirement. Broadly all the issues can be categorised into:

1. Bugs

Bugs are unexpected breakages or malfunctions within a component that disrupt its intended functionality. Few examples of bugs would be when the component:

• Does not behave as documented or expected
• Breaks across specific browsers, devices, or screen sizes
• Has accessibility issues that block usage for certain users
• Introduces visual or functional inconsistencies compared on design and dev

2. Enhancements

Enhancements are requests to improve or extend the capabilities of an existing component. Unlike bugs, these are not fixes but rather feature improvements that make components more powerful, flexible, or user-friendly. Few examples of enhancement of component:

• Adding new props or configuration options
• Supporting additional use cases (e.g., more states, variants, or layouts)
• Improving performance, accessibility, or usability
• Aligning components with evolving design standards or branding

🚨 Raising the Issue

Issues can originate from different sources and are identified whenever a gap, inconsistency, or improvement area is noticed in the design system. Broadly, issues may surface through:

1. Consumer Reports

Consumers of the design system are often the first to encounter gaps or problems when using components in real projects. They can raise issues through:

• Slack: Posting in the #design-system channel with details of the problem or feature request
• Office Hours: Bringing up concerns during scheduled design system office hours calls

2. Self Identification

Not all issues come from external users. Sometimes, while working on new features, audits, or refactoring existing components, the design system team may identify:

• Technical debt (e.g., outdated code patterns, performance bottlenecks)
• Visual/UX inconsistencies (misaligned with the latest design guidelines)
• Accessibility gaps discovered during testing
• Scalability concerns when extending components for new use cases

🔍 Evaluating the Request

Not every reported issue turns out to be a valid issue with the design system. To maintain focus and efficiency, each request is carefully evaluated before it is taken up for resolution. Broadly, issues fall into two categories:

1. Incorrect Implementation

Sometimes the reported issue stems from how the component is being used, rather than the component itself being faulty. This could happen when:

• The wrong component is chosen for the use case
• Props or configurations are applied incorrectly

👉 In such cases, instead of creating a fix, the design system team provides guidance to consumers — suggesting the correct approach, pointing them to the appropriate component, or clarifying usage through documentation updates.

2. Valid Concern

A valid concern is when a component fails to perform as expected, even when it has been implemented correctly. This can include:

• Functional bugs (e.g., a prop not working as intended)
• Visual or accessibility inconsistencies
• Performance bottlenecks in real-world scenarios
• Gaps that block legitimate consumer use cases

👉 For valid issues, the consumers raise a ticket to track, prioritise, and resolve the problem, ensuring transparency and accountability.

⏳ Prioritising the Request

Not all issues carry the same weight or urgency. To ensure efficient use of resources, each request is evaluated and assigned a priority level (P0, P1, or P2) based on the following factors:

1. Blocking the Product GTM

Is the issue preventing a product from going live or blocking a critical release?

• Yes → Automatically considered a P0 and addressed immediately.
• No → Evaluated against other factors below.

2. Effort Needed for Implementation

How complex is the fix or enhancement?

• Low/Medium Effort → Quick wins may be prioritised sooner.
• High Effort → Weigh against impact before scheduling.

3. Experience Breakage on User End

Does the issue directly impact end-user experience in production?

• If user experience is broken, the issue bypasses all other checks and is treated as P0, regardless of effort.

4. Good to have

Is it a nice-to-have feature or improvement that does not impact current functionality or user workflows?

• These requests are usually categorised as P2 and taken up when bandwidth allows.

P.S.: There could be occasional scenarios where we have to break from the guiding framework depending on various external parameters.

🛠️ Resolving the Issues

Once an issue has been validated and prioritised, the next step is to determine the most effective way to resolve it. Depending on the impact, effort, and scalability, there are three possible resolution paths:

1. Fix Within the Design System

The preferred approach is to update or enhance the component directly within the design system.

• This ensures the solution is scalable, consistent, and available to all consumers.
• The updated component is released as part of the next design system version, with proper documentation and change logs.

2. Provide a Workaround

In cases where the effort to fix is high but the impact is relatively low, the design system team may suggest an alternate approach:

• Consumers are guided on how to use existing components or combinations to achieve the intended outcome.
• Documentation or examples may be shared to make the workaround easier to implement.

3. Snowflake Route (Exception Path)

For highly niche or product-specific requirements that are not scalable across the system at the time it was raised, maybe can scale in future:

• A custom component may be created outside the design system, but still aligned by using design tokens for consistency.
• This is treated as an exception, not the norm.
• Such solutions require review and sign-off by the design system team to ensure alignment with design principles and governance.

🤝 DS Team Practices

To ensure issues are tracked, prioritised, and resolved effectively, the DS team follows a set of structured practices. These practices help maintain transparency, scalability, and quick turnaround for consumers.

1. Dedicated Channels for Receiving Requests

All design system–related discussions happen in the #design-system Slack channel.

• Acts as a single source of truth for consumers to raise issues or ask questions.
• Helps the DS team keep all requests centralised and visible, avoiding scattered conversations.

2. Issue Tracking on DevRev

We use DevRev internally as the system of record for issue tracking.

• Consumers raise tickets directly on DevRev.
• The DS team uses these tickets to track progress, assign ownership, and maintain accountability.

3. Weekly Triage Calls

A recurring weekly triage call ensures that issues raised are not just logged but also acted upon.

• The team reviews all open requests and tickets.
• Issues are prioritised (P0, P1, P2) based on impact, effort, and urgency.
• Ownership is assigned, and timelines are clarified.

4. Dedicated Days for Ad-hocs

Each team member keeps 2–3 days per sprint(2 weeks) reserved for handling ad-hoc requests.

• Ensures urgent consumer-reported issues don’t wait until the next sprint.
• Provides flexibility to address real-time needs without derailing planned work.

5. Special Mention: BladeBot

We’ve built BladeBot, a Slack bot powered by the DS knowledge base.

• Instantly answers most developer queries (e.g., usage guidelines, component details).
• Reduces dependency on the DS team for routine questions.
• Frees up team bandwidth to focus on high-impact issues and roadmap items.

Much like other design processes this is also not a linear process, lot of back and forth happens at various stages before finalising and shipping the component

Shout out to everyone who have contributed over time to set up this entire framework in place: Abinash Shaw, Anurag Hazra, Chaitanya Deorukhkar, Kamlesh Chandnani, Saurabh Daware, Saurav Rastogi, Ashutosh, Gaurav, Ravikumar, Swapnil

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.

Behind the scenes of maintaining a design system component was originally published in Razorpay.Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ever wondered why clicking a button on a website feels so natural? It’s because much of what we see on the web is inspired by how we interact with objects in real life! From flipping switches to browsing stacks of cards, designers borrow everyday experiences to create intuitive interfaces. Let’s explore some popular UI components, see where they come from in the physical world, and have a little fun along the way.

P.S.: All the UI components that you see in this blog are taken from Blade Design System

1. Button 🔘

Remember pressing the button on a toaster, doorbell, or even an elevator? That satisfying little push is exactly the experience modern designers and developers tried to replicate. On-screen buttons respond with visual feedback, much like that tactile click in real life. One click, one tap, and we’re off — just like pressing a real-world button to trigger a specific action.

2. Radio Button 📻

It might sound a bit old-school, but the radio button was inspired by the channel selector on old radios. You could only push one station button at a time: pressing a new one would pop the previous button out. This ensures you make just one choice in a given set, echoing how real-world radio buttons behave.

3. Checkbox ☑️

Think of a real-life checklist, like a grocery list. You mark items as done by ticking a box. That’s exactly how checkboxes on forms or settings pages work: checking off multiple items to indicate your choices, giving you that mini feeling of achievement each time.

4. Switch 🔀

Light switches are one of the most common household objects. Flick it up, the lights are on. Flick it down, lights out. Digital switches carry the same logic: they toggle a state on or off. That flipping motion is both intuitive and satisfying, just minus the elbow grease.

5. Input Field 📝

Think of the humble notepad or paper form. We write down our name, date of birth, or any detail required. On the web, the input field is your digital notepad. It waits patiently for you to scribble in your details, sending them off once you submit.

6. Slider 🎚

Volume sliders have evolved into modern digital sliders. Drag it up or down — just like that physical slider on your stereo system — to adjust levels. The immediate feedback you get is reminiscent of turning the dial up to crank that awesome tune.

7. Tabs 📑

Tabbed folders and binders have been around for ages in offices. Each tab displays a new section or topic while keeping the other tabs accessible. Digital tabs bring this concept to the web, making navigation snappy and organized.

8. Drawer 🗄

We’ve all had that junk drawer in the kitchen — slide it open when you need something, then close it up. A digital drawer is just that for your user interface: hidden away until needed, then easily accessible with a simple click or swipe.

9. Date Picker 📅

Ever had to thumb through a wall calendar to figure out the date of an upcoming event? The date picker re-creates that experience digitally. You select the month, the day, and voilà — just like flipping through a physical calendar minus the paper cuts.

10. Cards 🃏

Borrowed from physical index cards or playing cards, digital cards group content together in a neat rectangular package. They’re easy to shuffle around, stack, and organize, making scanning and browsing content feel effortless.

11. Progress Bar ⏳

Think about watching a fuel gauge creep down as you drive — progress bars do something very similar in the digital realm! They show you how far you’ve come and how close you are to the finish line, much like a dashboard meter that lets you know when you need to refuel.

12. Alert ⚠️

Think of a roadside caution sign or a big flashing traffic signal: bold, in-your-face, impossible to ignore. That’s exactly what an on-screen alert aims to mimic — capturing your attention to deliver an urgent message or reminder.

13. Pagination 📖

If you’ve ever used a book’s page numbers to flip through chapters, you’ve seen pagination in action. On the web, we split content across multiple pages to avoid endless scrolling. Clicking “Next” or “Previous” is just a digital way of turning a page.

14. Badge 🎖

Think of a sticker or a pin on your shirt, showing a message or achievement. Badges on web apps do the same: they highlight notifications or statuses, providing a quick snapshot of what’s new, just as real-life badges announce your proud accomplishments.

15. Breadcrumb 🍞

Think of the Hansel and Gretel story: leaving crumbs on the path to find their way back. A digital breadcrumb trail shows you where you are in a site’s structure and how to go back. This navigation tool is your personal trail of crumbs.

16. Toast 🥪

A quick pop-up notification is much like a toaster: once your toast (or message) is ready, it springs into view. And just like real toast, it’s usually gone after a few moments — hopefully without being burnt.

17. Menu 🍽

Menus on websites function just like restaurant menus. Browse the options, pick what you need, and the item (feature or page) is served. Easy to read, easy to choose — no bickering over what’s for dinner.

18. Tag 🏷️

Often used to label or categorize items (think of sticking a small label on a physical folder). A digital tag provides context at a glance.

Parting Thoughts

Web design is often a mirror reflecting the real world’s objects and interactions. By incorporating these familiar patterns, builders create interfaces that feel natural to users. When you see a button on your next website, think of that elevator or toaster button. That sense of recognition and comfort is what makes modern UI design both intuitive and fun.

Thanks for taking this journey through the everyday inspirations behind common UI components. The next time you interact with an accordion or a loader on a site, see if you can spot its real-life counterpart. You might be surprised how much we rely on old-school inspiration for our new-age digital playground!

From Real to Digital: How UI Components are Inspired from Real World Objects was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

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

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.

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

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

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

🎙️ 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.

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

👨‍💻 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.

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

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.

Behind the scenes of animating a design system component was originally published in Razorpay.Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

A beginners guide for product designers to get started with motion design.

Hello, hello!

What’s this article about? Being a full time product designer who can also do motion design upto some capacity (subtle flex), one of the frequent question I receive (from majority of folks in my circle, who happen to be product designers) is — I want to try out motion design, how can I get started with it? So this article basically talks about that. An approach that I have suggested a few folks and has worked for them. Hoping that you also find this helpful!

Let’s dive in...

Disclaimer: This is an article on how to get started with motion design, not on how to get better at motion design. If you are looking to get better at motion design, this might not be the right article for you.

🛠️ The tool in every product designers’ arsenal — Figma

If you are a product designer, you obviously know what Figma is(unless you are reading this article after some 500 years.) As product designers, we are responsible for multiple things — brainstorming solutions, defining flows, creating wireframes, designing stuff, etc. etc. Now, as product designers one thing that we do which is very close to motion design in many aspects is — prototyping.

When I say prototyping, I don’t mean just connecting multiple screens with an ‘instant’ transition to showcase a couple of flows in your product. What I really mean is building thoughtful prototypes where you take into account how the transition happens, how the content changes on screen, how micro-interactions happen, etc.

Mostly these kind of stuff can be achieved by using ‘smart animate’ while prototyping in Figma. Let’s understand how smart animate works and how is it related to motion design

If you are comfortable with using smart animate on Figma, you are already doing basic motion design upto some extent without realising it!

🔬 Dissecting Smart Animate — How does it work?

In Figma, while building a prototype if you want layers on your design to animate from one state to another that is where you use the smart animate property.

So, how does it work? When prototyping between 2 layers, it checks for the layer names on both the frames and animates the layers with matching names. If, in case it not able to find matching layer names, it just does a simple dissolve animation between the two frames.

You can learn more about smart animate in Figma’s official page.

🪄 What can you control with smart animate?

When using smart animate, it gives you the capability to control the following three things:

• Core Action — 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

Smart animate also lets you create spring-based animation but let’s not dive into that right now. Quick 101: Unlike classic animation(where you use easing curves), in spring animation you control the look and feel of moving objects by adjusting spring properties such as bounciness, stiffness, speed, etc. Spring based animations work only on web and not on animation tools. To keep thing simple let’s not jump into spring-based animations for now.

🪭 Fundamentals of Motion Design

Enough about Figma and smart animate, let’s talk about motion design. No matter which tool(AE, Lottie, CSS, etc.) you are working with or what kind of animation(2D, 3D, etc.) you are working on, the fundamentals always remain the same.

For any animation to work, you need to be able to control 3 main parameters. I think you might have guessed the answer already! These three main parameters are —

• Core Action — 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

I think by now you must have figured out how things are related. The interface changes but the fundamentals remain the same.

🤔 Where to start from?

For starting with motion design — I basically tend to think that there are two parts to it. Even though both of these are necessary but learning both of them simultaneously can be bit confusing at times, especially when you trying it for the first time. The two key parts are —

• Animation Principles — These are fundamental principles which when followed makes your animation looks lively (squash & stretch, anticipation, etc.)
• Tooling — Getting comfortable with the tool that you will be using for animation.

If this is the first time you are trying your hands on motion, I would suggest start with tooling and then move on to animation principles. Why you ask? I believe that you are starting out —

learning how to move things >>> learning how to move things in the correct way

Now, animation principles are universally applicable irrespective of the tool. You don’t need to learn them every time. So if you have some experience with motion design, you might be knowing the principles already. In that case, directly jump into understanding the new tool and start animating stuff!

🪅 Which tool should one use?

Ok, now the obvious question — which tool should I use? There are so many motion design tools in the market.

While I find After Effects to be the ‘beast’ but it also has a steep learning curve (and yes, it is paid as well) which might or might not be the right tool if you just want to play around with motion. If you are just exploring motion design and want to try your hands on it, there are a couple of easy to use tools as well. Two tools that I like in particular are —

1. Jitter
2. Lottie Creator (in Beta)

Using these tools, you can easily import your designs from Figma and start playing around with the properties. They provide animation presets that you can use and reverse engineer to understand how simple effects are created. BTW if you are certain to try the beast mode — After Effects, feel free to do so. You can find find a lot of tutorials around these tools on the internet.

No matter which tool you pick, initially try creating stuff by watching the tutorials and replicating what’s shown in them. Once you are bit comfortable with the tool, try creating simple animations without watching any tutorials. Post this, you should ideally be able to create simple animations on your own. Well, if you want to go beyond this and up skill to the next level in motion design — that’s a very detailed topic in itself. Saving this topic for another day!

📝 Final Words

This is obviously not the only way to get started with motion design. Everyone has their own approach and learning methods that they find helpful. Personally, I started with motion design and then transitioned to product design, so can’t guarantee if this approach works 100% of the time.

But over last couple of months, with trial and error I have come up with this approach and have also suggested this to few of my friends and this has worked for them. So, I am hopeful that this might also work for you.

On another note, your first design work won’t be the best but it would be a start. Keep iterating, keep practicing and you will get better with time.

Happy Designing! ✨

If this article has helped you in kickstarting your motion design journey, feel free to tag me when you post your motion design works online. Would love to see some what you create.

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.

If you can smart animate, you can animate was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

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:

1. Gaining component level understanding — this involves going through articles, blogs, videos, etc., and gaining better context about the component that is to be designed.
2. 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:

1. Introduction — gives a brief definition and overview of the component.
2. 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.
3. Variants — shows all possible variants of the component at an overview level.
4. 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.
5. Platform — contains information on how the component should be used across different platforms.
6. Accessibility Guidelines — has information about accessibility practices that everyone should take care of while using the component.
7. 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:

1. Animation for components to change from one state to another
2. Entry and exit animation of the component
3. 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.

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.

Behind the scenes of designing a design system component was originally published in Razorpay.Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

A summary of what I got to learn at MakeMyTrip during my internship

Hey!
How’s it going?

I worked with the Make My Trip (Ingo — MMT) Team as a UX Design Intern for 6 months this year and it was awesome. The team builds the enterprise-facing product for the hotel line of business for the Goibibo and MakeMyTrip brands. During this brief period, I had the chance to work on multiple projects with some awesome people.

Here, I have jotted down some of my major learnings during the 6 months internship.

Let’s start now without any further delay…

1. Understand the terminologies

LOB, ARI, BD, ZM, Listings,…
Don’t these terms feel a bit intimidating to you?

Well, I too felt the same in the first couple of days. Something that I learned in the initial days is to understand the terminologies associated with particular sectors. Understanding these terminologies makes it easier to communicate properly with different stakeholders and also helps in getting a better context of the problem that one is trying to solve.

2. Ask, ask, ask… as many questions as possible!

A frequent mistake I made in the beginning was not asking too many questions. The outcome? A task that would hardly take 2 days to complete, got delayed as long as 2–3 weeks.

The insecurity regarding what others will think of me if I asked questions frequently refrained me from asking many questions. However, I understood its importance over time. Shoutout to my manager who always supported and encouraged me to ask more!

So, why is it important to ask questions?

• You get a better understanding of the problem you are trying to solve
• You get a context of the target users and their pain points for the particular problem statement (especially when working on multiple products built for different user groups)
• You get to know the what are the expectations from the stakeholders for the particular task

3. Understand how the business works

I realized in the first few weeks of my internship that — in order to design for business, you need to understand the business (obviously not the entire business but at least the bare minimum). Building a business context helps to better understand the business problems that we are trying to solve.

It is quite difficult to design for the needs of a hotelier (person who manages the operation of a hotel) if I do not have a rough idea about how the hotel industry works.

P.S.: I had zero knowledge about how the hotel industry works but it is necessary to understand once the wheels start rolling.

4. Communicate!

No one knows everything, but everyone knows something. Communicating frequently helps everyone to be on the same page while building the product. Moreover, it brings unique perspectives of team members and stakeholders onto the project.

Remote communication is quite challenging and also a bit confusing at times. Finding a common free slot in a calendar just for a 10–15 min discussion is also a bit difficult many a time. I learned when to schedule a call or a meeting and when to connect async (over chats/messages) and how frequently communicate with others in the team.

5. Take notes

Something that no one tells a designer who is starting out — your day is often/frequently packed with meetings. Something that comes along with meetings (apart from the loss of energy and attention) is a lot of information.

With an abundance of information, trusting in short-term memory is not a good idea. Often, it happened to me that after the meetings when I started working on the projects, I would miss out on some of the feedbacks because I relied on short-term memory. Taking notes during the calls/meetings helped me keep up with the information. I would note down anything that seemed important, old-school style — pen and paper.

6. Control! First, think then Design

The most tempting thing as soon as the Jira ticket is assigned to you — to open Figma and start designing. Well, with a design system in place and a defined visual style, it feels tempting to open the tool and start designing the screens directly but… flows > screens.

UI is important but the flow and layout need to be brainstormed beforehand for it avoids UI design reworks and helps to build a solution that not only just looks good but also works well for the users. Or to put it in simple terms, “It helps to build a meaningful and impactful solution.”

7. It is a multiplayer game

You don’t need to do it all alone. The unique experience and perspective of different team members, when brought to the table, helps to build a holistic solution.

Your lived experiences affect your design. You are a part of the design.

Previously, I had this notion that design work ends after hand-off but that is rarely the case. Sometimes the designed solution might not fit well with the business requirement or might be restricted due to technical constraints. So, it is necessary to get along with other team members (devs, PMs, etc.) to discuss and understand what they are trying to convey, what problem they are facing — and that’s the way you can come up with new solutions that fit almost all scenarios and use cases.

8. Be a story writer and a storyteller

Designers are good visualizers and there’s a notion that people will understand easily what we are trying to convey, but that’s rarely the case. So, what’s with story writing and storytelling?

Something interesting that I learned from other designers in the team was — to think of the entire user flow of the product as a story. A story where you are composing the story with the end users’ point of view and pondering over the question “What If…”. As a result, what happens is —

• It becomes easy to account for different use cases and edge cases
• It becomes easier to rethink and improve the user flow
• Helps to avoid minor inconsistencies in design
• Understanding difficult concepts
• Empathize and better understand the goals and pain points

Now that’s about writing the story. But narrating the story that you have written is the critical part. It is vital to narrate a story in such a way that it paints the perfect picture in people’s minds and helps to build a shared understanding with others by making it easy to understand how the product/ feature works. After all, who doesn’t love a good story?

9. Prioritise!

Well, I am going to write about my most important learning now. With multiple tasks at hand every week and each task involving various stakeholders, it just becomes really confusing and tiring to manage time and energy for work.

How to deal with this? It is not so simple and requires a few attempts over a period of time to effectively handle these multiple tasks. As per my experience, I believe that it works wonders to discuss the priority and dependencies of the tasks early, after, or during the sprint meetings. Calculate the effort and time needed (add some buffer too) for each of the tasks. Get an idea of your and your stakeholders' availability. And in a few attempts, you will figure it out.

Prioritizing the tasks helps to effectively spend time and energy resulting in increased productivity and least burnout.

Ok, so we reach the end now! : I am neither an expert nor a perfectionist and am constantly learning, unlearning, and relearning stuff on a daily basis. But, I hope I was able to share some learnings that might prove informative and insightful for you.

Thanks for reading :)

Learnings as a UX Design Intern at MakeMyTrip was originally published in Go-MMT Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

Designing of payout feature enabling target users to pay a group of 5–30 people in a seamless and hassle-free manner

In this case study, I have described my process of designing a bunch payout feature of RazorpayX. Bunch payout is a that enables users to pay a group of 5–30 people in a seamless and hassle-free manner. This was the capstone project that I had worked on as a part of the 10k Designers Masterclass.

Razorpay is a payment gateway which used by E-Commerce companies or websites which used to charge the customer for their product and services and they require payment gateway to collect the payment online through net banking, wallets, debit or Credit cards and UPI.

• Project Type and Role: Personal Project(Solo), UI/UX Designer
• Platform: Web
• Timeline: November 2020 (2 weeks)

❓ Problem statement

Making a bunch of Payouts using RazorpayX

RazorpayX is a neobank for companies to manage their financial operations. There’s a use case that requires companies to make payouts to merchants, vendors, payroll for employees, etc. Currently, there are two options: Single Payout and Bulk Payout.

• Single payout works great for transferring to one single entity.
• Bulk payout involves uploading a CSV in a particular format and works great for hundreds or thousands of payouts at once.

However, there isn’t a good way to make a payout for the range of 5–20 payouts. Both existing solutions, Single and Bulk involve a lot of effort.

Here’s a video where I showcased this project live on Whiteboard FM

👨 Target Users

1. Familiar with computers and use software like Microsoft Office, Browsers, Bank websites.
2. Their tools often aren’t super user-friendly — link bank of govt websites. So they often are “trained” to execute such tasks. The goal of Razorpay’s products is to eliminate training.
3. Given it needs training, they are often apprehensive about trying out new things. New products could be intimidating.
4. They end up doing the same tasks repeatedly. Like there would be some person in the team who would be making payouts day in and day out. The flows should be optimized for such users.
5. A person interacting with such tools is always very cautious about doing things. A small mistake here could lead to major goof-ups or losses in money. Razorpay’s solutions should help people identify and reduce their mistakes.

👑 What is RazorpayX?

RazorpayX is a neo-banking platform that helps business owners and finance teams automate the manual, repetitive financial task,s and provide insights into money flow.

• Payout

A payout is made to a fund account associated with a contact. You are eligible to make payouts after sign up, account activation, and KYC verification.

A payout can be created in 3 simple steps:

1. Adding funds to the business account
2. Creating a contact and a fund account
3. Creating a payout

• Types of Payouts

As of now, RazorpayX has two types of payouts:

1. Single Payout — Creating a payout and send it to a single user
2. Bulk Payout — Creating and sending payouts to a large number of users

• How Payouts Work?

When a payout is created, this is the flow it follows:

😠 Understanding the Pain Points

When it comes to making payouts for a small group (5–30) of people, it becomes tedious by both of the existing methods. I analyzed both of the payout methods to understand the pain point better.

1. Single Payout

Repetition is tedious

This method involves sending payout to one person at a time. For a large number of people, the user has to make individual payouts one by one which thereby reduces the speed and increases the chances of making an error.

2. Bulk Payout

No one (or a very few) people maintain a well formatted file for a small group of people

This method involves uploading a CSV file that has all the necessary information about the people who will receive the payouts. Most users do not maintain a well-formatted file for a small group of 5–30 people.

b. The required template of the CSV file

The file needs to be in a particular format in order to function properly. There is an existing template that needs to be followed for Bulk Payout to work.

🧠 Empathizing with the Users

A: 2 or 3 options?

2 because having 3 would confuse the existing users. Moreover having 3 options adds to the cognitive load. The user has to spend time and effort while choosing a particular option. (Hick’s Law)

B: Single or Bulk options?

After finalizing that there would be 2 options instead of 3, I had to decide where to place the Bunch Payout feature.

Upon conducting some basic research, insights suggested having the bunch payout feature in bulk because people prefer bulk when it is more than once contact. They refer to a single payout to making a payout to a single entity and not more than that.

🧫 Assumptions

1. There is a significant group of users such that this feature becomes helpful
2. Users make frequent payment to the same batches

🎯 Solving for Speed, Accuracy, and Security

1. Speed

• Selecting multiple contacts at once
• Having existing batches
• Data entry in form of sheets fastens the payout process

2. Accuracy

• Preview mode showing the important details of all the selected contacts
• Options or choices would be unselected by default
• Data entry in form of sheets reduces errors
• The sheet would be non-editable after upload

3. Security

• The sheet would be non-editable after upload
• Single OTP for all the whole batch showing the number of selected contacts
• Higher authority approval needed when the payout amount is greater than the threshold payout amount

🤔 Minimum data needed in the sheet

I ideated on what minimum placeholders should be present in order to carry out a successful payout. The minimum information needed were the following:

• Serial Number
• Name
• Payout Amount
• Bank Name
• Bank Account Number
• Purpose of Transaction
• Transfer Method
• Email ID
• Phone Number

😶 What if a user is not familiar with MS Excel?

A user who is not familiar with MS Excel does not fall into the target user group. Considering it to be an extreme use case, I planned on adding a Help section in the payout flow to smoothen the process.

The flow, sitemap and wireframes are of the final version

🌊 Deciding the Flow

I planned on the user flow with the features and user pain points in mind.

⛓ Sitemap for Bunch Payout

With the user flow in mind, I built the site-map demonstrating the addition of the bunch payout feature in the RazorpayX’s payout.

🔨 Wireframing

Taking the features and user flow into account I built rough wireframes for the product.

Feel free to skip to Exploration 2 to see the final solution

— Exploration 1

After coming up with a few concepts, I designed the interfaces for the website following the design guidelines set by the brand.

This version of the design follows a 4-step process in order to make a bunch payout. After logging in, the user gets a notification about the new feature launch. The bunch payout feature is present inside the Bulk Payout. The 4-step process is as follows:

1. Select contacts and create a batch: Select/add contacts, create and name a batch. There’s also an option to select existing batches to fasten the flow.
2. Enter payout amount:
   Case 1 — If the payout amount is different for different contacts, the user has to enter the individual payout amount for all the users.
   Case 2 — If the payout amount is the same for all contacts, the user has to enter one payout amount and select the option “same payout amount for all contacts”.
3. Preview the payout:
   The user gets to preview the payout before finalizing and confirming the payout.
4. Confirm the payout:
   The user gets the OTP and upon entering the OTP the payout is created.

👏 Feedbacks and Insights

A crucial step in the design process — feedback.

This feedback was crucial to understanding the shortcomings and delivered insights to improve upon the solution.

— Exploration 2

Based on the feedback received, I iterated and came up with a solution that accounted for the missed use cases meanwhile improving the speed, accuracy, and security of the user using the application.

a. Onboarding

• User logins through the usual login screen to access the RazorpayX Dashboard
• After feature launch, there’s a one-time notification to make people aware of the new feature that has been added

b. Dashboard & Bulk Payout

• The dashboard has the previous payout options — Single and Bulk
• Bunch payout can be accessed from the Bulk Payout Page by clicking on “Upload Excel File” or “Enter Manually”

Does the user have Excel Sheet??

Case 1: The user has an excel sheet

c. Uploading the Excel sheet

• The user uploads the excel sheet that has the necessary information in order to carry out the payout

d. Renaming the column headings

• The user has to rename the column headings to the required names for easier and more organized data management

Case 2: The user does’nt have excel sheet

c. Selecting contacts and creating a batch

Possible Use Cases:
a. Send payout to a new group of contacts
b. Send payout to an existing group of contacts

• The first step involves creating and selecting contacts and grouping them as a batch for easier faster transaction
• Previously created batches are also present to avoid errors by eliminating the tedious process of selecting and creating batches every time

d. Creating Payout amounts

Possible Use Cases:
a. Send different payout amount to a group of contacts
b. Send the same payout amount to a group of contacts

• The user enters the payout amount for the contacts in the respective cells.
• For entering the same amount for multiple contacts, the user can select multiple cells using keyboard controls and enter the payout amount

e. Payout Finalization

• The third step involves previewing the information before finalizing the payout
• The fourth step involves entering the OTP sent to the registered mobile number for a secured transaction

f. Result

• Based on the outcome of the process, result screens will be displayed showing the payout status

🎁 Takeaways

• Putting users first in the design approach instead of intuition

During the initial steps of the project, while brainstorming and ideating when I had to decide the placement of the feature it seemed a good option to merge it with ‘Single Payout’ but upon some research, it made more sense to add the feature in ‘Bulk Payout’.

• Working with a well-established design system

Razorpay has a well-established design system, while working on the designs, I had to make sure that I followed the guidelines and created the designs accordingly. Deviating from the guidelines changed the design language of the screens and they didn’t match the brand.

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.

I thank Abhinav Chhikara, Mayank Khandelwal, Saurabh Soni, and Razorpay Design for giving me this as the capstone project as a part of the 10k Designers Masterclass.

Thank you for reading till the end! Did you know? You can hold that clap button for a few seconds to give a maximum of 50 Claps. I would really appreciate it. See ya!

Read my other case studies & articles:

• Masterclass for Scribld Creative — A UX/UI Design Case Study
• Community App for Kara and Nate — A UX/UI Design Case Study
• GenX and WhatsApp — A UX Research Case Study
• Building your Portfolio in Notion: Part 1
• More coming soon…

Designing Bunch Payout of RazorpayX was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sad that you don’t know about web development? Find it confusing to use Webflow or WordPress to build your website? Still struggling to build your digital portfolio? Then you have landed at the perfect place!! 😉

This article is a step-by-step process to building your portfolio in Notion. There are many possible layouts for your portfolio in Notion. For this article, I made the layout as close as possible to my personal website. Feel free to explore and experiment. Want to discuss or have any queries? Reach out to me at ramakrushna.design@gmail.com

Disclaimer: Since Notion is not a website building platform, there are certain limitations in the website designs that you can make such as limited font choices, default dark mode, custom domains, etc. Some of these limitations can be overcomed by using 3rd party applications. However, with what’s available at hand now, we can make wonders.

Warm Up!! 🥶

What is Notion?

Notion is an all-in-one workspace application that provides components such as databases, kanban boards, wikis, calendars, and reminders. Users can connect these components to create their own systems for knowledge management, note-taking, data management, project management, among others. The best part — it’s free to use.

Dissecting a portfolio

You are free to add anything to your personal website but you should have these 4 sections at the minimum in your portfolio — introductory section, about you, your works & case studies, and contact information.

Let’s get started!! 🎉🎉

What you see above is my personal website as of Dec. 2020. As mentioned earlier, we will be creating the Notionfolio(portfolio made in Notion) similar to that of my personal website. The whole process is divided into the following 4 parts for easier understanding:

1. Home Page
2. Case Study Page
3. About Page
4. Linking the Pages and Getting the URL

What each section talks about is pretty much explanatory from the section name itself. 🙃

I — Home Page

The home page of the website has three sections — The introductory section, the Works section, and the contact section. Before beginning, we need to set up the workspace.

• Visit notion.so, create your free account, get started with a free personal space, and delete all existing templates

• Rename your workspace to whatever you like(this step is optional btw!!)

• Make the page full-width

Your workspace is ready! Let’s start building. 🥳

a. Introductory Section

This section has a brief introduction about you — who you are, what you want to do, and what you do.

• Begin with changing the page name and adding your photo/emoji

• Select H2 block and put a one-liner about you

• Select Text block and write a short description about you. Create a partition and give some spacing.

• Create a Callout block and share your current job status — working at …., looking for …., etc.

b. Works Section

Well, the section name says it all! This section showcases all of your selected works.

• Begin by creating a Heading (H1 block) saying “My Works/ My Projects”

• Create a Gallery-Inline block and name it whatever you like.

• Add properties in one of the cards (The changes will be reflected in the others as well)

• Change the gallery properties to the following ⬇⬇

• Add images and other details to properties of the cards

• Click on Add and add the number of cards you need

c. Contact Section

This is where people who interested in connecting with you get your contact details. Some of the steps involved in building this section are similar to the ones discussed earlier, feel free to skip them. ⏭

• Start with creating a Heading (H1 block) saying “Contacts”. Select Text block and write a short description about what you like to discuss and talk about. Create a partition and give some spacing.

• Select H2 block and put your email-id

• You can add your social media links by creating Callout blocks, stack the blocks side by side, and add links of your social media handles to the text (Protip: You can use social media icons instead of emojis for a better experience)

• Link your email-id by selecting your email text, hitting the link button, and typing “mailto:email-id”

Hurray! You just completed your first page. 🥂

II— Case Study Page

This is where you have detailed case studies of your selected works. For this page, you can take either of the two approaches or a combination of both.

a. Approach 1

If you have published your case study on Medium, you might want to redirect the viewers to that page instead of showing the case study in the Notionfolio.

• To do this, add a new property to the card named “Note”, and put a note to click the medium link to view the case study

OR

b. Approach 2

If you haven’t published your case study on Medium, you can show the case study in the Notionfolio. Use the different blocks that are available to build your case study in Medium.

However, if you want you can combine both of these approaches and showcase your case study.

III — About Page

The about page has information about you. What you want to add and how much detailed you want it to be, totally depends on you.

• Start by creating a new page, renaming it, and adding your emoji (a short liner too, if you want)

• Create an Image block and add your photograph

• Select H1 block and put your full name. Using Text blocks, put information about yourself (Use different text styles and colors that fits you)

• Copy and Paste the contact details from the Home Page

95+% of your portfolio is ready. Exciting!! ✨✨

IV — Linking the Pages and Getting the URL

What’s a digital portfolio without a URL? — Nothing! In this section, we will connect the different pages and get the final URL of the portfolio site.

• Hit the Menu in the top Share and Publish to Web on the top right and Allow Share to Web. Disable “Allow Duplicating” if you don’t want others to duplicate your site. Click Copy Link and there you have the link to the About Page.

• Go to Home Page and Paste the link in the introductory section. Click Link to Page

• Hit Enter and write Resume in the next line and add the link to your resume to that text.

• Follow step-1 and you have the link to your portfolio site

— — — — — Congrats!! You made it.🎊🎊

Wrap Up 💝

This was one layout that I made for this article, you can create your own too — all you have to do is explore and experiment. You can supercharge your notionfolio using a third-party application such as super.so and Frutionsite.

Here’s the link to my Notionfolio: https://www.notion.so/Hey-I-m-Rama-Krushna-53ebad1b8bb04bd491108cac9c293be9

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.

Building your portfolio in Notion was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

A personal group project on designing a community app for the YouTube content creators — Kara and Nate

In this case study, I have described my process of designing a community app for Kara and Nate. In this project, we worked as a team, ideating, and brainstorming solutions to design an app that lets the Youtubers to interact with their community. This was a project that I had worked on as a part of the 10k Designers Masterclass.

• Project Duration: 2 weeks (Sept. 2020)
• Platform: iOS
• Team: Rama Krushna, Devesh, Sahil, Shradha, Ansh, Shrey

🎫 Background

Kara and Nate are a couple from Nashville, Tennessee who started in January 2016 with a goal of traveling 100 countries by 2020. Make video blogs (vlogs) about their travel and have 1.78 million subscribers on their YouTube channel with around 740+ videos. They use different platforms for streaming their content, posting their blogs, and keeping in touch with the community members.

😣 Design Problem

Kara and Nate are travel vloggers who traveled across the globe as a part of their journey. As a part of their daily schedule, they have to travel, shoot, and edit videos for publishing. The majority of their travels are funded by Patreon Members, Course Sales, and YouTube ad revenues. They also post blogs on their website to attract viewers for their content. Since their profession depends on traveling, it is crucial for them to keep in touch with the community members and build a relation. Due to traveling, it becomes hectic to be focused on their daily tasks and be in touch with the community. This project was an approach at uniting different jobs they performed into a single platform.

🎯 Tackling Problem

With the problems in mind, we brainstormed and gathered solutions for solving the problem. Before starting wireframing, we had many team discussions to decide what solution(s) would work in this case. In a nutshell, the solutions that we decided on were:

• Single App uniting the work of different platforms
• In-app YouTube video player
• Categorized content display
• External links to Patreon site and Online courses

How might we build an interactive community platform for the YouTube content creators — Kara and Nate such that they do not have to switch to different platforms while interacting with their community?

❓ Who, What, and Why?

• Who are ‘Kara and Nate’?

A couple from Nashville, Tennessee who started in January 2016 with a goal of traveling 100 countries by 2020. Make video blogs (vlogs) about their travel and have 1.78 million subscribers on their YouTube channel with around 742 videos. The couple achieved their goal of traveling to 100 countries in February 2020. Now they are traveling within the United States and posting vlogs about it.

• Home - Kara and Nate
• Kara and Nate

• What kind of content they produce?

The video content that they produce for their channel is Semi-Formal, Informative, and Joyful. Apart from the videos, they also write blogs on travel hacks, credit cards, and their income, and have got their own Travel Hacking and Video Editing course hosted on teachable. They are also planning to start their own newsletter.

• Why are we creating the app?

Kara and Nate have a diversified audience from different walks of life. Currently, they have:

1. A YouTube Channel for people to watch their videos and travel experiences
2. A website where they post blogs related to travel hacks, credit cards, and income report
3. A private FB group for Patreon members to interact with the community

It is difficult to keep track of different digital platforms and be productive while traveling. Moreover, some of these platforms are major contributors to their income.

The app is created with an idea to unify the purpose that is being served on different platforms, thereby increasing productivity without hampering their incomes.

💠 Addressing the Influential Criteria

After gathering basic information, we conducted research to address some of the major criteria that would influence the design and structure of the app.

👨🏻 Who are our Audience

From the research, we divided the target user group who will be using this app into three archetypes —

1. Travelers: People who have already traveled and are traveling to various locations
2. Travel Enthusiasts: People who have not traveled or have traveled to some nearby places only but are planning to travel in the future
3. Casual Consumers: People who watch their videos or consume their content because they find it to be interesting and have no intentions of traveling

🔍 Other Findings

• Logo: Initials ‘K’ and ‘N’, and ‘&’ and illustration of a globe, with a cross formed by 2 airplanes
• Video Intros: Logo reveal on a coffee cup followed by episode number, country number, and location

• Income Sources (in decreasing order):
  a. Patreon
  b. Course Sales
  c. YouTube Revenue
  d. Affiliate Marketing
  e. Video Licensing

💡 Brainstorming & Prioritizing

Based on the research, we used the insights gained to prioritize features and decide on what to include and what not to include based on the MoSCoW framework.

🌍 The Sitemap

Having the features listed out, we discussed, decided, and iterated on how to distribute the content and features across different screens and what should be the flow of screens in the app taking into consideration different types of users.

🔨 Wireframing & Copywriting

Having decided the flow and distribution of content across screens, it was time to experiment and try out different layouts to see what fits. After multiple iterations and discussions, we came up with a set of wireframes that had proper layout fitting to serve the purpose of the app.

After the wireframes, we discussed the kind of language that should be used in the app. We decided to use semi-formal and joyful language so that it reflects their brand personality.

📱 Visual Design

|| Style Guide

• We decided on using Circular STD because of its minimal and modern design, which is what we wanted as the visual language of our app.
• From the multiple color palette that we decided on, we planned on using one with Brown, Beige, Green, and B&W colors. This was planned from the coffee mug that is used as a signature in their videos.
• Since it was planned, the app would have many images, so we were restricted to a limited color palette. And hence the majority of our visual design will be using B&W colors.

|| Onboarding

• While keeping in mind that our targeted users will be coming from Facebook, Youtube, and Patreon and taking into consideration that Kara and Nate, who travel frequently and have less time to manage the database, we decided to include 3 three options to signup in to the app.
• Also, keeping in mind that some users might hesitate to login without checking out the app, we included a “Continue as guest” option, which also had certain restrictions like commenting & liking on a video or a blog.

|| Home

Our main goal for the home screen was to keep the existing fans/users to be updated with the latest content while also help new users to discover content with personalized and curated playlists.

• The topmost carousel contains the latest content: recent vlogs and blogs, which take users directly to a video player or the blog page.
• Further, the content is organized via countries while showcasing the most-watched ones on the feed.
• By keeping personalized and curated content in mind, the users can also find the content similar to what they just watched or read.

|| Video Player

|| Exclusive Content

Our main goal behind the exclusive content screen was to have everything centralized in the app itself.

• As previously mentioned, a part of the users came from Patreon, which involved perks like exclusive monthly live Q&A and Behind the scenes.
• We observed a big flaw, which was to get these perks; users have to use Facebook groups for any exclusive interaction — in contrast, making Patreon act like nothing but a payment gateway for fans to support the creators.
• All the premium members were then allowed to access the live Q&As and the past live videos. Apart from that, users can also see behind-the-scenes.
• We also decided to include an early content section that gave the app an overhead over the existing youtube

|| Other Screens

Video feed & Country-wise content screen:-

• We decided to dedicate the video feed screen to provide the most personalized and curated content via various playlists and sections.
• Once the user selects the country-specific playlist, he will then be landed on the country-wise content screen, which further divides the content into more subsections and playlists related to the respective topics.

Blogs feed & blog screen:-

• The blog feed screen consists of two parts that are the category tabs, which also have badges to highlight the latest content.
• The second part is the discovery section, where content is then split into various filters such as the latest blogs, most viewed, and tending blogs.
• Once the user selects the specific blog card, the blog page is shown where the user can complete reading the article.

💻 Website Design

A website that communicates the value of the app

We chose to keep it simple and minimal. We browsed through many other similar websites and found some common design patterns.

Based on the gathered insights and inspiration we decided on adding the following to the website-

• Hero Image and CTAs at the top and bottom
• Describing the purpose that the app serves
• Frequently Asked Questions
• Social Proof

Taking these into consideration, we designed the website for Kara and Nate that showcased the necessity of the app.

🎮 Prototyping

After making the visual design we moved on to make the prototype for the app. We used Figma for building the interactive prototype for the app.

🎁 Takeaways

• Solid research always forms the base of the project. Without proper research, everything falls apart.
• Collaboration is very much important. It gives room for more ideas and helps in taking collective design decisions.
• Design is not design without iteration. One needs to iterate multiple times and experiment to find out what works best.
• Communicate. What you think is not what others think, the intention of your decision might not be always clear to others. One has to communicate effectively to share their ideas.
• No one knows everything. One has to learn many new things every time he/she works on a new project.

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.

I thank Abhinav Chhikara for giving me this assignment providing valuable feedback as a part of the 10k Designers Masterclass.

Special thanks to Rahul Bhosale for providing helpful insights and feedback throughout the project.

Thank you for reading till the end! Did you know? You can hold that clap button for a few seconds to give a maximum of 50 Claps. I would really appreciate it. See ya!

Community App for Kara & Nate— A UI/UX Design Case Study was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Masterclass for Scribld Creative — A UI/UX Design Case Study

A personal project on designing an iOS app for an ed-tech startup in the field of Creative Arts

In this case study, I have described my process of designing an ed-tech app — Scribld Creative. In this project, I built a design system and designed for edge cases while solving user needs. This was a project that I had worked on as a part of the 10k Designers Masterclass.

❓ Problem Statement

How might we design a seamless and hassle-free online learning experience for people who want to learn Creative Arts?

🎈 Solution

In order to build a seamless and hassle-free online learning experience for people who want to learn Creative Arts, I designed a mobile app with user needs and business goals in mind.

Scroll down to know more ⬇⬇⬇

🎫 Background

With the outbreak of the COVID 19 pandemic, almost everyone in the world was staying indoors. There had been a huge rise in the number of Zoom meet-ups and Live streams. People were looking for new ways to socialize online- whether that’s to meet their friends or to meet new people. Under this situation, it was predictable that for the next few months the “events” were going to be conducted outline. With this in mind, the startup — Scribld Creative aimed at creating a digital platform where people can pursue their interests and learn more in the field of Creative Arts.

👑 Understanding the Brand

Scribld Creative is a media and ed-tech startup which aims at educating people in the field of Creative Arts. The motto of the startup is to create a shared understanding among people through creative art. The startup is planning to get professionals from various domains of creative art — ranging from cinematography to design to fine arts. The professionals will be spread across various locations throughout the country and they aim at reaching an Indian audience (in initial stages) of self-motivated people who are interested to learn new things in the creative field. They are planning to launch the product as early as possible so that they can reach a larger audience due to COVID 19 scenario (where people who have more leisure time are interested in learning more).

📱 Need for an App

The secondary research that I conducted in order to understand the methodologies and features adopted by apps in this domain suggested that having an app in the initial stages has the following benefits -

• Users can watch wherever and whenever they feel comfortable
• Videos can be downloaded and watched later
• It is easy to keep a track of progress made
• Navigation is simpler as compared to a desktop website

🎯 Target Audience

The startup is focusing on Indian people based in urban areas who are mostly students, working professionals, or homemakers from age groups between 14 years and 40 years, having a decent income and a decent way of living.

👨🏻‍🎨 Creative Arts 101

I conducted some secondary research on understanding the domain. The main findings from the research were:

Creative Arts can be defined as a range of activities and practices that enhance the creative and imaginative skills of a person.

Different types of creative art are:

• Fine Arts
• Design
• Music
• Drama
• Crafts
• Dance
• Cinematics
• Photography

The Brain Benefits of Creative Arts | Alongside You

🧪 User Research

In order to understand the user needs, I had some informal discussions with my friends to are into the field of Creative Arts or are pursuing Creative Arts. The main findings from this were:

• Watching tutorial videos are helpful in short-term but not effective in the long run

• Even though existing platforms provide room for assignment and discussion but they don’t induce motivation in the mind of most of the learners
• Tasks that do not have a deadline are going to continue forever.
• The best way to learn anything in this niche is by following the ‘Learn-Implement-Feedback-Improve’ loop

🕸 Common Design Patterns

I browsed through different apps in this niche and found out the following common design patterns:

• Course-specific discussion forum
• Downloadable video lectures
• Do not ask for a preferred interest
• Provide social proof and syllabus of course content
• Provide one(or a few) lessons for free
• Mandatory fees payment
• Skippable onboarding
• Provide recommended viewing
• Payments are either Subscription-based or Course-based

😠 Pain Points

After conducting the research and analyzing the information gained throughout the process, I enlisted the major pain points that the users are facing. The major pain points were:

• Lack of motivation
• Inability to complete the assignments
• No proper feedback is received
• Even if the feedback is received, it is only once
• Platforms lack engagement. Very few discussions in the forum
• Forget what they have learned after a few days

👨🏻‍🏫 Teaching Methods

Based on the insights gained from primary and secondary research, I ideated the teaching curriculum and methods for the startup.

• Pre-recorded lectures on generalized topics
• Live lectures for important topics (with available recordings)
• Fixed course curriculum
• Live interactive sessions
• Open-ended assignments with feedback from instructors
• Lifetime access to course content
• Limited-time period for course completion

♾ Converting Action to Habit

Learning is a continuous process. In order to make the most out of the platform, it is essential to make learning a habit. I designed the flow following Fogg’s behavioral model which states that

Behaviour = Motivation + Ability + Prompt

💡 Ideation

Before proceeding to build the sitemap and the wireframes, I ideated and prioritized features for the app. The features were:

• Calendar to show the scheduled live events
• Virtual points to encourage the user to enroll in more courses
• In-course discussion forum
• Cohort based learning
• Active interaction with instructors and colleagues
• OTP based Mobile number login (primary)
• Downloadable Course Content
• Pay for the course only

⛓ Sitemap

Taking the features I ideated and insights gained from research into account, I built the sitemap for the app.

🔨 Wireframing

I iterated on the wireframes for the app to come up with layouts that serve the essential features of those pages without hampering the user experience.

After making rough sketches, I moved to Figma where I iterated with several different layouts for the screens as well as screen components.

🤵🏻 Branding

I explored different logo symbol and wordmarks for the startup. After some explorations, I chose one that represented the idea of Scribld Creative — Every idea starts with a scribble. It follows a path from imperfection to perfection.

🎨 Style Guide

From the wireframes, I chose a few crucial screens and experimented with different color combinations and typeface combinations.

• Since it is an educational app and users will spend more time staring at the screen, I decided on making the UI in the dark mode so that there are no eye strains and users can use the app for a longer time.
• For the colors, I choose the primary color to be ‘Purple’ as it gives a creative and inventive vibe. Darker shades of purple were used for dark backgrounds. ‘White’ served as a neutral color for the texts and other necessary elements

• I iterated in different font combinations before settling for ‘DM Sans’ as the heading font and ‘Inter’ as the body font. DM Sans was chosen as it gave a non-serious and friendly vibe and Inter was used due to its clean and modern ligatures.

• I planned on using consistent icons with smooth corners so that they match with the personality of the product

• I used an illustration library for the illustrations. The chosen library had illustrations that depicted the niche Creative Arts and were more user-friendly.

⚓ Component Library

Since in this project, I had planned on designing for edge cases soI started building a component library through an iterative approach. Throughout the project, the major components were added to the library.

✨ Visual Design

I iterated different layouts and used the component library to fasten the process. Then I designed different screens(taking into consideration the edge cases as well) for the app. I iterated and improved upon the visual designs based on the numerous feedbacks that I received.

• Onboarding

Simple and Interactive onboarding for user delight. Added animations in the onboarding flow to reduce drop-off and grab users' attention to sign up for the product.

• Sign Up/Login using Mobile Number

• OTP based sign up and login using a mobile number as it is a common sign up flow in the Indian context. This 3-step reduces time and allows for smooth signup/login.
• Sign up and login through email for users who are more tech-oriented and familiar with emails. This process is short and fast to maximize user retention.

• App Walkthrough

Simple and minimal walkthrough showing the essential features of the app to the first time users.

• Home

Generalized home screen for first-time users and personalized home screen for returning and regular users to maximize user retention. Home screen contents are in descending order of priority. Course List screen shows courses under a particular topic.

• Search and Calendar

• Search page to easily browse courses and instructors across various categories. Categories in the default state of the search page make it easier to browse courses across a particular domain.
• Calendar to keep track of live classes and be alert.

• Course and Instructor Details

Provides details and information about the course and instructors. Also, has a free preview of certain videos of a course and the FAQs.

• Enrolled Courses

Shows enrolled courses and also has downloaded course section if the user wants to watch the videos later.

• Checkout

Easy checkout flow to allow users to enroll for a course.

• Notifications and Account

• Get notified and not miss any change in schedule or any other important detail.
• Get detailed feedback from mentors and improve upon the works
• Keep a track of learnings and achievements throughout different courses. Also, can change app settings and refer a friend from here.

• Designing for Edge Cases

After building the main flow, I designed the edge cases for different screens taking into account the possible use cases.

To view more such edge cases and access the Figma file, mail to ramakrushna.design@gmail.com

🔗 Prototype

After completing the visual design, I prototyped the app in Figma.

🎁 Takeaways

There major learnings for me during this assignment were:

• Creative Arts can’t be learned through traditional methods of watching tutorials. Practice and feedback are much needed.
• I understood the importance of iterating for real needs. There 100 possible ways to design a screen, but only a few of them will work. Iterating gives an idea of what are those layouts would work and which one should fit for my product.
• Designing for edge cases. How to take into consideration different edge cases while designing a product.
• Using constraints to design responsive screens.

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.

I thank Abhinav Chhikara for giving me this assignment providing valuable feedback as a part of the 10k Designers Masterclass.

Special thanks to Rahul Bhosale, Sneha Sankar, Abheyraj Singh, Mayank Khandelwal, and Janardhan Massar for providing helpful insights and feedback throughout the project.

Thank you for reading till the end! Did you know? You can hold that clap button for a few seconds to give a maximum of 50 Claps. I would really appreciate it. See ya!

Read my other case studies:

• GenX and WhatsApp — A UX Research Case Study
• More coming soon…

Masterclass for Scribld Creative — A UI/UX Design Case Study was originally published in UX Planet on Medium, where people are continuing the conversation by highlighting and responding to this story.