Return to work

Open to work

Return to work

Open to work

ShareFile Design System

From complex to cohesive. Our journey building a design system that made ShareFile more accessible, faster, and future-proof.

Timeline

10 months

Tools

Figma, Supernova, Storybook

Role

Principal Product Designer

Team

Oleksiy Kvasnhchenko, Aaron Penny, Douglas Goodman, Shawn Horner, Alex Boyd, and Josh Trauberman

Overview

ShareFile was in the midst of a major transformation. Having previously operated under the Citrix umbrella and relying on Citrix’s Juice Design System, ShareFile was now establishing itself as an independent business unit within the Cloud Software Group. At the same time, the company was undergoing a full-scale rebrand to reposition itself as a leader in secure work management solutions. This organizational shift created a unique opportunity and necessity to build a dedicated design system that reflected ShareFile’s new identity and could scale with its product strategy.

Problem statement

ShareFile’s design foundation was fragmented. The product team relied on a limited subset of legacy components from Citrix’s Juice design system, which no longer reflected the evolving product vision or the needs of a newly rebranded business unit.

Issues

• Designers recreated components inconsistently across files.
• Engineers had no clear guidance for implementing UI in code.
• Accessibility standards weren’t enforced systematically, putting key enterprise sales opportunities at risk.
• The new brand identity had no formal presence inside the product, creating visual disconnects between marketing and product experiences.

Goals

• Establish a scalable design system.
• Achieve WCAG 2.2 AA compliance.
• Improve development efficiency.
• Launch a centralized documentation site.
• Bridge brand and product.

Phase 1: Audit & discovery

The foundation of a successful design system starts with understanding the landscape you’re designing for. During the audit & discovery phase, I led a cross-functional effort to analyze ShareFile’s existing UI and system infrastructure to uncover gaps, redundancies, and opportunities.

Component inventory & UI audit

We kicked off with a full audit of the current product UI across the web app, which included areas such as signature requests, document requests, files and folders, and projects. Steps included the following:

•. Cataloged existing UI components and identified whether they were components in the system, custom code, or duplicates.
• Identified patterns used inconsistently across teams.
• Mapped components and patterns that were used and how heavily they had been customized.
•. Documenting edge cases or “one-off” designs that created unnecessary complexity in implementation.

Cross-team interviews

After completing the system audit and reviewing existing patterns, I met with Product Design, Engineering, and Product Management to validate findings, uncover pain points, and align on priorities for the new design system.

Lack of flexibility

Existing component library was too rigid, both in Figma and in code. This lack of flexibility led to frequent one-off solutions, causing inconsistencies and added dev effort.

Undefined usage guidelines

There were no clear usage standards or documentation for when and how to use components, resulting in inconsistent patterns across design and implementation.

Missing accessibility considerations

Accessibility was not embedded into component design or development, leaving gaps in keyboard navigation, aria-labels, and other accessibility areas to meet the business requirements .

Key outcomes

• Identified 45 necessary components to support the current and future product features.

• Documented misalignment between design and code due to a lack of a shared system.

• Created a prioritized roadmap that aligned with engineering velocity and design capacity.

• Surfaced key accessibility gaps to be addressed in component creation and the documentation site.

Phase 2: Foundations & components

With insights gathered from the audit and stakeholder interviews, Phase 2 focused on building the foundational elements of the new ShareFile Design System, starting with design tokens, then constructing reusable Figma components, and aligning closely with engineering for consistent code implementation.

Colors

Paying homage to the roots of our customers who used ink and paper to complete tasks on a daily bases, we focused on the old and brought it to life with our vibrant accent colors.

Paper

Hex: #FFFFFF

RGB: 255, 255, 255

CMYK: 0, 0, 0, 0

PMS: Coated: White C, Uncoated: White U

Ink

Hex: #0C0D0D

RGB: 12, 13, 13

CMYK: 7.69, 0, 0, 94.9

PMS: Black 6 C

Defining color principles

Use sparingly and intentionally

Flow uses functional coloring that supports products designed to be run on laptops, desktop workstations, and mobile devices. Color is used to communicate, not to decorate. We use color sparingly and intentionally in order to emphasize important information. The color system facilitates all-day use while minimizing visual fatigue.

Flow uses functional coloring that supports products designed to be run on laptops, desktop workstations, and mobile devices. Color is used to communicate, not to decorate. We use color sparingly and intentionally in order to emphasize important information. The color system facilitates all-day use while minimizing visual fatigue.

Utilize color role

We offer a curated palette of colors that are intended for specific roles within Flow. For example, we apply consistent coloring to components such as text, status, buttons, and navigation. This helps users to identify a component and understand its relationship to its environment.

We offer a curated palette of colors that are intended for specific roles within Flow. For example, we apply consistent coloring to components such as text, status, buttons, and navigation. This helps users to identify a component and understand its relationship to its environment.

Make it accessibile

When the color system is applied, it will be in compliance with color accessibility standards. We support WCAG 2.2 level AA which requires 4.5:1 contrast for text. We never rely solely on color for communication at ShareFile. Accessibility ensures that our product works for people with visual impairments and improves legibility for all users.

When the color system is applied, it will be in compliance with color accessibility standards. We support WCAG 2.2 level AA which requires 4.5:1 contrast for text. We never rely solely on color for communication at ShareFile. Accessibility ensures that our product works for people with visual impairments and improves legibility for all users.

Pairings

Design tokens

Our design token system is organized into four levels. Base tokens are the lowest level that set the raw value of a token (e.g., #FFFFFF, 8px, and so on). Seed tokens define the core design values like colors, typography, and spacing. Map tokens transform those values into meaningful roles (e.g., colorPrimary, fontSizeBase). Finally, component tokens give an added layer to apply specific tokens to a component for extra customization if needed (e.g., Button, Input, Modal).

#FFFFFF

#6356F6

gray-1

purple-6

$colorTextLightSolid

$colorPrimary

$primaryColor

Flexible components

When building the ShareFile component library in Figma, one of my primary goals was to create a system that was both structured and adaptable, one that preserved core visual and behavioral standards while giving designers the flexibility to work with real-world content and layout variations.

To achieve this, I implemented a slot-based method inside our components. Slots are essentially placeholder areas within a component where designers can swap in various elements, such as icons, labels, or supporting text, without detaching the component from the system. This approach mimicked the flexibility of slot-based APIs in front-end development and gave our design team the power to handle complex UI needs without compromising consistency.

Why slots matter

In real-world applications, UI components rarely exist in a static, one-size-fits-all state. Data can vary. Labels can grow. Elements like badges, icons, or help text may or may not be present. By incorporating swappable slots into components, like a button that accepts an icon or a card that supports dynamic header/footer content, we created a highly flexible framework that allowed for nuanced use cases while maintaining:

• Locked-in structure for layout, padding, and spacing.
• Design-to-code alignment through shared props and naming conventions.
• Consistent interaction states like hover, active, and disabled.

Key outcomes

• Designers could swap content within components without detaching or breaking structure.

• Components remained visually consistent across the product thanks to shared spacing, layout, and states.

• Developer handoffs became faster and more precise, with Figma components mirroring coded props.

• The model scaled well into complex patterns like tables, cards, and empty states.

Phase 3: Documentation & education

With the foundation of tokens and components in place, the final phase focused on ensuring adoption, clarity, and long-term scalability. A design system is only valuable if teams know how to use it and use it consistently. That's where documentation and education came in.

Launching the documentation site

To house the system and make it accessible to all teams, we built a centralized documentation hub using Supernova. This tool allowed us to create a flexible, developer- and designer-friendly space where every part of the system, from core styles to code examples, could live in sync.

• Style definitions (e.g., spacing, colors, tokens, states).
• Usage guidelines (when to use, do's and don'ts, behavior rules).
• Coded examples (mapped to Ant D components and embedded Storybook).
• Accessibility specifications (focus states, ARIA roles, contrast checks, WCAG 2.2 AA guidance).

Driving adoption through education

To support the rollout and encourage healthy usage, I established a consistent feedback loop across teams:

Weekly office hours

Open to both designers and engineers, providing a space to walk through component usage, get help debugging implementation, or explore new needs.

Live walkthroughs

During team rituals and sprint reviews, to introduce updates or clarify guidelines.

Feedback channels

We used Slack to gather suggestions, spot friction points, and evolve the system through communication and new use case explorations.

Key outcomes

• A live, centralized documentation site that serves as the source of truth for ShareFile's design and code libraries.

• Comprehensive documentation for every component, including design tokens, code usage, and accessibility specs.

• Cross-functional buy-in through ongoing education and dedicated support, increasing confidence and reducing friction across the product and technology org.

Lessons learned

No design system is without its challenges. Throughout the process of building ShareFile’s system, I encountered several friction points that helped shape my thinking for how I would approach similar efforts in the future. Here are two key lessons that stood out:

Token complexity can hurt adoption

Ant Design’s token architecture, organized into seed, map, and component tokens offered a powerful way to style components at different levels. However, this structure also introduced unnecessary complexity for designers, especially during onboarding. Early on, many struggled to know which token to use and when, leading to inconsistent usage and confusion within Figma. It became clear that while specificity in tokens offers precision, too much granularity can overwhelm users and slow down adoption. I spent a significant amount of time guiding teams through token usage, creating cheat sheets, and reinforcing naming conventions.

Ant Design’s token architecture, organized into seed, map, and component tokens offered a powerful way to style components at different levels. However, this structure also introduced unnecessary complexity for designers, especially during onboarding. Early on, many struggled to know which token to use and when, leading to inconsistent usage and confusion within Figma. It became clear that while specificity in tokens offers precision, too much granularity can overwhelm users and slow down adoption. I spent a significant amount of time guiding teams through token usage, creating cheat sheets, and reinforcing naming conventions.

What I’d do differently: In future systems, I’d lean toward a class-based or styling hook model that prioritizes simplicity—using generic, reusable tokens like bg-blue or text-blue rather than deeply component-specific tokens. This makes the system more intuitive and encourages cross-component reusability while reducing the learning curve.

What I’d do differently: In future systems, I’d lean toward a class-based or styling hook model that prioritizes simplicity—using generic, reusable tokens like bg-blue or text-blue rather than deeply component-specific tokens. This makes the system more intuitive and encourages cross-component reusability while reducing the learning curve.

What I'd do differently

In future systems, I’d lean toward a class-based or styling hook model that prioritizes simplicity—using generic, reusable tokens like bg-blue or text-blue rather than deeply component-specific tokens. This makes the system more intuitive and encourages cross-component reusability while reducing the learning curve.

Ant Design’s token architecture, organized into seed, map, and component tokens offered a powerful way to style components at different levels. However, this structure also introduced unnecessary complexity for designers, especially during onboarding. Early on, many struggled to know which token to use and when, leading to inconsistent usage and confusion within Figma. It became clear that while specificity in tokens offers precision, too much granularity can overwhelm users and slow down adoption. I spent a significant amount of time guiding teams through token usage, creating cheat sheets, and reinforcing naming conventions.

What I’d do differently: In future systems, I’d lean toward a class-based or styling hook model that prioritizes simplicity—using generic, reusable tokens like bg-blue or text-blue rather than deeply component-specific tokens. This makes the system more intuitive and encourages cross-component reusability while reducing the learning curve.

Prebuilt component libraries create accessibility constraints

Using AntD as our component base helped us move quickly, but it came with trade-offs, particularly around accessibility. Since we didn’t fully “own” the component code, engineers couldn’t easily make the structural changes needed to meet evolving WCAG standards. In several cases, our development team had to wrap AntD components to extend or override behaviors, which added technical overhead and increased maintenance complexity. It also slowed down implementation when we needed to apply specific accessibility attributes or update markup for compliance.

Moving forward

Both of these challenges reinforced a key principle: design systems are living products. They require continuous iteration, team education, and a strong feedback loop to remain useful and usable. I’m proud of how we adapted in real time, and these lessons will directly inform how I approach token strategy, accessibility, and framework decisions in future system builds.

95%

WCAG 2.2 AA compliant

The ShareFile Design System established a scalable, accessible, and brand-aligned foundation for building product experiences. We successfully launched a shared component library in Figma and code, aligned design and engineering through consistent tokens and documentation, and earned our VPAT certification by meeting WCAG 2.2 AA standards, unlocking key enterprise and government sales opportunities.

15%

Reduction in development time

While our initial goal was to reduce development time by 30%, we achieved a 15% reduction, which still marked a significant improvement in efficiency. I believe this shortfall was less about system performance and more about ongoing education and adoption as teams continue to familiarize themselves with the tools, documentation, and workflows. I’m confident that number will continue to improve. Ultimately, we delivered a system that brought structure, clarity, and consistency to how ShareFile builds products and laid the groundwork for even greater scalability moving forward.

Additional case studies

10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read

10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read

10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read

10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read

10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read
10 min read

MANTL account opening

Helping financial institutions and their customers open accounts faster with higher deposits.

Read case study

8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read

8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read

8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read

8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read

8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read
8 min read

Prizmway

A marketplace for creating meaningful agreements and relationships between shippers and carriers.

Read case study