BlueJay Design system – Creating a design system for a Game Engine
Hi, I’m Joshua, a co-creator of the BlueJay Design System. This comprehensive framework helps developers extend our engine efficiently, encompassing APIs, prebuilt components, a QT control gallery, a Figma design library, and extensive documentation. I spearheaded and facilitated the creation of BlueJay to enable rapid interface development for both Lumberyard and, subsequently, O3DE.
Origin Story:
As my fellow designers and I worked on different parts of the engine, we noticed that varying use cases were causing slight divergences in our implementation of input fields, dropdowns, and selection states. While our design library maintained good form, we observed inconsistencies creeping in as developers either weren’t aware of previous code versions or were attempting to innovate. This fragmentation in our designs prompted us to develop a unified solution.
The image to the left illustrates the transition from Editor 1.0 to Editor 2.0, also known as UI 2.0. This transformation represents our initial effort to streamline and standardize our user interface. It marked a significant milestone in our design evolution, where we focused on eliminating inconsistencies in patterns, simplifying components, and creating a more cohesive visual language.
This clean-up initiative was more than just a visual refresh; it laid the foundation for what would become the BlueJay Design System. As we refined our UI, we began to see the potential for a more comprehensive and systematic approach to design within our engine.
Editor 2.0 served as the catalyst for the creation of BlueJay. It was during this phase that we started conceptualizing and implementing our design system in earnest. As we worked through the redesign, we identified common elements and patterns that could be standardized and reused across the engine.
This process of refinement and systematization led to the gradual introduction of BlueJay components. Each new or redesigned element was carefully considered not just for its immediate application, but for its potential as a reusable component within the larger system.
While UI 2.0 represents a significant visual improvement, it’s important to note that it was just the beginning of our journey. The real power of BlueJay as a comprehensive design system began to unfold as we continued to iterate and expand upon this foundation, creating a more robust, flexible, and consistent design framework for our engine.
Thus, the BlueJay Design System was born. Its primary goal was to ensure consistency across all component implementations throughout the engine. This system allowed developers to improve or expand components globally, with changes reflecting across all instances of that component classification. It also enabled us to create variations for different circumstances, with users naturally inheriting these modifications. This approach, already present in our design systems and code, was now being universalized within the engine.
We initiated the project with a small team to build a proof of concept. The results were impressive: it not only saved thousands of hours of work long-term but also significantly eased the onboarding process for new developers, eliminating the need to build components from scratch on both the code and design sides.
Naming the System:
The name ‘BlueJay’ emerged from a creative naming process. Initially, four designers were involved: myself (Joshua), Yuyi, Lee, and Bhanuja. After considering various naming conventions used for internal products and services, we settled on using an anagram. Given that many internal services used bird names, I searched for an anagram that could incorporate all our names, eventually landing on ‘BlueJay’.
Collaborative Development:
While the system was under the UX banner, it’s crucial to acknowledge the hundreds of hours contributed by developers like Danilo Aimini, Luis Sempe, Gene Walters, Chris Galvan, and Ram Kappagantula, among others. Each team dealt with different configurations and objects, with developers picking up components based on their specific tools, creating iterations, and seeking team approvals on functionality and appearance.
Evolution and Impact:
As customer requests for improvements or updates came in, we always considered how the BlueJay Design System needed to be updated first. This shift in thinking created a new paradigm for managing and maintaining the component structure in Lumberyard and later in O3DE.
The QT control gallery serves as the underlying infrastructure for managing our QT components, allowing us to add, modify, or update the library. It also enables us to extend APIs and documentation directly to customers via an executable app that accompanies O3DE. This tool helps us identify when code is implemented outside our standard norms and allows us to extend new features like themes, variants, and system-wide changes to font sizes and languages.
In essence, the BlueJay Design System represents a significant leap forward in our approach to consistent, efficient, and user-friendly design implementation across our engine ecosystem.
