CONTEXT

Unqork is a no-code platform used to build hundreds of enterprise applications, which means users rely entirely on our design system. They don’t just use our components; they build directly on top of our system.

At Unqork, we want to empower our users using a scalable, flexible, and adaptable design system that could support our own needs while also supporting our client's needs including styling applications.

I knew that defining and implementing design tokens in our own design system was the best way to align with industry standards, streamline the styling process, and empower users to apply their own tokens directly within Unqork.

THE PROBLEM

Unqork lacked a native, scalable styling system, excluding non-technical users, breaking design consistency, and limiting product scalability.

Styling in Unqork was manual and code-dependent. Users had to write CSS and manage styles through external files. This not only excluded non-technical users but also introduced inconsistencies and inefficiencies across applications. Clients couldn't to integrate their own design systems, and we had no scalable way to support tokens, or reusable styles.

TIMELINE

Here’s a look at the end-to-end timeline of this project, from kickoff to the inevitable ‘final_for_sure_pls’ milestone 😂. This structured approach helped me align with cross-functional teams, validate each phase with users, and ultimately deliver a scalable solution that’s now being implemented across the platform.

UNDERSTANDING CLIENT NEEDS

Understanding user needs was critical to ensure the system would cover user needs and adoption, not just implemented. Since our users range from non-technical builders to enterprise clients with complex design systems, the solution had to be flexible, intuitive, and able to meet them where they are. Based on interviews, audits, and client requests, I identified three core needs:

Import and integrate tokens from their existing design systems, often managed in tools like Figma, Token Studio, or JSON files,

Apply multiple themes across applications to support product variations, brands, or accessibility modes.

Assign those tokens to components inside Unqork without having to write CSS.

Goldman Sachs Design System (One of our biggest clients)

RESEARCH

To ensure the token architecture and built-in tool experience were aligned with user expectations and industry standards, I ran extensive research in two different subjects:

Design System Analysis

I audited leading systems like IBM Carbon, Adobe Spectrum, Atlassian, and Material Design to identify naming patterns, token categories, and architectural approaches. I also studied how our own enterprise clients (e.g., Goldman Sachs, JPMorgan) structured their tokens.

Competitive Analysis

I analyzed token tools like Figma Variables, Token Studio, Specify, and Supernova to understand how tokens were being created, imported, and managed in real-world design systems.

RESEARCH INSIGHTS

Through my research, I realized most systems follow a loose folder-like hierarchy:

👉 A top-level library or system name
👉 A category like color or typography
👉 A specific purpose or variant
👉 Optional scale or state information

This insight led me to define a flexible token syntax that could be easy to use and understand, mappable, and scalable.

STRATEGY

After identifying the need for scalable styling, I knew that defining the right token structure was the foundation. But the challenge wasn’t just creating tokens, it was designing a system that worked across multiple clients, multiple maturity levels, and a multi-product platform without introducing complexity for the end user.

I started by asking:

How might we support both simple brand guidelines and complex token structures within our design system?

How might we enable any token structure regardless of naming logic to be mapped into Unqork?

How might we make token mapping and management intuitive and usable through a no-code interface?

DESIGN EXPLORATIONS

To bring the system to life, I explored both the underlying token architecture and the user experience of the Style Manager, making sure the structure and interface worked hand in hand. Here is what I did: 👇

Token Architecture

The token structure was a critical foundation, so I explored several rough approaches to support both simple and complex design systems. I sketched out different naming models using layers like system, theme, category, property, and state, testing how much should be user-defined vs. auto-generated.

These early explorations helped me understand how the structure could flex to different levels of design system maturity and laid the groundwork for how tokens would eventually be grouped, mapped, and reused.

Style Manager

At the same time, I was exploring how would users actually integrate, manage, apply, and scale their own tokens? I went through several iterations, focused on making complex token data feel intuitive especially for non-technical users.

I explored tabs, table views, grouping patterns, and filters that would let users browse by category, assign tokens to components, and switch between themes effortlessly. Every detail was tied back to the architecture, from the token groupings to the system and theme hierarchy.

TESTING BABY, TESTING!

I tested four iterations of the token structure and Style Manager prototype with both internal users and new users unfamiliar with the system. Each round uncovered usability gaps and opportunities, informing key improvements to the token model, naming logic, and interface. These continuous feedback loops helped shape a solution that’s both scalable and intuitive, even for first-time users.

THE REAL DEAL

With the architecture validated and user feedback in hand, I had everything I needed to make things happening. From here, I focused on two parallel tracks: finalizing the token structure itself, ensuring it could scale across any client or brand, and designing the Style Manager, the no-code interface that would bring this system to life for our users.

Token Structure

This diagram captures the three levels of token abstraction defined for the system.

At the bottom are raw values, useful, but too vague to scale or reuse across teams. So we introduced base tokens to give those values structure and consistency across styling categories. Then, at the top, we defined semantic tokens, these have a clear purpose and context, making them more meaningful and easier to apply across components.

This layered structure not only makes the system more meaningful and maintainable, but also aligns with the standard token hierarchy used across the industry.

Base Tokens

Each token starts with a system name, then optionally a theme. The required category aligns with Unqork’s styling support, like colors, typography, spacing, and more.

We include CSS properties when needed (like font-weight or drop-shadow), followed by optional fields like variant, name, and scale.

This format keeps tokens flexible, readable, and easy to map, whether users are building from scratch or importing their own system.

Semantic Tokens

They follow a similar structure to base tokens, but they’re purpose-driven! They describe what the token is actually used for. Like base tokens, they start with the system and optional theme, and use the same predefined categories (like color, typography, spacing).

From there, they introduce new levels of specificity: element, variant, state, and scale, all with predefined values to ensure consistency and communicate clear intent across components.

Semantic tokens also support composite tokens!

This is where multiple base tokens come together to define a single, reusable style. It allows us to express consistent, scalable design decisions in one token, making theme application not only faster and easier to manage across large-scale systems.

Categories that support composite tokens: Typography, Spacing, Borders, & Effects.

With a token architecure set up, now it was time to give users a tool to apply, manage, and map their own tokens while still using our design system as the source of truth!

Token Mapping

Here’s how our token structure adapts to different brands.

Starting with a raw value like a hex color, we define a base token that standardizes that value across our design system. Then we assign it a semantic token that gives it context and purpose, like a background color for buttons. From there, clients can map that semantic token to their own naming logic, whether they follow a brand structure like $jpm-color-bg-brand, $gs-color-bg-surface-primary, or something else entirely.

This flexible system supports multiple naming conventions without sacrificing consistency or control.

Now that I had the token architecture defined, it was time to design the actual experience, a tool that would let users style applications without writing a single line of code! A tool that it’s fully built around the token system I created.

INTRODUCING THE STYLE MANAGER

A built-in tool that empowers clients to integrate, assign & apply their well-defined token system in a single place with zero-code!

Featuring base

and semantic tokens!

Aligning with the industry standard of tokens!

From colors and typography to borders and spacing, the style manager supports standard token categories to build a scalable and consistent visual language throughout all applications!

Supporting imports from third-party tools clients already use, like Figma, GitHub, and GitLab.

Users can upload a JSON file or connect directly to their token source using a personal access token.

It reviews and maps tokens with AI automation for instant use on the platform!

Going from an empty style manager

To a populated one in minutes

Styling components? Not a biggie!

Previously defined tokens can be used to style components unlocking scalability, reusability & consistency across all applicaitons

Theming can be easily applied!

Applying themes is made in minutes, not weeks!

HOW EVERYTHING COMES TOGETHER

Token systems might look different from company to company, but what really matters is naming and order.

The Style Manager makes easy to integrate and map any kind of token architecture by building the structure right into the interface.

Every part of a token, like system, category, or state, maps directly to a place in the UI, so users don’t have to follow a strict naming convention. They just fill in the fields, and the system organizes everything under the hood.

That’s how we support any token system, without forcing anyone to change how they work.

And just like that, every token on the Style Manager automatically maps to a clean JSON format behind the scenes!

BY THE NUMBERS!

Token category coverage across color, typography, spacing, borders, and effects

85%

10X

faster styling workflow compared to the previous manual setup

100%

brand theming coverage! Clients can fully reflect their multi brands and products without any code

80%

reduction in token mapping time thanks to auto-mapping and smart suggestions

45%

fewer customer tickets related to styling issues

The Style Manager is still being implemented as of Q1, 2025. But even before the full launch, the impact is already measurable 👇🏼

CUSTOMER FEEDBACK

YAYYY! I DID THAT!

I built a token system and styling experience that actually works, one that scales, adapts, and feels simple, even for peeps who’ve never touched a line of code. It’s functional, but more importantly, it’s something users actually want to use.

Honestly, this has been one of the most rewarding projects I’ve led.

I got to take something really complex and turn it into a system that feels clear, intuitive, and (dare I say) kinda fun. This is the kind of work I love! Turning complexity into clarity, and building tools that help teams move faster, stay consistent, and create with confidence.

Implementing Accessibility at Unqork

Maintaining and Scaling Unqork Design System

MORE PROJECTS