Skip to content

Experience Design Director | 3 – 6 Months

Enterprise Design System: Crown Resorts

When starting at Crown, the teams worked from large Figma files that served multiple large products. This led to huge files hitting Figma file size limits, complex findability of recent designs, and a lack of source of truth.

The Enterprise Design System for Crown Resorts was created to tackle and resolve significant issues in the company’s design and development processes and outcomes. Crown Resorts encountered problems with inconsistent designs across products and channels, redundant design and development elements, and prolonged design times. As the Design Director, I managed the entire process from discovery to implementation, ensuring alignment and efficiency.

— The Process

Discovery

Team Workshops
Data Analysis
Heuristic Evaluation
Content Audit

Ideate

WOW Flow Diagrams
File Structure Architecture

Design

Style and Tokens libraries
Component Libraries
Product Template Framework

Validate

Quantitative Data Analysis
Retrospectives

— Discovery

The content team, designers, and developers discussed various issues during the retro meeting. The content team pointed out their main concern about the inflexibility of the content management system. Despite having a wide range of components, they need more influence in implementation. The lack of flexibility forced them to resort to “hacks” to achieve their goals, creating messy and inconsistent pages that affected the user experience and design. The developers also highlighted their challenges, including style inconsistency, high maintenance efforts, a backlog of bugs, and various design requests. Designers were frustrated by the complexity of design files and the need to understand the latest and most accurate design information.

While collaborating with the CMS development team, we conducted thorough audits to examine how often components were being used. This assessment revealed several low-value, redundant, and duplicate functionality components. This pointed to a problem with components being designed and developed in isolation, without consideration for existing components or those created by other teams.

An audit of live products revealed common inconsistencies in spacing, colour, fonts, and layout. Furthermore, many colours were off-brand. Some of these issues stemmed from designers not implementing style guides and existing components, while others resulted from components not aligning with the supplied designs.

— Stakeholder management and Quantifying results:

Project managers and owners hesitated to invest time and effort in a new design system without new features. With evidence of much frustration with design-related problems and significant overhead on maintaining components, we were able to move forward by focusing on one product first. Key metrics were observed to monitor the rollout’s success and help provide a case for extending the design system to an enterprise level. These metrics included:

  • The frequency of design bugs was logged in Jira and found during random design audits of live products (quant data).
  • Monitoring content authors’ creation experience, including authoring times and experience feedback (quant/qual data).
  • Monitoring design experience, including design times and experience feedback (quant/qual data).
  • Tracking retro issues, including front-end and design-related issues (quant/qual data).

— Design Architecture

The structure was carefully designed with future growth in mind, focusing on enterprise-level needs. The core library (main brand) was used across all brands and was consistently active for all team projects. Sub-brand libraries were essential for allowing branding rules and tokens to override styling rules in component libraries. These were strategically divided into sub-brands to streamline token usage and minimise issues with cross-brand token usage.

The component libraries were tailored for different product touch-points, allowing design teams access according to their requirements. This approach kept libraries smaller and simplified usage for the product teams, providing only the necessary components.

Product feature folders were treated as works in progress (WIP) files, with sections for research, definition, wire-framing, UI designs, showcase/prototypes, and component WIP pages. This structure improved the organisation of design files.

— Design Process

Only Design System Designers had edit access to the system files, while product teams and developers had view and development rights for the files. This approach supported effective tracking and managing component library changes, ensuring consistency.

The Design Systems team collaborated closely with product teams in the early stages of creating or enhancing components. After final approval, the design systems team transferred the new component, validating its designs and functionality. Once finalised, it was handed over to developers in build.

We collaborated closely with the developers to improve the handover process. The design system served as the ultimate reference for all developed components, removing the need for work-in-progress files and establishing a robust development handover. The developers organised their Storybook according to the atomic structure and naming conventions. By implementing Chromatic, we could track updates and changes comprehensively, empowering designers to conduct thorough and rapid design quality assurance. This ensured that every component underwent meticulous audits for design and functionality.

— Design Libraries

All components were overhauled and restructured entirely from the ground up, starting with style elements and tokens, followed by components. Core brand tokens were implemented first to ensure consistent spacing of fonts and colours across brands.

Sub-brands focused on specific elements, creating themes and collaborating with brand teams to align colours and accessibility, including new colour variants to meet accessibility standards.

I create a component library based on atomic design principles (atoms, molecules, and organisms). The components were designed to closely resemble the live version at various screen sizes, using variables, variants, and auto-layout. The main objective was to enable rapid design and make these components flexible enough to meet any requirement without detaching them.

Components pages were structured to provide guidance on inherited components, spacing rules, and front-end and content authoring functionality and behaviour, giving designers and developers all the necessary information to use the components.

Design template files were set up with a clear structure for research, definition, wireframes, UI, and showcase (prototypes). A components work-in-progress (WIP) was included as part of the workflow to hand over new or updated components to the design systems team.

— Outcome

The implementation of the Enterprise Design System yielded significant improvements. Design efficiency increased, with the average t-shirt sizing dropping by 42%, design time for similar features reduced by 74%, and new functional features by 28%. Live front-end and content authoring bugs were reduced by 48%. Design audits showed a 98% reduction in released design issues, with critical issues becoming non-existent.

Positive feedback from designers and content authors highlighted increased flexibility and speed. Development efficiency improved with reduced component overhead, bug fixing, and a consistent handover process.

The iterative rollout, continuous feedback, and collaboration with all teams ensured a successful implementation, aligning everyone towards a unified design system that supports scalability and efficiency. These results led to the continual expansion of the system product teams

This project underscored the importance of a structured, iterative approach in developing an enterprise design system, balancing technical capabilities with user needs to deliver a comprehensive and effective solution.