Rethinking the Bottom Sheet component
Designers were forced to detach instances, developers rebuilt from scratch, and accessibility was overlooked. This case study shows how I redesigned the bottom sheet to solve these inefficiencies end to end
About Nykaa
Nykaa is India’s go-to destination for beauty and lifestyle shopping. From skincare to fashion, it brings thousands of brands together across app, web, and stores—making it easier for people to discover, learn, and buy what they love
Context
Nykaa’s current design system faced several challenges:
Each brand relied on its own UI kit, creating duplication and inconsistency.
While the system was fairly strong on web, iOS and Android lacked equivalent support, forcing teams to build locally.
It also lagged behind modern Figma capabilities, making it difficult to evolve with new features.
This made it clear we needed a second-generation system built for consistency, cross-platform parity, and scalability.
Every component would be rethought, but I’ll use the Bottom Sheet to illustrate this journey. As a complex and widely used component, it surfaced many of the system’s shortcomings and became the perfect lens to show how the new system solved them at scale.
Challenges: Why the old bottom sheet was holding us back
Designer Pain Points
Broken Component API
Master component API was broken - Certain variant combinations were missing, causing unexpected behaviour when props are applied in Figma. This made it unusable at times, leading to detaching instances
Prop names were not intuitive as well (such has inline meta, action etc.)
No theming support
The bottom sheet existed in three separate UI kits, forcing designers to rebuild it, especially for platform level projects.
Since content was managed through instance swap, additional effort was required to migrate a design to different ui kit
Engineering Limitations
No iOS/Android Support, Only Web
Without engineering support on iOS and Android, teams had to build their own versions of the Bottom Sheet — resulting in duplicate effort, design–dev mismatches, and longer QC cycles. Since certain atom components didnt exist as well, it created a domino effect
Design and Code are not coherent
The component in Storybook often doesn’t match the component in Figma, leading to inconsistencies between design and development. These differences cause misalignment, extra communication overhead, and rework
Accessibility issues
No screen reader or keyboard support
The modal lacks proper accessibility controls — screen readers skip the 'modal-open' state and move directly into content. Focus indicators are missing or broken, making it difficult for users to track their current position within the modal
Foundational a11y issues
Although not entirely related to bottom sheet, certain foundations like icon button, color, heading tags lacked accessibility controls. This further created a domino effect in complex components like Bottom Sheet
Tackling the gaps, one at a time
Challenge #1
Lack of theming forced duplicate components (not just Bottom Sheets) across UI kits, making cross-platform design slow and inconsistent.
Complexity
Low
Effort
High
Utlised variable-based tokens with Primitive and Semantic layers to increase consistentency
Primitives (e.g., pink-600, slate-500) were aliased to semantic tokens (e.g., text.default, icon.disabled) to clearly convey intent and ensure consistency.”
Semantic tokens themed to multiple brands
After creating semantic tokens for Nykaa Beauty, I added multiple modes by mapping them to the appropriate primitive values.
Challenge #2
Rigid, use-case–specific architecture with poor API and restrictive slots reduced reusability and scalability
Complexity
Mid
Effort
High
Improved the component API to accommodate use cases consistently without breaking the component
Redesigned the component API by introducing boolean and text props, reducing the need for multiple variants while covering previously unsupported use cases. This streamlined the component structure, improved usability, and ensured consistent implementation across platforms.
Edit slots directly inside the component without local components or detaching instance
Designers can now edit slot content directly through "Integrated slots"—without creating local components—mirroring how it works in code and greatly improving the component’s usability and flexibility
Baked animation into the components turning a flat bottom sheet into a lively one
By integrating animation and smooth transitions into atomic components, the Bottom Sheet evolved from a static organism into one with depth and dimensionality, creating a more polished and immersive user experience.
Challenge #3
No accessibility support left the Bottom Sheet unusable for differently abled users
Complexity
High
Effort
High
Established a process for designers to clearly convey accessibility tags to engineers, ensuring accurate implementation
With the annotation kit, designers could tag elements (e.g., heading, alt-text, aria-labelledby, role), enabling developers to seamlessly integrate accessibility into code.
Challenge #4
No engineering support on iOS and Android led to duplicate builds, mismatched designs, and extended QC cycles
Complexity
Mid
Effort
Low
Component was built in all platforms and connected to Figma via Code Connect
Every component was unified across Web, iOS, and Android. We went further by mapping component code to Figma props, enabling developers to preview exact code directly in Dev Mode (and even in VS Code). This meant that any differences in props could be mapped accurately without any guesswork. Code connect files were authored and maintained by me
Bringing it all together
Building bottom sheets just got easier…
Adjust style based on use case, edit content directly within the component, inherited transitions - all in one
Theming in action…
not just colors and corner radius, even icons switch seamlessly
Before vs After - A quick snapshot of improvements
Here’s a comparison of the Bottom Sheet component ‘Before’ and ‘After,’ highlighting improvements across performance, accessibility, theming, and slot configuration for better usability.
BEFORE
Total Variants
89
Missing variants?
Yes
WCAG Compliant?
No
Theming available?
No
Slot config
Instance Swap
AFTER
Total Variants
4
Missing variants?
No
WCAG Compliant?
Yes
Theming available?
Yes
Slot config
Integrated slots
How did these changes make an impact?
As part of our initial beta, we decided to migrate our old onboarding flow to the new system. Certain metrics like design time, development time, QC time and visual coverage were tracked throughout the process.
Time to design
from 1 week to 3 hours
92.5%
Time to develop
from 2 weeks to 1 week
50%
Time to QC
from 2 days to 1 day
50%
Visual coverage
from 30% to 100%
3.33x
Next steps
This isn’t over yet—the Bottom Sheet component is still evolving. To prepare it for a GA release, a few key steps were planned:
Conduct crit sessions to gather feedback on future use cases not yet captured in the current component API.
Ensuring the Bottom Sheet and other components cover all relevant use cases from crits, supported with central web-based documentation.
Set up playground files to help designers onboard quickly and provide confidence scores while exploring the new component.
Fin.
🚀
Like what you see?
Let’s build something great together