Overview and Context

‍
As part of a team at FanDuel, I was involved in delivering a centralised design system called 'Formation'. Towards the end of the project, a new requirement emerged for a centralised site to host and direct users to all the extensive documentation necessary to implement and effectively use Formation. My role in this project involved leading the design, collaborating with engineers, testing the site with end-users, and writing the majority of the required documentation. The project ran from April to September 2024. Although five months may seem like a long duration, given the extensive content required, we decided that the first iteration would be an MVP (Minimum Viable Product).

Defining the MVP

A reference site typically includes numerous features and functions to help users adopt a design system, such as search functionality, code snippets, and live demos demonstrating component usage. While these are undoubtedly valuable, we did not have the time to deliver everything. 

We conducted a workshop to identify potential features, assigned time estimates from both design and development perspectives, and then held a dot-voting session to determine what should be included in the first iteration of the reference site. The following key features were determined in the workshop:

• Usage guidelines for each component.
• Information on various design tokens and how to adopt them.
• Resources for designers and engineers to get started.
• A section for housing release notes for future updates to Formation.
• Blog Section to drive interest and usage.

Addressing the Need for Additional Features

We knew additional features like code snippets and live demos were important, but we didn’t have the time or resources to deliver these in our MVP. To address this, we included links to the Storybook to meet this requirement without extending development time.

Designs

Based on the workshop mentioned previously, the initial pages I needed to design included:

• Homepage
• Template for Component Usage Guidelines
• Colour, Typography and Spacing Token Pages
• Getting Started Designs
• Getting Started EngineersIcon Pages
• Colour and Colour Usage Documentation
• Release Note Pages
• Blog Templates
• FAQ Page
• Contact Us Page

Competitive Research for Designs

To inform the creation of the reference site for the Formation Design System, I conducted a thorough comparison of the UK Government Design System, Atlassian Design System, and Google’s Material UI Design System. I analysed various aspects, such as content structure and organisation, the clarity of component documentation, and the integration of design tokens. I also evaluated their approaches to accessibility, responsiveness, and the inclusion of live demos and code snippets. This research helped identify best practices for creating a streamlined, user-friendly site that balances comprehensive documentation with efficiency. Features like intuitive navigation, clear usage guidelines, version control, and links to external tools such as Storybook were prioritised to meet the needs of both designers and developers. By studying how these established systems support cross-functional teams, I ensured the Formation reference site would be scalable, accessible, and efficient for its users.

‍
Research to Designs

Homepage

The homepage was designed to function as a directory for the site, rather than serving as a typical introduction to a product or service. Since the design system is an internal tool with an already knowledgeable user base, our priority was to help users quickly access the information they needed. To achieve this, we implemented the following:

A. We placed prominent links to the 'Getting Started' pages for designers and engineers at the top. Since most users would be new to the system, this ensured they could easily find the essential onboarding resources.

B. A section was added to introduce the core areas of the reference site. Each card includes a brief description of the content within, offering more detail than the simple page names found in the navigation bar. This helps users in 'content-finding mode' to better understand where to navigate.

C. The 'Hot Off the Press' section was created to share updates about the Design System. As users become more familiar with the system, they will need a space to stay informed about the latest changes. Placing this section on the homepage ensures that updates are easy to locate for all users.

‍

Component Usage Guides

The purpose of the component usage guide is to introduce each component and provide guidelines on how it should be used across different products. We implemented the following features:

A. Visual Examples in the Hero Image: Each component was showcased within the hero image of the page. This gave a clear visual reference at the start, helping users immediately understand what the page would cover.

B. Resource List: At the beginning of each page, we included a resource list. Since the design system's content is spread across multiple tools and this is an MVP, we couldn’t migrate everything to the site for the initial release. The resource list helps identify what additional content is available for each component.

C. Optimised Content Width: The main content is displayed using two-thirds of the page width, rather than full width. This layout is inspired by patterns seen in online news websites, as users find narrower text blocks easier to read.

D. Visual Guidelines: We included visual examples of both correct and incorrect usage for each component. People generally find it easier to understand guidelines when they can see visual examples rather than relying solely on written instructions.

Token Guideline Pages

The typography guidelines pages were provided to educate the end-user on what they were for each category. They also defined each typography to provide a place where the end-user can look up the tokens and know when to use them.

Token Pages

Colour Tokens

A. Colour tokens display both the semantic and core tokens. By default, we first made the semantic tokens load as 90% of users would need them over core tokens. Core tokens are useful when creating new themes or new semantic tokens need to be made. But only a small percentage of users would do this and therefore we prioritise the needs of the others.

B. Semantic tokens were listed in a table so the dark and light themes could be shown together. A description of each token was given as with the amount of tokens we had, it was confusing to know when to use which token.

C. Core tokens were just listed within a table without any description. This is due to the fact that core tokens have no meaning. They are colours to be used as a palette for the semantic tokens.

Typography Token

D. Typography tokens had the most information to show per token. Initially, we tried the table approach but with the amount of horizontal scrolling needed, we decided to use cards instead to display the information. This way the user can see all the relevant information on the screen with a preview of the font with the attributes applied.

E. Core tokens had less data to display and we could fit this into tables. We split them by attributes, font family and font-weight.

Spacing Tokens

F. Spacing Tokens are visualised so the end-user can get a sense of how much space each token generates. This would help designers, who need to layout the page pick the right token, as they can see it in practice and not a number.

Icon Tokens

G - Icon tokens allow users to generate icons within the platform via referencing the token. The purpose of this page was to be used as a library for users to quickly identify icons needed for their designs and for development to know what token they need to reference. 

Guideline Pages

Guidelines pages were created to offer detailed information on effectively using the design system, ensuring comprehensive coverage. My role involved crafting the copy and designing all informational pages required by the design team. These pages included: Getting Started for Designers, Colour Usage & Combinations, Tokens and FAQ. The main purpose of these pages is to portray detailed information. I knew people don’t take in information when it's text block-heavy. To make this as easy for users to digest as possible, we tried to add as much imagery and diagrams as possible (A).

Testing Our Designs

Testing Goals

After creating our designs, we wanted to test them with different teams within FanDuel. The goal of the testing was to identify common pain points, specific challenges, and opportunities for improving the reference site for Formation. It would evaluate the site's information architecture, users' ability to find specific content, and whether it provides sufficient information to meet end-user needs.

Testing

To accomplish our goals we planned to run user interviews with 5 designers and 5 engineers. We spent 30 minutes diving into how they currently use the design system and how they find information and then proceeded to give them two tasks within a prototype and some tree-testing. These tasks tested the following:

• Does the overall architecture of the site make sense?
• Are users able to digest content and gain the information they need?
• Are there any unforeseen pain points with the new re-design site?
• Are we missing content for the site's initial launch?
• I created a testing script to allow the other moderators and me to run the project as smoothly as possible.

What We Learned

The sessions were split by users, all designers were moderated by myself while developers were talked to by product management. The learnings could be summarised in 6 points:

1. Balancing Content for Designers and Engineers: The site content is too designer-focused, leaving engineers to search elsewhere for relevant resources.
2. Positive Feedback on Token Contextual Information: Users appreciate the contextual details in the tokens, such as the descriptions in semantic colour tokens and the visual representation of spacing tokens.
3. Lack of Guidance on Building Components in Figma: The site is missing content on creating components in Figma using the Formation method with tokenisation and best practices.
4. Challenges in Token Selection: Users find it difficult to choose the right token for their specific needs due to the abundance of options and the ambiguity of some tokens.
5. Need for Ref Site Consolidation: We direct users to external platforms like GitHub, Confluence, and Storybook too often, making it harder for them to find information in one place.
6. Standardising Product Development Processes: We need to standardise approaches for when the Formation design system is insufficient, as uncertainty currently forces teams to choose between using it or not. To get a more in-depth understanding of the research data, see the research recommendation pack that was generated for the client.

Development and Release

During the development of the reference site, I worked with the engineering team to create the reference site. I tested the site as they built it, as well as answered any questions the engineering teams had. I was responsible for working with the development team to overcome any problems they encountered.

Conclusion

The Formation reference site became a pivotal resource, fostering greater adoption and consistency across FanDuel’s product ecosystem. By prioritising user needs and balancing design with development constraints, we delivered an MVP that could scale over time. This project strengthened my ability to lead cross-functional teams, advocate for user-centric design, and execute complex design system initiatives. Ultimately, the site stands as a testament to how thoughtful collaboration and strategic prioritisation can yield impactful results, driving design system adoption and enhancing product quality.I hope this case study has given you a good overview of my skills and experience. If you have any questions, please do not hesitate to contact me.