✨ Joykit Emails

📌 Light mode recommended

A design system created for Joy's 2025 email overhaul.

There was an intention to introduce a newer design language which was stress tested with the development of an updated lifecycle email launch. A design system that was Claude compatible had to be created to support this project.

ROLE

Product Design Intern

RESULTS

Responsive components that could be translated into dark mode

150+ lifecycle emails redesigned with said components and design system

Streamlined our end-to-end email production cycle.

2x more engagement with lifecycle emails post-launch

Before

After

Opportunity areas i.e. defining our design brief

Dev remodels

Dark Mode

Creating new color styles that are dark mode compatible. For example, a brand primary that can be translated into dark mode without becoming unrecognizable.

Google fonts

Coding emails necessitates the use of google compatible fonts. (In the past, emails were exported as PNGs)

CTAs

Color story

Brand purple should only be used for CTAs. Primary CTA (filled round button) is always brand purple.

One primary CTA per email

Too many primary CTAs distract and overwhelm the user.

More direct windows to product

Currently CTAs lead to blog articles when they should lead to specific product features.

More direct windows to product

Currently CTAs lead to blog articles when they should lead to specific product features.

Design language

Images > text

We're promoting Joy!

Cleaner baseline

The main focus of the emails should be the product features and couple images. Backgrounds and text should be neutral colors.

The actual kit.

Atomic design principles

When designing the Joy Email Kit, I began with the child components. A dark mode compatible color style, an Google font compatible typography style, a diverse button collection, and scalable logos, images and tags. From there, I could establish a system for information hierarchy i.e. large cards, small cards, and blocks.

Claude compatibility i.e. connecting system to code

Defining the system

Code Connect

Mapping your Figma components to your actual code components, so Claude reuses what you've already built instead of reinventing it (big one for teams)

/References

A folder of screens so it can match real layouts and feel..

More direct windows to product

Currently CTAs lead to blog articles when they should lead to specific product features.

.mds

Claude.md

Loaded in full at the start of every session, that points Claude to your real token files and component library in code

Design.md

A readable map of the system so Claude has the vocabulary in context without re-querying Figma on every build

Reviewing outputs

Design-reviewer-agent

Checks each screen against the system and flags where it drifted

Build-screen skill

A skill loaded that runs those checks the same way on every screen

Results and takeaways

“A design system acts as the connective tissue that holds together your entire platform.”

2x

more engagement with lifecycle emails post-launch.

150+

lifecycle emails redesigned with said design system.

Design for your future self

When creating a design system that an AI tool can properly use, details matter the most. Stay organized, make sure each layer is properly named, and make sure the rules are clear enough for your future self to understand 10 years down the road.

Component architecture and the world of tokens

'Component architecture' isn't just a buzz word. AI is trained on available data, so use pre-existing standards for design systems to define your variables, because that's how Claude will define your tokens.