THE CHALLENGE

Why create a design system for OpenAI?

In this project, we analyzed OpenAI's ecosystem and reimagined their design system to align with best practices. OpenAI was an ideal choice due to the absence of a publicly available design system and noticeable opportunities for improving their visual consistency.

OpenAI is an AI research lab that develops and promotes AI technologies like ChatGPT, Sora, and DALL-E. Their mission is to ensure that artificial intelligence benefits all of humanity.

It's a company that transformed how our world works but their visual design lacks consistency across their branding guidelines, main website, platform website, and other sites like ChatGPT. This inconsistency affects user perception and brand cohesion.
Additionally, we noticed the absence of primitive design tokens and the usage of hardcoded values, which may also be a contributor to these inconsistencies.

This project aims to resolve these issues by creating the start of a cohesive design system for the company in 2 weeks.
FOUNDATIONS

Introducing Lumina

The name "Lumina" symbolizes light and clarity, reflecting our commitment to creating an accessible and user-friendly design system.

Lumina embodies three core principles: Consistent, Accessible, and Semantic, aligning with OpenAI's brand values of Gravitas, Precision, Approachability, Allure, and Boldness.

The three core principles

Consistent

Consistency ensures a unified user experience across all touchpoints. We followed these guidelines:
Color Palette: Defined primary and semantic colors with specific codes (HEX, RGB).
Typography: Established font families, sizes, weights, and line heights.
Components: Created a library of reusable UI components with standardized styles and behaviors.
Documentation: Provided detailed guidelines and examples for consistency.

Accessible

Accessibility ensures inclusivity and engagement for all users. It embodies inclusivity and empathy, ensuring that technology serves everyone.
Below are guidelines we set to follow:
Color Contrast:: Meets WCAG AA or AAA standards for readability.
Keyboard Navigation: Interactive elements are accessible via keyboard with clear focus states.
Screen Reader Support: Uses semantic HTML and ARIA attributes for screen readers.
Text Alternatives: Provides alternative text for images, icons, and non-text content.

Semantic

Semantic clarity ensures that every design element is meaningful and contributes to the overall understanding and usability of the system.
Below are guidelines we set to follow:
Design Tokens: Defines and documents tokens for colors, typography, spacing, ensuring consistent usage.
Semantic HTML: Uses appropriate HTML tags for meaning and structure. (e.g., <header>, <nav>, <main>, <section>, <article>, <footer>).
Guessability: Intuitive primitives and components to reduce the learning curve
Code Consistency: Integrates design tokens into the codebase for easy reference and consistent styles.

The foundations we set for Lumina guided us as we made decisions throughout the creation process. We also set guidelines for our voice and tone, prepared a glossary, and identified repeating patterns, which can be accesed in our project files.
DESIGN TOKENS

Setting up our Tokens

Setting up primitive tokens was essential for consistency, reusability, and scalability across the design system. From these primitives, we created semantic tokens representing design decisions reused across components and application.

Color primitives

Core Colors

Color is a powerful tool that enables users to quickly grasp the information hierarchy. Lumina uses three core colors that establish the visual identity and consistency of the OpenAI brand, ensuring immediate recognition across all mediums.
These colors play a crucial role in creating a cohesive look and feel, guiding our user's attention and supporting the overall design hierarchy.

Color Scales

Color scales were also prepared based off the core colors, offering flexibility and depth in design while maintaining brand coherence.

These colors created visual hierarchy that allows differentiation between elements such as backgrounds, buttons, and text. Furthermore, color scales support accessibility by providing sufficient contrast options, ensuring readability and usability for all users.

Semantic Colors

Semantic colors convey specific meanings or statuses, improving usability and accessibility. These colors are not necessarily part of the core brand colors but are used consistently across the design system to communicate specific feedback or states to users.

By using semantic colors, users can quickly and intuitively understand the significance of different UI elements, enhancing both usability and accessibility.

Typography

It was very important for us to get our typography right because a large part of OpenAI's platform is documentation, meaning text is being used everywhere.

Using font tokens,  text variants, and semantic tokens allows us typographic consistency and clarity, making design scalable and maintainable. This standardization simplifies the design process and ensures a unified user experience.

Font Tokens (Primitives)

Font tokens define core typography styles such as font family, size, weight, and line height for consistency across the design system.

These primitives serve as the foundational elements for all text-related design.

Text Variants

Text variants are predefined styles for specific text uses like headings, body text, and captions, ensuring design consistency.
We also created guidelines for spacing and border radius. These can also be accessed in our project files.
CREATING COMPONENTS

Building components for Lumina

When developing components for the Lumina Design System, our primary goal was to ensure that they are intuitive, reusable, and consistent—reinforcing our commitment to a design system that is easily adoptable and maintainable by others. We also made sure to define the do's and don'ts for each component's usage.

Variants and States

To accommodate various use cases and ensure flexibility, we prepared different variants and states for each component. This allows designers and developers to adapt components to their specific needs while maintaining a consistent look and feel.
HOW WE MADE DECISIONS WITH OUR COMPONENTS
Between design and development, there were a lot of decisions we needed to make for every component we wanted to add in our system—after all, that is the point of the design system. For a structured process to go over creating our components, we followed the following checklist:
Type Variants: Should our component support different incarnations?
Size Variants: Should our component support different rendering sizes?
Dimensions: Can users tweak width or height by means of tokens or values?
Alignment: How does content get aligned by default? Can we customize this?
Spacing: How will our component handle its margins in the component's flow?
Text Placeholders and Slots: Will it include children content? How?
Hover and Focus State: Will it include children content? How?
Interaction Guarding States: Read-only, disabled, loading mode, etc.
Other Usability States: Error state, pristine, touched, dirty states.
Transitions: Should the component feature enter/exit/hover animations?
REFLECTIONS

Foundations are essential

I’ve tried creating design systems for past projects, but this project really taught me that a good design system is built upon its solid foundations. It’s not about the cool components (but it's definitely fun to create them) but it's about the principles we follow, the primitive tokens we set up, and the design tokens we eventually turn into variables in code.

Furthermore, documentation and clear communication was, as expected, a crucial and important step we needed to do, especially if we wanted our design system to be useful to others as well.

Now, I definitely have a better appreciation of how to think with a design system mindset—where each and every thing we design and develop, whether it's color, typography, or a component, is made with intention and careful consideration of existing and future use cases.
This project was completed as fulfillment of the course Design Systems for Interactive Systems taught by Pablo Deeleman, working as a Staff Frontend Engineer from Twilio, at Harbour.Space University (Barcelona).