Design tokens
Reframing design token architecture to foster design clarity.
Site update in progress 💡
I'm currently upgrading my portfolio, improving both visuals and content presentation. Please bear with any temporary inconsistencies. Feel free to reach out if you'd like to discuss anything in the meantime!
Eric Cheng, Jan. 2025
Time
2024
Team
Experience Design
Creative technologist
Web development
Role
Product Designer
Tools
Figma
Google sheet
Jira
Confluence
Context
Product team relied on generically-named tokens at the beginning of design system development. However, as the product scales, the generic naming often lead to decision confusions then reflected in inconsistent product design and scaling, inefficient cross-team collaboration and longer QA process, defecting the product quality.
Objective
Enhance the design tokens architecture to clarify usage, maintain scalability.
Problems
Ambiguity in naming abstraction
Consumers struggled to interpret and connect abstract token naming informing design decisions.
Scalability barriers
Designers were limited from feature expansion efficiency then scarified compliance over product experience.
Solution
I specified action-specific alias token layer that clarified token usage from token naming and established consistent naming structure for scaling. I also worked with consumers to deliver a token application guidance that enhance the scalability of product and reduced the application confusion.
x
Faster design review
x
Faster design iteration speed
x
Faster QA time
%
Increase collaboration satisfaction
Scroll down for full story
Goal
Improving the design token system to minimize decision confusion, fosters design consistency in product design, and enhances cross-team collaboration.
Research
8 Designers
3 Engineers
1 QA
What difficulties do you face using design tokens to inform design decision?
How does design tokens impacting handoff workflow between design and engineering?
What problems does design token bring out before product rolling out?
Actionable observations
1️⃣ Overly generic names
Token naming is unclear to consumers informing design decisions.
2️⃣ Risky maintenance
Token abstraction layer mixed different design decisions.
3️⃣ Misalign with business goal
Token structure missed to provide flexibility for agile product development goal.
How might we
…design a token abstraction structure that balances flexibility for agile product development and consistent maintenance?
Creating a balance through token abstraction layers.
…create a token naming strategy that provides clear to improve consistency and ease of implementation?
Integrate context into token naming.
Token consumer workshops
Benchmark
Phase one of the token exercise, we leveraged different affiliated token frameworks on Suzy Design System to expand perspectives, uncover potential models to learn from, and foster collaborative understanding between design and engineering.
Design assets taxonomy
We brought insights to reflect on our design and explored various ways to categorize existing assets, drawing inspiration from benchmarks and analyzing natural groupings and hierarchies. The key takeaway: overly abstract taxonomy confused stakeholders, while overly simple anatomy lacked scalability.
Trade-off analysis
After analyzing pros and cons for application feasibility and long term scalability with different sorted approaches, we placed all ideas on a trade-off analysis grid to find out which direction work the best for us to organize and maintain as product feature expands.
Design token structure
Abstraction layers
I designed two layers of token abstraction that both provide flexibility through secondary variations to scale design decisions in an agile environment and keeps high-level consistency control by contributing design choice to a singe source of truth.
Alias token namespace
Outcome
Design token adoption
The consistent token set up reflected in both Figma variable(for designers) and the Storybook(for developers). The clear abstraction naming improved design accuracy and scalability, enhanced collaboration between teams, reflected more consistent product experience.
Reflections
Takeaway
Think beyond immediate needs: Holistically consider long-term trade-offs ensure longevity, adaptability, and work efficiency for the product and business.
Positive team moral build success product: Effective delivery of product comes from active team contribution and feedback loops, a product is the reflection of team moral.
Next step
Automate token generation and management to enhance adoption efficiency.
Improve token documentation to improve design token advocacy.
