Building a Scalable Design System for Healthcare Products
Role
Research, Systems thinking, Design System, Developer Collaboration
Team
Sai Dheeraj, Akhil Ram
Industry
Healthtech
As IKS Health added more healthcare products, keeping things consistent got harder. Two teams would build the same kind of component, say a status card, and end up with different spacing, different states, different rules for when it expanded. Do that across many products, and the small differences pile up quickly. Nothing breaks all at once. It just quietly stops matching.
So we built a scalable design system, one that's accessible, flexible, and made to support the platform as it keeps growing.
Identifying the oppurtunity
When I joined IKS Health, I noticed the same problem coming up again and again: designers and developers making exceptions because the design system couldn't keep up with what the products needed. Components got rebuilt or tweaked for one-off cases so often that products started looking inconsistent, and delivery slowed down as a result.
As the company kept adding healthcare products, I raised this with my Design Director and Manager. Together, we kicked off a rebuild, not just a patch, meant to give teams one shared design language, stronger accessibility, and a system that could actually keep up as the product line grew.
Challenges
Multiple Products, One Experience
Clients often used multiple IKS products together, including MyCareHub, Scribble, Denial Prediction, and Pre-Op Visit. Every product needed to feel like part of the same ecosystem.
Multiple Development Teams
Different engineering teams built different products. A shared component library and clear documentation reduced implementation inconsistencies and improved collaboration.
Accessibility by Default
Healthcare products served users across a wide age range. Every component was designed with WCAG accessibility guidelines in mind, emphasizing readability, contrast, and usability.
Parallel Product Development
Product development couldn't pause while the design system was being built. We developed both in parallel, continuously introducing reusable components as products evolved.
Built to Scale
The system wasn't created for one product—it was designed to support future healthcare products, new workflows, and evolving business requirements.
Ready for Future Growth
Although initially built for US healthcare products, the system's foundations were designed to support future expansion and new markets without redesigning core patterns.
We sat down with operational teams across different healthcare functions to see how they actually put together reports for leadership. Every conversation surfaced new KPIs, different formats, different terminology, Each one shaping the dashboard a little more.
Discovery & Audit
We didn't start by designing new components. We started by figuring out what already existed.
Every product team had solved the same problems in its own way. Buttons looked different from product to product, tables behaved differently, and each team had its own take on common UI patterns. Before adding anything new, we needed to know what was actually working and what was causing the inconsistency.
Old Design system
Few existing product UI designs
Component Inventory
(Methodology: Component Audit)
We asked every product team to send over the components they were already using: buttons, tables, filters, charts, steppers, navigation patterns, all of it. The goal wasn't to rebuild everything from scratch, it was to keep what already worked and figure out where it could be standardized.
Product Review
(Methodology: Product Audit)
We went through multiple healthcare products to see how each one had solved the same problems in its own way. That surfaced two things: where consistency broke down, and which interaction patterns users kept running into again and again.
Engineering Alignment
We talked to developers before locking in design decisions, not after. Some dashboards were still built in Tableau, so interactions and animations had real limits. Those conversations helped us build a system that worked for designers but also held up once it hit different technologies.
Finding the Patterns
Once we had all the components together, we started grouping the similar ones. We compared layouts, interactions, spacing, tables, charts, and navigation to figure out what should be shared across products and what should stay specific to one. Those patterns became the foundation for the new design system.
Design principles
Consistency
Every product should feel like part of one healthcare ecosystem
Accessibility
Built for users across all age groups following WCAG standards
Scalability
Components should support future healthcare products without redesigning
Simplicity
Reduce unnecessary decisions for designers and engineers
Reusability
Build once, use everywhere
Developer Friendly
Predictable variants, naming and documentation
Foundations
Color system
Typography
Spacing, Radius and Shadows
Work in progress
I'm currently documenting the remaining process and will be publishing the complete case study soon.
Work in progress
I'm currently documenting the remaining process and will be publishing the complete case study soon.
Building a Scalable Design System for Healthcare Products
Role
Research, Systems thinking, Design System, Developer Collaboration
Team
Sai Dheeraj, Akhil Ram
Industry
Healthtech
As IKS Health added more healthcare products, keeping things consistent got harder. Two teams would build the same kind of component, say a status card, and end up with different spacing, different states, different rules for when it expanded. Do that across many products, and the small differences pile up quickly. Nothing breaks all at once. It just quietly stops matching.
So we built a scalable design system, one that's accessible, flexible, and made to support the platform as it keeps growing.
Identifying the oppurtunity
When I joined IKS Health, I noticed the same problem coming up again and again: designers and developers making exceptions because the design system couldn't keep up with what the products needed. Components got rebuilt or tweaked for one-off cases so often that products started looking inconsistent, and delivery slowed down as a result.
As the company kept adding healthcare products, I raised this with my Design Director and Manager. Together, we kicked off a rebuild, not just a patch, meant to give teams one shared design language, stronger accessibility, and a system that could actually keep up as the product line grew.
Challenges
Multiple Products, One Experience
Clients often used multiple IKS products together, including MyCareHub, Scribble, Denial Prediction, and Pre-Op Visit. Every product needed to feel like part of the same ecosystem.
Multiple Development Teams
Different engineering teams built different products. A shared component library and clear documentation reduced implementation inconsistencies and improved collaboration.
Accessibility by Default
Healthcare products served users across a wide age range. Every component was designed with WCAG accessibility guidelines in mind, emphasizing readability, contrast, and usability.
Parallel Product Development
Product development couldn't pause while the design system was being built. We developed both in parallel, continuously introducing reusable components as products evolved.
Built to Scale
The system wasn't created for one product—it was designed to support future healthcare products, new workflows, and evolving business requirements.
Ready for Future Growth
Although initially built for US healthcare products, the system's foundations were designed to support future expansion and new markets without redesigning core patterns.
We sat down with operational teams across different healthcare functions to see how they actually put together reports for leadership. Every conversation surfaced new KPIs, different formats, different terminology, Each one shaping the dashboard a little more.
Discovery & Audit
We didn't start by designing new components. We started by figuring out what already existed.
Every product team had solved the same problems in its own way. Buttons looked different from product to product, tables behaved differently, and each team had its own take on common UI patterns. Before adding anything new, we needed to know what was actually working and what was causing the inconsistency.
Old Design system
Few existing product UI designs
Component Inventory
(Methodology: Component Audit)
We asked every product team to send over the components they were already using: buttons, tables, filters, charts, steppers, navigation patterns, all of it. The goal wasn't to rebuild everything from scratch, it was to keep what already worked and figure out where it could be standardized.
Product Review
(Methodology: Product Audit)
We went through multiple healthcare products to see how each one had solved the same problems in its own way. That surfaced two things: where consistency broke down, and which interaction patterns users kept running into again and again.
Engineering Alignment
We talked to developers before locking in design decisions, not after. Some dashboards were still built in Tableau, so interactions and animations had real limits. Those conversations helped us build a system that worked for designers but also held up once it hit different technologies.
Finding the Patterns
Once we had all the components together, we started grouping the similar ones. We compared layouts, interactions, spacing, tables, charts, and navigation to figure out what should be shared across products and what should stay specific to one. Those patterns became the foundation for the new design system.
Design principles
Consistency
Every product should feel like part of one healthcare ecosystem
Accessibility
Built for users across all age groups following WCAG standards
Scalability
Components should support future healthcare products without redesigning
Simplicity
Reduce unnecessary decisions for designers and engineers
Reusability
Build once, use everywhere
Developer Friendly
Predictable variants, naming and documentation
Foundations
Color system
Typography
Spacing, Radius and Shadows
Work in progress
I'm currently documenting the remaining process and will be publishing the complete case study soon.
Work in progress
I'm currently documenting the remaining process and will be publishing the complete case study soon.
Building a Scalable Design System for Healthcare Products
Role
Research, Systems thinking, Design System, Developer Collaboration
Team
Sai Dheeraj, Akhil Ram
Industry
Healthtech
As IKS Health added more healthcare products, keeping things consistent got harder. Two teams would build the same kind of component, say a status card, and end up with different spacing, different states, different rules for when it expanded. Do that across many products, and the small differences pile up quickly. Nothing breaks all at once. It just quietly stops matching.
So we built a scalable design system, one that's accessible, flexible, and made to support the platform as it keeps growing.
Identifying the oppurtunity
When I joined IKS Health, I noticed the same problem coming up again and again: designers and developers making exceptions because the design system couldn't keep up with what the products needed. Components got rebuilt or tweaked for one-off cases so often that products started looking inconsistent, and delivery slowed down as a result.
As the company kept adding healthcare products, I raised this with my Design Director and Manager. Together, we kicked off a rebuild, not just a patch, meant to give teams one shared design language, stronger accessibility, and a system that could actually keep up as the product line grew.
Challenges
Multiple Products, One Experience
Clients often used multiple IKS products together, including MyCareHub, Scribble, Denial Prediction, and Pre-Op Visit. Every product needed to feel like part of the same ecosystem.
Multiple Development Teams
Different engineering teams built different products. A shared component library and clear documentation reduced implementation inconsistencies and improved collaboration.
Accessibility by Default
Healthcare products served users across a wide age range. Every component was designed with WCAG accessibility guidelines in mind, emphasizing readability, contrast, and usability.
Parallel Product Development
Product development couldn't pause while the design system was being built. We developed both in parallel, continuously introducing reusable components as products evolved.
Built to Scale
The system wasn't created for one product—it was designed to support future healthcare products, new workflows, and evolving business requirements.
Ready for Future Growth
Although initially built for US healthcare products, the system's foundations were designed to support future expansion and new markets without redesigning core patterns.
We sat down with operational teams across different healthcare functions to see how they actually put together reports for leadership. Every conversation surfaced new KPIs, different formats, different terminology, Each one shaping the dashboard a little more.
Discovery & Audit
We didn't start by designing new components. We started by figuring out what already existed.
Every product team had solved the same problems in its own way. Buttons looked different from product to product, tables behaved differently, and each team had its own take on common UI patterns. Before adding anything new, we needed to know what was actually working and what was causing the inconsistency.
Old Design system
Few existing product UI designs
Component Inventory
(Methodology: Component Audit)
We asked every product team to send over the components they were already using: buttons, tables, filters, charts, steppers, navigation patterns, all of it. The goal wasn't to rebuild everything from scratch, it was to keep what already worked and figure out where it could be standardized.
Product Review
(Methodology: Product Audit)
We went through multiple healthcare products to see how each one had solved the same problems in its own way. That surfaced two things: where consistency broke down, and which interaction patterns users kept running into again and again.
Engineering Alignment
We talked to developers before locking in design decisions, not after. Some dashboards were still built in Tableau, so interactions and animations had real limits. Those conversations helped us build a system that worked for designers but also held up once it hit different technologies.
Finding the Patterns
Once we had all the components together, we started grouping the similar ones. We compared layouts, interactions, spacing, tables, charts, and navigation to figure out what should be shared across products and what should stay specific to one. Those patterns became the foundation for the new design system.
Design principles
Consistency
Every product should feel like part of one healthcare ecosystem
Accessibility
Built for users across all age groups following WCAG standards
Scalability
Components should support future healthcare products without redesigning
Simplicity
Reduce unnecessary decisions for designers and engineers
Reusability
Build once, use everywhere
Developer Friendly
Predictable variants, naming and documentation
Foundations
Color system
Typography
Spacing, Radius and Shadows
Work in progress
I'm currently documenting the remaining process and will be publishing the complete case study soon.
Work in progress
I'm currently documenting the remaining process and will be publishing the complete case study soon.
More works
Think of all the cool stuff, We could accomplish together
All rights reserved.
Created by Sai Dheeraj
Think of all the cool stuff, We could accomplish together
All rights reserved.
Created by Sai Dheeraj
Think of all the cool stuff, We could accomplish together
All rights reserved.
Created by Sai Dheeraj