Building the foundation for consistency across enterprise experiences
Overview
This project focuses on the centralization of Accenture’s enterprise design systems within the larger Data & AI Studio, a network of 200+ designers. The goal was to build a unified, accessible, and scalable design foundation that could replace fragmented libraries, reduce redundancy, and ensure consistency across enterprise products.
Organization
Accenture Song
Role
UX Designer
Duration
2 months
Team
2 UX Designer + 1 Design Manager
What I Did
Audited existing design systems to identify overlaps, accessibility gaps, and opportunities for consolidation.
Designed and standardized key components to establish a cohesive, scalable foundation across enterprise products.
Collaborated cross-functionally and created documentation to align developers, designers, and stakeholders around shared standards.
IMPACT
50%
reduction in redundant components across projects
150+
Components and tokens
Global Playbook
Accenture wide playbook foundation
Background
Systems Within Systems
As part of our work at Accenture Song, we were tasked with a full redesign of an enterprise data platform within the larger Data & AI Studio, an ecosystem of 300+ teams and partners.
Visualization showing how multiple design systems existed in parallel — layered, disconnected, and inconsistent, with no single foundation for teams to rely on.
The platform was pulling from multiple design systems, each with conflicting styles and rules. This wasn’t unique, across the Studio, teams often pieced together their own mini systems, leaving products fragmented and inconsistent.
We turned this gap into an opportunity to build a unified design foundation for the entire Studio, one that could scale, support accessibility, and sustain continuity across projects.
Problem
Lack of a Unified system
The lack of a single standard design system created both inconsistency and inefficiency:
Multiple internal competing libraries with clashing rules
Each project building its own “one-off” system → duplication everywhere
Fonts, icons, colors, and forms lacked standards and consistency across larger team
Accessibility wasn’t embedded → color contrast failed, forms broke for screen readers
Extra work at every handoff → teams wasted time rebuilding systems instead of focusing on the product
The challenge was to replace this patchwork with one unified, accessible, and scalable design system, eliminating rework, reducing confusion, and enabling smooth collaboration across teams.
“Every time I start a project, I’m pulling components from three different libraries and half the time, I still can’t find what I need.”
- Designer, Accenture Data & AI Studio
“We just added a new business domain, but there’s no single place to find components. Nothing matches what we already have.”
- Designer, Data & AI Studio
Beyond Components
What It Takes to Build a System
Even though we were designing the system, we knew that building components was only part of the work. Design systems at enterprise scale aren’t just libraries, they’re ecosystems that require continuous effort to stay alive.
Meetings & Alignment: Constant syncs across 300+ teams to secure buy-in
Audits: Reviewing existing products to consolidate duplicates and close gaps
Maintenance: Updating components as projects evolved and needs changed
Cross-Team Communication: Translating design rationale into language developers and stakeholders trusted
This invisible but critical work was what ultimately made adoption possible.
Research & Benchmarking
Not Reinventing the Wheel
Before making decisions, we studied Material, Carbon, Fluent, and other industry systems.
Benchmarked leading systems — Nielsen Norman Group, Carbon, Fluent, Material — and guidance from design system leaders to shape our approach.
Examined their grid systems, spacing scales, typography rules, and accessibility practices
Borrowed best practices where they fit (e.g., Material icons, 8pt grid system)
Documented rationales for every choice, so even new team members could understand the “why”
This ensured the system felt familiar and adoptable, not foreign or disruptive.
The Design System
Building a Shared Foundation
Once we identified the gaps, our focus shifted to creating a central design system that could replace scattered project libraries with a single, consistent foundation. This wasn’t just a set of components, it was a structured system guided by clear principles:
Consistency → every component, from type to icons, aligned to a common grid and spacing rhythm.
Accessibility → contrast ratios, target sizes, and form semantics were baked in from the start.
Scalability → the system was lean enough to be adopted across multiple projects without bloat, but flexible enough to evolve with future needs.
Clarity in Use → rules and documentation explained not just what to use, but when and why.
This unified system became the foundation that allowed teams to design faster, hand off work more smoothly, and build with confidence. From here, we dove into the specific building blocks, typography, iconography, colors, buttons, and forms, applying these principles to each.
Components covered in this case study
Typography
Iconography
Colors
Buttons
Tables
Form Fields
Dark Theme vs. Dark Mode
Across Accenture’s external profiles and websites, there was a clear shift toward an all-black theme that reinforced the brand identity. However, within enterprise products, there was noticeable hesitation to move entirely in this direction. Many of these platforms were data-heavy, and stakeholders worried that a full dark theme could compromise readability, scanability, and user comfort during long working sessions.
This created an ongoing debate: should our platform adopt a dark theme by default, or should we enable dark mode as an option while keeping light as the standard?
Accenture.com’s external sites leaned into a dark theme, while enterprise products often stayed light — creating clear disparity.
Our approach
Designed all components with dual-mode support, ensuring they could function in both light and dark contexts.
Chose light mode as the default to support data-intensive use cases, while providing a dark mode option for scalability and brand alignment.
Documented design tokens for both modes, embedding accessibility checks into each.
Light vs. Dark Mode Options
Why this works
Balancing brand direction with product usability ensured the system was future-proof. Light remained optimal for enterprise workflows, while dark mode allowed flexibility and consistency with Accenture’s broader design language.
Typography
Typography in enterprise platforms often spirals out of control: too many weights, arbitrary sizes, and inconsistent usage.
Our approach:
Established a clear hierarchy of headings (H1+, H1, H2, H3, H4), ensuring only one H1 per page and enforcing correct nesting for subcategories.
Defined four heading levels to enforce hierarchy and reduce inconsistency.
Standardized paragraph text styles at three core sizes — P16, P14, and P12 — each with semibold variants to provide emphasis without introducing unnecessary new styles.
Standardized paragraph text into three core sizes (P16, P14, P12), each with semibold variants.
Included special styles such as Eyebrow14/16, Labels, and Highlight treatments for flexibility in emphasis and information hierarchy.
Established dedicated styles for Eyebrows, Labels, Highlights, and Inline Links.
Defined 16px as the minimum body size (with 13px as an absolute floor) to preserve accessibility and readability.
Documented guidance for alignment (avoid excessive centered or right-aligned text) and punctuation (sparingly in headlines/subheads).
Why this works
By enforcing a rigorous, documented hierarchy, we reduced inconsistency and ensured text always remained legible, accessible, and on-brand.
Iconography
Icons on the platform had mixed origins and unclear meaning. Some came from Material, others were custom, and many had no traceable source. Styles clashed, some were filled, others outlined, some pixel-perfect, others blurry.
To make things worse, the system contained entire sets of decorative icons (e.g., “business type” icons) that added no functional value. This created confusion and wasted visual real estate.
Our approach
Conducted a requirement-first audit, reducing 100+ icons to 50 essentials.
Standardized on Material Symbols (24dp grid; 20/40/48dp variants).
Applied style rules: outlined by default, filled only for high-priority actions.
Removed icons with unclear or redundant meaning.
Ensured interaction targets met accessibility: 48dp for touch (Material) or 24×24 CSS px minimum (WCAG).
Adopted Material Icons as the base, with customized rules for fill/outline use. (Full library not shown due to NDA.)
Why this works
A smaller, standards-based set eliminates noise while ensuring icons are recognizable, purposeful, and accessible across contexts.
Colors
Color usage was inconsistent and often inaccessible. Purple and gray dominated, while yellows failed to meet contrast ratios in both light and dark modes. Without documented guidance, teams improvised palettes, resulting in interfaces that looked dull in some places and unreadable in others.
Our approach
Introduced cooler neutrals to balance vibrancy and reduce visual fatigue in data-heavy contexts.
Added swatches and states (hover, focus, active, disabled) as tokens, so interactive elements were always accessible and consistent.
Corrected yellows and other tones to pass WCAG AA+ contrast (≥4.5:1 text, ≥3:1 large/UI).
Accessible red, amber, and green defined for error, warning, and success states.
Expanded the palette while keeping it lean and purposeful, preventing the overuse of decorative or redundant colors.
Neutral greys tuned for accessibility and consistent background/application use.
Why this works
By grounding the palette in brand colors but addressing accessibility and variety gaps, we created a system that was both on-brand and usable at scale, turning color from a liability into a foundation for clarity.
Buttons & Tables
Interactive elements like buttons and tables had grown bloated and inconsistent. Buttons came in too many shapes, paddings varied, and minimum touch targets weren’t enforced. Tables, meanwhile, had rigid structures that didn’t adapt well to different use cases, forcing users to scroll endlessly or lose sight of key comparisons.
Our approach
Buttons
Defined a clear primary/secondary/tertiary hierarchy with distinct use cases.
Enforced minimum target sizes: 48dp for touch (Material), 24×24 CSS px minimum (WCAG).
Standardized spacing using the 8pt grid system to maintain consistency across layouts.
Different button styles and states defined to create a consistent component library.
Tables
Observed that rows stayed fairly consistent (10-15), but columns varied widely depending on the dataset.
Redesigned tables to flex at the column level, enabling responsive behaviors such as freeze, scroll, and column toggles.
Followed Material Design and NN/g patterns to support core table tasks: find, compare, edit, and act.
Showcasing two approaches to building tables: fixed rows vs. flexible columns. Column-based design proved more practical and widely used.
Why this works
By anchoring buttons to grid-based rhythm and making columns fluid while rows stayed consistent, we created predictable yet adaptable interaction patterns. This improved usability in data-heavy contexts without overcomplicating design.
Form Fields
Form fields were among the most inconsistent and inaccessible elements. Labels sometimes appeared inside inputs, helper text shifted unpredictably, and error states were not programmatically announced. For users relying on keyboards or assistive technologies, this broke the flow entirely.
Our approach
Required labels before/above inputs for screen reader predictability.
Standardized helper/error text placement and programmatic announcement.
Created consistent validation and error-handling patterns.
Explored label placement inside, below, and above text boxes. Finalized above-field labels so screen readers announce them before input.
Why this works
Predictable, accessible form structures remove cognitive friction and ensure usability across input methods, mouse, keyboard, or assistive technology.
Outcome
A Centralized Design System Playbook
The result was not just a design system but a shared foundation:
5+ projects adopted the system immediately
Component library was 50% leaner
Teams reduced rework and inconsistency dramatically
Documented into a Design System Playbook, a central “house” that teams could build from instead of starting fresh
Takeaway
Less is More - The biggest impact came not from adding new components, but from removing redundant ones.
Accessibility is Non-Negotiable - Contrast, tab order, and minimum sizes aren’t extras — they’re core.
Scaling Design = Politics as much as Pixels - Success required just as much negotiation and documentation as it did visual craft.
Hear From My Team
More
Due to NDA restrictions, the visuals from my work at Accenture are limited and masked. Feel free to reach out for more details.