35 pharmacy configurations, three applications, one shared design system.
VytlOne brought multiple pharmacy experiences into a shared digital platform spanning desktop, mobile, and tablet. As the sole product designer and design-system owner, I was responsible for creating the experience architecture, reusable system, responsive interactions, and production-ready product designs that allowed the platform to scale without turning every pharmacy brand into a separate product.
Role
Senior / Lead Product Designer
Design Ownership
Sole Product Designer
Responsibilities
VytlOne is a white label, multi tenant pharmacy platform built as three applications, desktop, mobile, and tablet, running on one shared design system. That system supports 35 pharmacy brand configurations rather than 35 separate products.
The screens throughout this case study are shown as they appear for real pharmacy operators. Desktop and mobile are white labeled for Apicha Community Health Center. Tablet is white labeled for JPS Health Network.
Each pharmacy brand needed to retain its identity while the underlying experience needed to behave consistently. At the same time, healthcare workflows required clarity, accessibility, reliability, and careful handling of complex information.
The Design Problem
How do you create one coherent product system that can support multiple pharmacy brands without forcing every brand to reinvent the experience?
The desktop application, white labeled for Apicha Community Health Center.
Instead of designing each experience independently, I looked for the shared structures, behaviors, and patterns that could become the foundation of the platform.
Shared Experience Architecture
The underlying structures, states, and interaction patterns common to every pharmacy brand on the platform.
Design System
Reusable components, tokens, and patterns built once and inherited everywhere.
Brand Layer
Client variable tokens carry each pharmacy operator's identity without forking the underlying experience.
Desktop / Mobile / Tablet
The same architecture, expressed through the interaction model each device actually supports.
Customer Experience
What the pharmacy customer or patient actually sees, uses, and depends on.
I was responsible for the product design experience across the platform rather than owning one isolated feature. My responsibility extended from product structure and interaction decisions through visual design, reusable components, responsive behavior, prototypes, engineering collaboration, and production validation.
Sole Ownership, Shared Responsibility
Sole ownership did not mean designing in isolation. I worked collaboratively with Product, Engineering, business stakeholders, and healthcare and pharmacy stakeholders throughout. The product design responsibility itself was mine.
The design system was not a side project. It became the mechanism that allowed the product to scale. I established and evolved the design system as its owner.
Reusable Foundations
The Product Decision
Separate experience behavior from brand expression.
Shared components and interaction patterns could remain consistent while brand level styling could adapt the experience for different pharmacy clients.
Explore the System
This is not a recreation or a retrospective diagram. This is the actual design system work used to shape the product.
Every component is built with client variable tokens: font, color, and radius change per pharmacy brand, the component doesn't.
The challenge was not building 35 unrelated design systems. It was creating one shared component architecture that could support 35 pharmacy brand configurations while keeping the underlying product experience consistent across all of them.
Figma Variables and Modes made that possible. Shared components stayed part of one system rather than being copied per brand. Brand specific values, such as color and type, could change according to the selected pharmacy mode, and that mode changed the visual expression of the component system for that pharmacy without changing the underlying component.
The Architecture Decision
One shared system, 35 pharmacy configurations, not 35 separate design systems.
Same Components, Different Pharmacy Configuration
Figma Variables and Modes controlled pharmacy specific values across the shared component system. Changing the selected configuration changed the system's visual expression without requiring a separate component library.
The same component specification is shown below under two configurations, VytlOne and Apicha, with the Variables panel visible showing the selected mode. The specification also carried each component's interaction states, default, hover, focus, and disabled, as part of one shared definition rather than separate copies per brand.
VytlOne Configuration
Apicha Configuration
This comparison shows the mechanism using two of the 35 configurations. The interactive prototype below remains the broader evidence for the full set of pharmacy configurations.
VytlOne Platform
The single product experience shared by every pharmacy brand on the platform.
Shared Design System
One component library and set of interaction patterns, not a separate system per brand.
Shared Components
The same components used everywhere, built once rather than rebuilt per brand.
Figma Variables and Modes
Brand specific values attached to each component through a Figma mode, rather than a separate copy of the component.
35 Pharmacy Configurations
The same components, expressed through the selected pharmacy brand mode.
A Shared Reference Across Roles
The same system served as a common product reference across design, development, product, stakeholders, sales, accessibility, and QA, rather than a resource used only by designers.
Explore the Configurations
Move through the shared design system across all 35 pharmacy brand configurations directly, rather than relying on a written description of how it adapts.
Explore the shared VytlOne design system across all 35 pharmacy brand configurations.
The design system was not a theoretical Figma library. It was used to build the actual product. The components, tokens, and interaction patterns shown above appear directly in the application that follows.
The application needed to make pharmacy workflows understandable to customers without exposing unnecessary operational complexity.
Important Themes
Explore the Product Design
Inspect the actual desktop product design directly, rather than relying only on selected screenshots.
The account portal, white labeled for Apicha Community Health Center: refills, transfers, and pharmacy locations.
Responsive design here was not a matter of resizing screens. Each device changes what the experience needs to prioritize, from available space and navigation to touch interaction and content density.
Desktop
Full pharmacy experience with room for richer information architecture and parallel task visibility.
Mobile
Focused task execution with tighter prioritization and touch first interaction.
Tablet
A middle context requiring both efficiency and clarity without simply reproducing desktop.
Because this was healthcare, accessibility and usability needed to influence reusable patterns rather than be applied as a final audit.
Accessibility scales when the system scales it.
Addressed at the Component Level
When accessibility is addressed at the component and pattern level, individual product experiences inherit better behavior rather than forcing every screen to solve the same problem independently.
The component specification shown earlier in this case study carried interaction states, default, hover, focus, and disabled, as part of one shared definition. That specification supports systematic interaction states across the platform. It does not, on its own, demonstrate WCAG conformance.
Consistency
vs.
Brand Flexibility
Every pharmacy brand needed to feel distinct to its own customers, while the underlying experience needed to behave the same way regardless of which brand a customer was using.
Resolution
Standardize behavior and reusable interaction patterns while allowing controlled brand expression.
Power
vs.
Patient Simplicity
The platform needed to support complex pharmacy operations, transfers, and account management, but a patient managing a refill shouldn't have to understand any of that complexity to complete a simple task.
Resolution
Keep operational complexity behind the experience wherever possible and expose only the information and decisions customers need.
Desktop Depth
vs.
Mobile Focus
Desktop had room for parallel information and deeper account management. Mobile needed to get a specific task done quickly, on a much smaller surface.
Resolution
Preserve the task and information hierarchy rather than forcing identical layouts across devices.
Speed
vs.
System Quality
New client brands and features needed to ship quickly, but speed that fragmented the design system would have made every future feature slower to build.
Resolution
Use reusable components and patterns to increase delivery speed without allowing individual features to fragment the experience.
Patient Simplicity
vs.
Operational Requirements
A customer should not have to understand the internal complexity of a pharmacy system simply because the system needs that complexity to operate.
Resolution
Progressive disclosure, sensible defaults, and clear hierarchy reduced unnecessary cognitive load in the refill flow, so a customer who already knows they need a refill can complete it in as few steps as possible.
A customer who already knows they need a refill gets it in as few steps as possible.
I remained involved through engineering collaboration, implementation review, design QA, responsive validation, accessibility review, and continued evolution of the design system.
Implementation constraints sometimes required design adjustments, but the goal was to preserve the user outcome rather than defend a static mockup.
Product Need
A workflow, task, or brand requirement enters the platform.
Design
The experience and interaction model are defined against the shared architecture.
System
New patterns are built into or reconciled with the design system rather than designed as one offs.
Engineering
Implementation surfaces real technical and platform constraints.
Validation
Design QA, responsive validation, and accessibility review confirm the built experience.
Iteration
The experience and the system evolve together as the platform grows.
These figures describe the platform-wide transformation across three years, not outcomes attributable to any single feature such as One Click Refill. Individual features contributed to the experience; the metrics reflect the system as a whole.
I was the sole product designer and design-system owner, but the product itself was built collaboratively with Product, Engineering, business stakeholders, and the broader organization.
The work resulted in more than a collection of desktop, mobile, and tablet interfaces. The shared architecture and design system created a foundation that allowed the product to remain coherent across pharmacy brands, workflows, and devices.
The goal was not to design every screen the same. It was to make every experience feel like it belonged to the same system.
A successful design system is not measured by the number of components in a library. It is measured by whether teams can use it to create better, more consistent products without working around it.
An Accessibility Operations Platform for managing accessibility work from assessment through delivery.
Another platform where accessibility lived in the underlying pattern library rather than a final audit, the same system-level approach applied here.