Architecture - product vs marketing

[taysea]

Similar to previous explorations on density work, prior to v1 release we should explore how we might support different token values for marketing vs product. The reason to explore this prior to v1 release is in case there are any architecture adjustments to be made now to avoid breaking changes.

Some initial feelings we have are that:

• Marketing design tokens that differ from product should be housed in a separate file (rather than being a mode within existing collections). The reason for this is that a designer would not be likely to toggle a design from product --> marketing or vice versa. Rather, marketing designs are fully distinct.
• For the most part, the primitive values for marketing and product are likely the same (same color palette, base dimensional unit, etc.). Where they differ are that typography sizes might be "sized up" for marketing use cases and potentially component sizes as well.

In exploring architectural decisions, we some initial test scenarios to consider would be:

• We decide that marketing needs to have a "sized up" typography scale -- how should we deliver this?
• We decide that marketing needs to have different button treatments (bigger and with different colors) -- how should we deliver this?
• Other test cases?

Success Criteria:

• Support the needs of the average product designer on the Web team

• Maintain single source of truth and minimize duplicate efforts when updating across both product and web.

• Updates and management of web tokens should not disrupt existing workflow and management of current “product” tokens.

• Web & Product Themes should not be dictated by ‘modes’ as a designer would not be toggling between the two

• Offer a recipe/example on how to achieve breakpoint differences with tokens

---

Test Scenarios
Typography Scale: Evaluate the ability to adapt typography scales to accommodate different contexts and breakpoints.
Component Styling: Test larger scales or alternative treatments for components like buttons, ensuring compatibility across themes.

---

Key Question
Is the end goal to have the design system support and work in tandem with the Web team in the same way it does for the Product team?

---

Bonus Feature
Enable support for language translations (e.g., using dummy text for testing and validation).

Deliverable:

• Test Figma or coded token files to demonstrate proposed architecture: https://www.figma.com/design/JZjIz3XwwvbGKVAsfhcR1S/Multi-Product-Theming?node-id=0-1&t=S7iG6cyIynW2Oj6F-1
• Documented approaches: https://www.figma.com/design/JZjIz3XwwvbGKVAsfhcR1S/Multi-Product-Theming?node-id=0-1&t=S7iG6cyIynW2Oj6F-1

[taysea]

Closing this ticket. Based on the research explored, there is nothing with our current architecture that would stop us from extending to add a marketing theme in the future. There are a handful of options/approaches, each with some pros/cons. When we want to extend we can revisit to decide on the exact approach.