Overview
Bringing order to a system of Theme Sets & Design Variables
Persona develops infrastructure for businesses to verify individuals and organizations, trusted by the world's leading companies. During my 3-month internship there, I shipped a variety of foundational features that has been adopted widely, but my primary focus was a complex architectural pivot: Theme Sets & Design Tokens.
I led the design of a scalable system to help massive B2B2C organizations manage their brand configurations centrally, eliminating the need to manually update hard-coded values across thousands of templates.
The Problem
Customers were repeating the same decisions hundreds of times
As Persona's B2B2C customers scaled, their branding systems didn't. Instead of defining a visual property once, customers were forced to repeat the exact same values across hundreds of isolated templates. Branding decisions became repetitive, difficult to maintain, and prone to inconsistency.
Let's have a look at Twilio
The color #0263E was repeated in
1000x templates
435x color.primary
30 theme sets

The problem became even more complex for B2B2C customers, where different businesses needed to dynamically apply their own branding to the same experience.
How might we…
help builders define a value once and reuse it across Persona?


The intitial proposal
A new layer for reusable values
The initial direction was to create Resources: a central place where customers could define reusable values and reference them throughout Persona.
I explored multiple models for how reusable values could be created, inherited, overridden, and swapped safely.
Option 1
Default values & overrides
A superset with override values layered on

Option 2
Collection + Variants
Borrowed from Figma's design variables

Where it fell apart
Don't we already have the primitive we need?
But the more I explored, the more problems surfaced. A centralized resource layer could easily become a dumping ground for unrelated values. And once values could be overridden or inherited from multiple places, it became difficult to answer a deceptively simple question:
Users where left to question
"Where does this value actually comes from?"
Theme Sets already represented a reusable, brand-specific configuration that could be selected at runtime. Instead of introducing another abstraction, I explored expanding what Theme Sets & design variables could do.
Shaping the architecture
Where should design variables live?
While Theme Sets supported swappable experiences, they lacked granular customization. Design tokens provided the exact semantic architecture we needed, but we had to decide where they should sit within the hierarchy.
Org-level + Scoped tokens
Pro: Greatest flexibility across shared and localized tokens
Con: Most complex to explain and onboard builders
Org-level tokens only
Pro: Global consistency without a layer to maintain
Con: Can't build a reusable, brand-specific token set for B2B2C
Scoped-tokens only
Pro: The implest mental model
Con: Less flexible for one-offs
Scoped-tokens only was the best option
Compared with the combined direction, the ownership was much clearer: brand-specific values lived with the brand context that supplied them. This gave us the behavior the B2B2C use case required, while keeping each brand context independent.
Working around edge cases
How do we prevent runtime errors?
Introducing scoped tokens created a dangerous edge case. If Theme A defined color_primary but Theme B didn't, swapping themes at runtime could leave the template with a broken, unresolved value
What if we enforce a shared universal token schema?
When a new token is created, it is automatically added across all Theme Sets. Themes can have completely different visual values, but they will never have different structural shapes, ensuring seamless runtime handoffs.
From architecture to interface
Before
A standalone, repeated experience that requires workarounds

After
A shared, reusable system that's adaptive, scalable and consistent

where builders make and manage variables
where builders reference a variable

The next opportunity
Token Management System

──── ୨୧ ────
Key Takeaways
My previous internship was heavily visual—I spent a lot of my time thinking about visual direction, assets, layouts, and how things looked.At Persona, the people pushed me to care just as much about the logic underneath the craft as the craft itself.
The interface was only the tip of the iceberg
Artefacts & diagrams showed invisible trade-offs
Protyping with Cursor, choosing the right fidelity







