Cardinal Design System
A SINGLE SOURCE OF TRUTH FOR DIGITAL DESIGN AT TRANSAMERICA.
Ever-evolving product, providing framework agnostic components, patterns, usage, styles and code to align the design and development of our digital products.
Leadership & management | UX Design
Role and contribution
I was the design lead and individual contributor for the Cardinal Design System. My goal for leading this team was to “systemize”, improve documentation and governance.
Managed 4 designers and 2 UI developers to transition from a centralized pod to a distributed model
The design system served 7 digital products across Transamerica’s product ecosystem
Conducted research, audits and iterative design to foster adoption and increase efficiency
Background
The Cardinal Design System provided the product teams with the freedom to tackle unique, challenging problems without having to recreate the wheel each time.
It started off as a style guide, inherited from an outsourced company. Symbols were nested and robust, but there was not a system encompassing it nor was there a connection to the nature of our products and Transamerica brand.
The system evolved into the Digital Design System (DDS), where a few designers allotted efforts as a side project. The team would later become a dedicated Pod known as the Cardinal Design System, equipped with a Product Owner, Scrum Master, Design Lead, 2 - Designers, Development Lead, 2 - Developers, and a Technical Copywriter.
Opportunity
With 7 products across multiple surfaces, there were gaps in UI alignment. This became an opportunity to create our own guidelines for design that proactively incorporate previously established Brand and Digital Standards.
Challenges
Despite much evangelism and support by designers and engineers, digital leadership struggled to see the value in dedicating an entire team to focus on design systems. The Cardinal Design System project was defunded, transitioning the centralized pod into a federated model, impacting scope and bandwidth.
Leadership & management
Methodology
Systematize
The design system needed improvements in documentation and the catalog. Rethinking navigation and creating a shared language would allow our system to have a broader reach and adoption.
Document
As simpler components were built out, there was a growing need for more complex patterns. Taking inventory of current elements in play across our products helped us to visualize connections and create more cohesion across components with varying complexity.
Governance
The system was working for those who used it. Some designers felt the Cardinal team was the “design police,” while others were less aware of the existence or robustness of the design system. More inclusive processes and recurring share-outs helped to combat this.
Backlog & prioritization
Taking the existing backlog and identifying new needs in Align & Refine Wednesdays allowed me to present component options and opportunities to designers. From there, I would assign the design task to a Guild designer, and track visually.
Rethinking processes
When the team switched to a federated model, the process of design to development shifted and needed to include Guild checkpoints, as all designers would become contributors. Development hand-off would shift as well to the developers on dedicated product pods.
Contributing components
Research
• What are you are designing?
• Is it new or improved?
• Any dependencies?
• Is this needed by other pods?
Design
• Use existing symbols & styles
• Nest where possible
• Does it scale?
• Are there variants?
Validate
• Is it accessible?
• Has this been tested?
• Did you have an ICR?
• Is it technically feasible?
Document
• Be explicit
• Usage: Content, Behavior,
Motion, Do’s and Don’ts, etc.
• Style: Specs, Anatomy, states
Design
Audits & visual inventories
Audit and Inventory processes had low participation. Documentation often lacked consideration for the business of the product pod these components would surface on. Creating a visual inventory gave a collective view of similar patterns and behavior so that I could dig in to align and identify needs.
Distilling into requirements
Once the visual inventory was complete, I would compile the different behaviors or variants of
an potential component into a spreadsheet, where pods could identify if and when they would need the component. From here, the component or set of components gets added to the backlog as a story or epic, depending on the size.
Component - Contextual Details
It seemed that across all of our digital products, the term “disclaimer” was being universally used to describe numerous behaviors and UI patterns. I asked designers to send in screenshots of their “disclaimers” so that I could assess all use cases. What I discovered and deduced was 5 different patterns, all different in levels of complexity and criticalness.
Results & Impact
Though business needs led to the defunding of the centralized pod, we still found a way to support ur designers as the users of the design system, while they contributed to their product areas in parallel. Our new federated model made us more inclusive of designers and disciplines outside of the design system pod, and in turn, helped us to build better products.