BetDUX Design System

Visit

BetDEX Labs

ROLE

Principal Product Designer

ROLE

Principal Product Designer

ROLE

Principal Product Designer

PROJECT LENGTH

3 Months

PROJECT LENGTH

3 Months

PROJECT LENGTH

3 Months

TEAM SIZE

2 Designers

TEAM SIZE

2 Designers

TEAM SIZE

2 Designers

PLATFORMS

Responsive Web

PLATFORMS

Responsive Web

PLATFORMS

Responsive Web

New York based BetDEX Labs is currently building one of the world’s first decentralised and licensed sports betting exchanges. At the beginning of the project, BetDEX Labs faced a unique challenge—they had no existing product or brand identity.


As one of the team’s founding designers, I had the task of crafting a design system from scratch, laying the foundation for all future products and experiences, ensuring both accessibility and scalability.


Huge effort was poured early on into developing a robust and flexible design system, with a focus on creating a strong foundation that could accommodate future growth.


We meticulously planned the end goal of the system, envisioning a comprehensive solution, only to scale back strategically to create an efficient Minimum Viable Product (MVP) that would serve as a solid starting point for the startup's growth. This deliberate approach ensured that the design system would be well-prepared to meet the demands of a rapidly evolving product landscape.

The Problem

The absence of an established brand identity or product presented a significant challenge for the team. The potential scope of the project was vast, as every aspect of the design system had to be developed from the ground up.


The design team took ownership of this expansive scope, leveraging their domain knowledge and expertise to manage it effectively. However, we faced significant constraints in the form of a small team with limited time and resources.


We also recognised the importance of building a design system that struck the right balance between providing structure and remaining flexible enough quickly. It needed to establish a coherent visual language and maintain consistency, while also allowing for adaptability and variety within the product.


Communicating the value of the design system to the broader business early on was also crucial, requiring the team to articulate its benefits early on to gain support and alignment from the wider team.

Defining our library hierarchy early on was key

The Goal

Our primary objective was to create a highly scalable design system that could support the planned exchange product while also accommodating future offerings across web and native platforms.


A key focus was to establish a comprehensive design token system that encompassed all the visual and interactive elements of the user interface. This included defining colour palettes, typography, spacing, and other design attributes to ensure consistency and efficiency in design implementation.


Another crucial goal was achieving full parity with the development libraries to streamline the collaboration between design and development teams. This meant implementing both Zeroheight and Storybook as essential tools for documentation and component management.


Success in these areas meant BetDEX Labs would have a robust design system that enabled rapid iteration, enhanced efficiency, and maintained a cohesive user experience across all current and future product offerings.

Foundations formed the base for the rest of the system

Research

Each library in the DUX design system is composed of Elements, Components, and Patterns.


Elements

An Elements core purpose is to inform the user of certain data/information. Elements utilise foundations to create informational structures, that aren't typically interacted with directly. Two or more elements can be combined to create more complex structures. E.g. Alerts, banners, breadcrumbs, buttons, checkboxes, inputs.


Components

Components utilise both foundations and elements, combining them into larger more functional structures. Components should be functional and/or informational, functions however should be contained within the bounds of the component. E.g. Stepper


Patterns

Patterns are generally composed of multiple components, which when added form a functional pattern that achieve a specific goal. Patterns can be a combination of similar or different components, repetition of components is to be expected at this level. E.g. Sign-up form


Data visualisation

Given their complex nature, visualisations follow their own ruleset so as to not break the logic outlined above. Data visualisations may contain a unique combination of foundations, elements, components, and patterns which change across screen size and device type. Similarly some foundations, elements or components created will be unique to data visualisation, further differentiating them. e.g. Line chart, bar chart, orderbook, bullet chart

All components were broken down as much as possible for streamlined development

Design

The hierarchy of the DUX Design System was outlined early, defining the relationship between foundations, platform based libraries, and local design systems. This was inspired by a modified version of Atomic Design.


1. Foundations

The basic building blocks that form the foundation of all BetDEX Products. These building blocks cannot be broken down into anything smaller and form the basis of our hierarchy and should be shared across products to ensure a consistent design language unique to BetDEX.


The foundation level defines all of our base styles at a glance and are tokenized as a way to convey usage and improve team communication. E.g. Colour & text stylesFoundation examples


2. Platform based libraries

The next level up from foundations, platform based libraries (e.g. DUX Web) consists of any shared elements that take the building blocks defined in the foundations file and combines them into larger more functional elements.

Platform based libraries predominantly consist of elements, and components given their reusability across products, and more limited complexity.


3. Local design systems

Local systems are a place to keep design elements that are tailored for specific products or audiences (e.g. DUX Exchange). These are things that need to be shared—just not shared across all products.

Local design systems predominantly consist of patterns and data visualisation given their bespoke nature.

Foundations, components, and patterns within the libraries

Challenges

One key challenge was establishing a strong foundation while maintaining the necessary flexibility to accommodate future system and product iterations while also preventing the accumulation of design debt. The team had to strike a delicate balance, ensuring the design system provided structure without impeding the speed of product development.


Another challenge was onboarding team members who were not proficient in Figma. The design team had to invest time and resources in training and providing support to help these members effectively contribute to the development of the design system.


Educating team members from other disciplines on the correct usage and benefits of the design system was another significant challenge. The design team undertook the responsibility of providing guidance and training to ensure consistent implementation and promote cross-functional collaboration.


Finally, we had to accommodate ongoing iterations alongside the rapid development of the product. This required the design team to be agile and adaptable, constantly refining and enhancing the design system to align with evolving user needs and business requirements.

Detailing the granularity of components was crucial for development

Results

The well-structured foundation and comprehensive component libraries proved instrumental in accelerating the development process. The design team was able to work more efficiently and effectively, thanks to the ready-to-use components and consistent design patterns. This allowed us to move at a faster pace than would have been possible without the system in place. By minimising design debt early on, we avoided the need for extensive future overhauls or reworks.


The design system also facilitated seamless collaboration between design and development teams. The clear component structure and documentation, which mirrored the underlying code structure, enabled a smooth handover and implementation process. This resulted in a more efficient development team that could focus on building functionality and features rather than spending excessive time on UI and design-related tasks.


Additionally, the product itself became fully component and pattern-based, providing consistency and a unified user experience across various screens and interactions. This cohesive approach enhanced usability and brand recognition, strengthening the overall product offering.


Most importantly, the design system became deeply embedded in the teams' way of working, becoming an integral part of our development process. This integration fostered a culture of rapid product development, enabling us to iterate and release new features and updates swiftly.

Designed by Luke

Built in Framer