From Design Systems to AI Language Models

Challenges in traditional design systems

Design systems, known by various names, have been in practice for a considerable time. They serve as collections of reusable assets, enabling the creation of a virtually infinite number of product variations. Pioneering companies like Apple and Google have championed the development of design systems, aligning them with well-defined company product standards.

Each design component is meticulously crafted, considering aspects such as color, line weights, shading, and typography. When implemented at the code level, these components provide product teams with ease and efficiency, shortening production cycles. Users benefit from the resulting consistency and familiarity in their experiences.

However, the complexity of product frameworks can sometimes reveal limitations in a design system’s ability to fully control the entire product production cycle. Ironically, these challenges often arise from the very principle of centralization of their creation.

Here’s how it unfolds: Specialized design groups focus solely on developing and implementing design components. These groups adhere to a set of design principles. The process is typically unidirectional: Localized design teams receive a pre-designed set of components from the governing body, along with guidelines (the “Do’s” and “Don’ts”) for a handful of mainstream scenarios.

Lego pieces are often used as an analogy for how a Design System works. And just as with a box of random legos, you will get the same number of assembled variations as the number of test subjects. This is because the intent of how the group of assembled legos should perform had not been defined beforehand, leaving you with an assortment of assembled creations. This gap is quickly filled by a small and fast-moving product teams from the angle of their own (otherwise healthy) product bias. The system is frayed before it has touched the ground.

DS for eBay Ads

It is not uncommon to uncover pages that date back 3 or more generations of design systems while using any company’s services. You may have seen jarringly antiquated help pages at Google or conflict remediation flows at Apple. Design systems often take years to gradually permeate through the fabric of horizontal adoption within micro product-level development streams. Not every live product is actively owned and managed. Additionally, new design systems are sometimes released before the previous ones have had sufficient time to establish platform-level roots, compounding the user journey-level dissonance.

eBay is no exception. Design systems are initially implemented in the Shopping experience, but it often takes 3-4 years or more for them to be absorbed into vertical experiences, such as Selling and Advertising platforms. As a design leader for Ads, I was presented with the challenge of applying generalized horizontal components towards highly specialized purposes. More critically still, I was seeing smaller engineering teams taking up independent code-level production of Figma-level components to keep up with their own release timelines. This resulted in chronic redundancies and overlaps which were then compounded into equally chronic engineering resources shortages. All this at a time when the need for robust experimentation and A/B testing was at its highest.

Optimizing E2E implementation

The problem I had in hand may seem orthodox. I’ve found myself in a situation where each engineering team was busy developing their own set of code-level UI components in accordance with their own needs along specific product tracks. Underpinned by various tech stacks and in the midst of raging intellectual war between Markojs and React, the problems looked exponentially troublesome. As our framework grew, this would inevitable lead us into a crisis mode, where our users would have to re-learn how to perform exact same task depending on the ads program or a specific management objective. Moreover, the teams were burning very valuable development time that could have otherwise been put to a number of much needed uses, such as validation of designs in live environments.

I set out a two-prong approach to solving this problem.

The decline of curated design systems

From seed to fruit, the design systems have relied on the intercession of a human agent. Today, we’re starting to see the emergence of AI-powered Design Language models are coming to replace the curated Design Systems. These are dialects of English that formally describe the aspects of a design, including motion, visuals, audio, data, and interactivity. They are tuned to a specific team’s aesthetic identity and keep it consistent at all times.

Capturing a style is done through programming rather than curation. Existing UI libraries can be mapped to new Design Languages, providing an English “command line” that can generate finished UI through a prompt. DLs ensure design consistency by providing a standardized set of guidelines and terminologies that designers follow. This common language helps maintain a cohesive look and feel across different parts of a user interface, ensuring that all elements align with the overall design aesthetic and user experience goals.

With LLMs even the least technical designer can fully drive the system, provided they possess intrinsic familiarity of user goals at a task-level. Think of it as a human-centric specification that can be executed. Interestingly, a similar model has been serving the blockchain for executing smart contracts for over a decade.

Before that day comes you can learn about using publicly available AI in everyday UX and help shape the future of AI in Design.

Eric Nordquist: Using Ai Tools for UX Design (LinkedIn course)