CLOUD THEORY DESIGN SYSTEM
Timeline:
April - August 2024
My Role:
Lead Designer and Project Manager
Team:
Product Manager: James Ramadan
Engineering Manager: Sean Merron
Engineers: Josh Stauffer, Adrian Padilla
Context
Cloud Theory is a DaaS organization enabling internal account managers to serve customers in the Automotive, and more recently, Vacation Rental industries. Evolved from marketing agency Zerosum, their legacy product teams established their development process without dedicated front-end engineers or a full-time product designer.
Developers across teams were hampered by front-end inefficiencies. Customers love Cloud Theory products for the precise, real-time analytics that enable them to make informed inventory and marketing decisions. These analytics are powered by CT’s full-stack engineers, who are experts at scraping, integrating, and translating data into reliable insights. Unfortunately, while the back-end flourished and evolved, the front-end process and codebase had been neglected.
I recognized we needed a design system while working on my first big project at Cloud Theory, a tool that was meant to seamlessly connect sales and operations workflows in the platform. I didn’t have clear tech constraints to guide my process, and developers were under-equipped to tackle new use cases without reinventing the wheel. It was a huge undertaking, and the team was proud (and relieved) to ship the product and see its success, but it was clear that we needed to upgrade our FE tools and process to deliver the user experience we all believed in.
CT Engineers relied on several tools for FE development– components from the Telerik library, Sass styles from Boostrap, and icons from the Font Awesome library. These tools were not inherently misaligned, but they were mismanaged as the team continuously patched the framework with new code when new use cases arose. This required them to manage 8 stylesheets and a complex system of overrides to style UI elements without design tokens or a component library to act as a source-of-truth. The complexity made it challenging for me to design and even more challenging for devs to execute, burdened with ambiguity, duplicative work, and complicated training.
THE TASK
My goal was to develop a component-based design system to streamline our FE process and define design patterns to improve user experience across products. Further, I hoped to lay the groundwork for future initiatives with FE dependencies (e.g. productizing theme customization).
In early 2024, Cloud Theory formed a new product team to target customers in the travel industry. We’d be building a new platform, Bookings Cloud, and we wanted to take advantage of the blank slate to pilot FE improvements we could apply to legacy products in the future. I collaborated with my engineering partners to roadmap plans for our design system and define success criteria. We faced three primary constraints:
1. Cross-Product Alignment – Our design system had to be suitable for new and legacy products alike. This was especially important to consider when defining which components our system required.
2. Split Workload – While I structured tokens and components for our design system, I still had to hit larger milestones for the Bookings Cloud launch, designing the overall look-and-feel, user flows, and edge cases. Likewise, Josh and Adrian were building the component library while learning Blazor for the first time and building the platform’s back-end. We all had our hands full, so I had to be resourceful while defining the scope and milestones of this project.
3. Cross-Team Collaboration – Don’t think for a second I went into this project knowing what ASP.NET is. I have a little coding experience, but I’m not a front-end developer– Josh and Adrian had to introduce me to these systems and their vocabulary. Meanwhile, I had experience with mature design systems, but my team wasn’t used to discussing their work in terms of components, variants, and tokens. It was challenging for all of us to communicate concepts and expectations, and we were outside of our comfort zones, learning new skills and ways of working. Ultimately, we grew to trust each other and ourselves as we stormed and normed, and I’m so grateful for my team’s partnership throughout this journey.
How might we accelerate UI development across multiple product teams without compromising usability?
Goals:
-
Prototype the Blazor framework
-
↓ Dev time
-
↓ Design time
-
Define sustainable design standards and accessibility guardrails
Impact:
-
Implemented component-based Blazor architecture
-
<1/3 lines of CSS
-
1/5 design time across workflows
-
Streamlined handoff and UAT
-
Introduced and solidified improvements to usability, accessibility, and visual design
DISCOVERY
What does our design system need to include? As I jumped into discovery, I considered the Cloud Theory product team to be the users– product managers, developers, and designer(s) included. I needed set up internal knowledge share sessions with my team to understand their process and pain points, as much as I needed to look outward towards best practices in the wild. I hoped to use these insights to settle on a scope.
Knowledge Sharing
Discovery Questions:
What FE tools do our developers rely on?
What “components” does our current system include?
What’s working well? Where are the pain points?
What use cases do we need to accommodate for an MVP component library?
What does our design system need in order to integrate our effective tools and deprecate the ineffective?
Cloud Theory already had a design system; it just wasn’t meeting our needs. My first task was to map the system in place. Adrian and Josh gave me demos on our old and new codebase and showed me how they break down mockups into code. I learned how they depended on the Telerik, Bootstrap, and Font Awesome libraries for much of their FE development and our design system would only be effective to the extent that it integrated those tools.
Competitive Analysis
Discovery Questions:
How have other teams approached scoping and documenting their design systems in the past?
What makes a design system effective?
What terms and definitions do I and my team need to know?
To learn about best practices for establishing a successful design system, I referenced many resources. I studied systems in the wild (e.g. Polaris, Lightning, Spectrum), too many Medium case studies to count, and Dan Mall's Design That Scales. I was also fortunate to meet Amy Lee through ADPList who gave me invaluable tips on managing this complicated project and staying sane. At this stage, I was primarily concerned with the structure of design systems as a whole– I needed to understand the different tools other teams have drafted to meet their specific needs.
Extracting Requirements
I did a teardown of our legacy products to identify tried-and-true UI elements we could evolve into components. Simultaneously, I built wireframes of Cloud Bookings to identify the components we needed for our new platform. I wanted to be resourceful and find the overlap, areas where a single component could solve problems in either context. I was also on the lookout for strategic areas where we might establish a better standard for design and interactivity.
Next, I generated and prioritized a list of components that we needed in our design system to handle the majority of use cases across platforms. I worked with the Josh and Adrian to assign a “source” for each component– is it most efficient to pull directly from Telerik, evolve an element from the Bootstrap library, or build from scratch? Generally, we could build on components engineers were already accustomed to using, with some minor customization.
I also planned to create a system of design tokens that could be applied across Telerik, Bootstrap, and custom components. The system needed to be robust to cover the immediate needs and carefully structured to scale if/when new brand themes are introduced. This would be a huge asset to the team, as it would enable them to significantly reduce the number and complexity of their CSS stylesheets.
Finally, I planned to develop an ecosystem in Figma to ensure designs always align 1:1 with the Blazor framework Josh and Adrian were developing. The UI kit would be a home base and source-of-truth for our components, tokens, specs, and documentation. The various design templates and resources would help streamline design and handoff, regardless of who's behind the wheel/mouse/trackpad.
DESIGN & BUILD
Rapid Release Cycle
With a lot to deliver in just a few months, design and development was a relay. First, I handed off the primary user flows in a near-ready state, so the engineers had context and a reference for the individual components in the system.
They began BE and FE implementation as I defined the token system and finalized the individual component designs. The design system had to unify Telerik, Bootstrap, and custom css– as we worked in parallel, I tried to minimize ambiguity in the UI kit.
The design tokens would be disseminated throughout the system, so I tackled those first. Minimally, we needed typography and color tokens that could be applied to Telerik, Bootstrap, and custom CSS, accommodating light and dark themes. My stretch goals were to build in guardrails for ADA accessibility and consider a future where agencies that license CT products could customize the theme colors to their brand.
There are infinite ways to structure a design token system, especially color variables. I referenced many different design systems to understand best practices and developed the system according to the unique needs of my team and ADA accessibility standards. To test and iterate, I built out a few key components (❖ Button, ❖ Grid, and ❖ Chip) using my system to see if those needs were met and how it “felt” to use them. This was challenging, but the final 3-tier architecture is optimized for engineers and future designers to apply styles with ease. Further, it would take less than 5 min to create a new theme without needing to manually test for accessibility, as color contrast has already been pressure tested and locked in.
PILOT
In August 2024, we launched a proof-of-concept for the new Bookings Cloud app, along with the new Blazor design system. There wasn't much time to celebrate– we had a full plate of fast follows and ideating on the future– but I am still in awe of all we were able to revamp in such a short time and how smooth the launch went. With the engineers' attention to detail and a tight feedback loop, we were able to build fast and keep our momentum after launch to keep refining the system.
Cloud Theory
Design System
The Cloud Theory Design System is an ecosystem of reusable tokens, components, and templates that enables engineers to efficiently develop user-friendly interfaces according to modern design best practices.
Foundations
Design tokens to define and organize typography and color decisions. These are the "atoms", of our design system.
Typography
Color
Utilities
UI elements that end-users can view an interact with. These are the "molecules" and "organisms" of our design system.
Layout
Icons
Components
Resources
Tools to assist during the Figma design process, to improve efficiency for designers and clarity for engineers.
UI Kit
Documentation Kit
Project Template
THE IMPACT
Implemented component-based Blazor architecture
The pilot introduced Blazor to our development process, a more modern and robust FE framework. The new component-based architecture was easier to manage and scale as we continued to evolve the Bookings Cloud platform.
<1/3 lines of CSS
With the implementation of the design system, developers on the Travel team could deprecate entire stylesheets– significantly simplifying their process and minimizing FE errors and inconsistencies. The process improvements, source-of-truth, and shared language the system created helped our team move faster in following cycles.
1/5 design time across workflows
We established the Figma UI kit and Blazor component library as matching "toolkits". As I designed full screens and flows, I was able to iterate more efficiently without detaching components. Further, page and project templates enabled non-designer teammates to easily create feasible mockups on their own.
Streamlined handoff and UAT
Designing within our co-created guardrails, I didn't need to document designs with as much granularity before handoff. We also developed more efficient async processes with Figma comments and links to detailed layout specs.
Enriched usability, accessibility, and visual design
The design system introduced and solidified tangible UI/UX improvements. The component-based architecture afforded quicker load times and more consistency among interactions and flows compared to Cloud Theory's legacy products. I was able to introduce more responsiveness with our defined layouts and improved web accessibility with our token and component structures. I also developed a fresher look-and feel that aligns with Cloud Theory's brand identity. We received overwhelmingly positive feedback in demos from users, teammates, and stakeholders beyond the Travel team– I'm proud the design system represents the complex Cloud Theory universe so well!
Moving Forward
The Travel team worked hard to get our design system into production, but our legacy apps were still using the old framework and tools. As I designed the tokens and components, I was very mindful of how the system would back into the older applications, so the UI elements could blend easily regardless of how gradually we transitioned. Training a larger team of engineers to use Blazor and the new best practices would be challenging, but this project has made me more confident than ever that the Cloud Theory team can tackle the trickiest of challenges!
