Persona Identities
Designing foundational systems that power customization across millions of verification flows for OpenAI, Reddit, Brex
Context
One customer, many brands
Persona helps businesses build customizable identity verification experiences through Inquiry Templates. Each template acts as a mold for the end-to-end verification journey, defining everything from branding and UI text to verification logic and edge cases. At runtime, a Theme Set is applied to control the visual properties—such as colors, sizing, and spacing—that are propagated to the end user.
My Role
Persona’s customers were increasingly using Theme Sets to manage branded experiences across thousands of templates and multiple sub-businesses. But as these systems scaled, branding decisions became repetitive, difficult to maintain, and prone to inconsistency.
I explored how Persona could evolve Theme Sets into a scalable, reusable system for managing brand configuration—particularly for complex B2B2C organizations.
The Problem
Why are we defining the same thing over and over again?
Customers were repeating the same values across templates instead of defining them once and reusing them. For example, a single brand color could be duplicated hundreds of times across templates, meaning a change required updating each instance individually.
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
Resources as a container for everything
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.
Default set + override: to have a default set containing the organization's baseline values, then layer overrides on top for specific B2B2C scenarios.
Collection + variants: Instead of having one giant default container with overrides, you'd organize related resources into collections, with different variants/modes representing different brands or contexts.
Default values + overrides
A superset with override values layered on
Collections + Variants
Borrowed from Figma's design-variable architecture.
They introduced the same two problems: bloat, with unrelated resources accumulating in one place, and ambiguity, with no clear answer to where a value actually lived.
Most importantly, we realized we already had the foundation: Theme Sets shared the core properties we wanted from Resources—reusable, brand-specific configurations that could be selected at runtime.
Design decision
Expanding the power of Theme Sets
Theme Sets already supports swappable branded experiences, what they lack was just more granularity and customizations. Design tokens now acts as the right unit of reusability and provide a semantic information architecture for brand decisions
Design decision
A safe swap needs one shared shape underneath
Scoped tokens created a new risk: if Theme A defined color_primary and Theme B didn't, swapping at runtime could leave the template with an unresolved value. I chose to prevent the mismatch altogether: all swappable Theme Sets would share one token schema. When a new token is created, it is added across Theme Sets, so they can have different values, but never different shapes.
Landing on the final solutions
Theme Set Editor
Flow Editor/inline/other surfaces
Select the primary button and easily apply a design token.
Creating a reusable font, spacing, weight, or bundle of these variables
An image asset like logos, graphics, etc can also be turned into a token
A proposed solution
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
What looked like a UI problem was really a systems problem. Changing the relationship between Resources, Theme Sets, tokens, and variants fundamentally changed what the interface needed to be.
🛠️ Artefacts & diagrams showed invisible trade-offs
I stopped treating diagrams and prototypes as just artifacts for communicating a solution. Each prototype helped expose trade-offs, challenge assumptions, and eliminate weaker models before they became more expensive to build
Protyping with Cursor, choosing the right fidelity
This was my first time working in Cursor, and it quickly became one of my most useful tools for exploring ideas. I could make a system interactive in a matter of minutes and experience the consequences of a design direction instead of just imagining them.
But I also learned that high fidelity can make a weak concept feel more resolved than it actually is. It was a lesson knowing when to push the prototype further and when to step back and rethink the idea in the canvas.