Overview
Shesha had been in development for nearly 10 years. As it prepared to become its own independent company, the product's outdated UI was holding it back—giving users and potential clients a poor first impression of what was actually a powerful low-code platform.
Shesha had been in development for nearly 10 years. As it prepared to become its own independent company, the product's outdated UI was holding it back—giving users and potential clients a poor first impression of what was actually a powerful low-code platform.
CLIENT
Shesha
YEAR
2024
DELIVERABLES
Design Tokens Component Library Documentation Design Files
ROLE
Product Designer
Impact
Achievements
Since the Design system's rollout we've seen a steady rise in GitHub engagement from the developer community.
Shesha's interface now matches the quality of the platform underneath it, giving the product a stronger, more professional first impression.
Developers now work from a single source of truth, which has cut down on back-and-forth and made design-to-development handoff noticeably smoother.
Problem
Brand Guidelines Without a System
When I joined, the team had brand guidelines and a UI Kit that documented fonts, colours, component styles, and input styles.
However, These were constructed several years ago. As it prepared to become its own independent company, the product's outdated UI was holding it back. This was giving users and potential clients a poor first impression of what was actually a powerful low-code platform.
While it defined how the UI looked, it lacked:
Approach
Understanding the Mess
We divided and conquered—conducting a full audit of Shesha's existing UI and evaluating how it impacted the overall user experience. We ran usability tests and held in-depth discussions with developers to understand their pain points.
What we found:
A surprising disconnect: Visual debt masked platform strength
Here's what surprised us; when we showed the same feature set in a modern interface mockup to potential users, their perception of Shesha's capabilities improved dramatically. The product wasn't the problem. The UI was. This finding was a turning point: it meant we didn't need to redesign functionality, only refresh its presentation. That realisation shifted our entire strategy from "rebuild everything" to "modernise what works."
Outdated visual trends
The UI felt stuck in 2015, giving users the impression the product was below standard—even though the underlying platform was powerful.
Inconsistent design language
Too many contributors over the years meant inconsistent fonts, typography, spacing, and iconography across the platform. The worst part wasn't any single choice, but the cumulative cognitive load on users navigating between different visual systems.
Limited icon library
The existing icons couldn't support Shesha's custom components, forcing designers and developers into awkward workarounds. We were using generic icons for domain-specific actions, which further muddled clarity.
Good news: Many original components were actually well-designed and reusable. We didn't need to reinvent everything, just modernise and systematise what already worked.
Solution
A Shared System Teams Could Actually Use: Modernised component library
The result was the company's first design system since launching as an independent company. It is currently being used across web, mobile and internal tools. It standardised core interactions and visual foundations while remaining flexible enough for growth within Shesha and the product needs.
Enhanced existing Ant Design components with Shesha's visual language. Avoided unnecessary rework by keeping what already worked well.
Unified typography & colour system
Standardised fonts, type scales, and colour tokens to eliminate inconsistencies across the platform.
Bespoke icon library
I proposed and led the creation of a custom icon set specifically designed for Shesha's unique components and use cases.
Conclusion
Key Takeaways: What I Learned
Not everything needs to be rebuilt from scratch.
We avoided unnecessary rework by identifying what already worked and modernizing it instead of starting over.
Constraints breed creativity.
Shesha's technical limitations forced us to think creatively about component design and iconography, which ultimately made the system stronger.
Design systems are never done.
They evolve with the product. The best systems are built to adapt, not to be static.
This was my first experience contributing to a design system at scale, and it taught me how to balance design ideals with technical realities. Working closely with developers helped me understand the importance of building components that are not just beautiful, but practical and maintainable.
I also learned that good design systems aren't about perfection—they're about creating a shared language that helps teams move faster and more confidently.
Other projects
