Mostly Working

Tom and Jonny sit down with Cassie Groos, design systems lead at Unily, to learn what happens to a design system once AI starts reading it. They dig into the prose documents that brief her agents, unpack a token architecture built for an infinite number of brands, and go behind the scenes of her first big stage at Hatch.

Key takeaways

  1. AI now reads the design system as well as helping to build it. That was the thesis of Cassie’s Hatch keynote. A system built for agents ships with context, skills and, more and more often, its own MCP server, so someone can ask an agent a question about the system and get the answer back.
  2. Every component at Unily gets one prose document that its agents work from. Cassie calls it the CRD: a semi-structured document covering a component’s properties, requirements, behaviour and accessibility needs, including the details Figma can’t hold. It briefs the agent that builds the component and feeds its tests, and any agent using the component later reads it too. Send an agent to a polished documentation site like zeroheight instead and the human-friendly prose ‘blows out its context window’.
  3. Spell out what every designer already knows. Any designer knows the red button is for destructive actions. AI might decide purple suits it better, or that the brand red belongs on every primary button. Cassie reckons AI gets things right about 80% of the time, and more context plus repeated checks are how she closes the gap on the other 20%.
  4. Have one skill do the work and a second, stripped-back skill check it. Cassie’s contribution workflow, built so people outside the design system team can contribute, pairs a skill that holds the conventions with a review skill that has the same conventions and nothing else. Each check gets a little closer because the reviewer isn’t carrying the original context. She also runs a ‘Simplify prose’ skill over everything, borrowed from a friend and modelled on Simplify for code.
  5. Feature design is leaving Figma, and component design is staying on the canvas. Cassie expects product, feature and flow design to move out of Figma, with Figma Make catching some of it. Components for complex, multi-brand systems still need a visual canvas, and Figma variables remain the hub for Unily’s tokens. She is ‘not in the Figma is dead, everything lives in code now camp’, and says Figma has become far more responsive to the design system community over the last 18 months.
  6. At Unily, clients bring their own brand at runtime. Cassie calls it ‘infinite multi-brand’: any client can set up their brand through a self-serve journey, across light and dark mode (with high contrast to come), each with several colour schemes. Clients pick from presets, so spacing comes as spacious, regular or compact, and hundreds of tokens across several layers sit behind every choice. Unily’s AI assistant, Indi, then builds clients’ intranets from the system’s blocks and components with their branding already applied.
  7. Skipping the design system shows up in brand and trust. Agents can move fast without one, and a design.md file will still spin up slightly different buttons all over the place. Cassie calls ‘we don’t need design systems anymore’ a trap, and expects people to gravitate towards brands that still feel consistent and human-made. Hence the line from her keynote: design systems matter more now than ever before.
  8. With a CRD and a rough design, Claude can build five to seven components in a day. On her single-brand side project, Cassie asked Claude for a token architecture from a handful of colours, and it did ‘honestly a great job’. A workflow now helps her write each CRD, and the CRD plus a rough Figma design is enough for Claude to build the component. For a team of one or two, she’d start with buttons and fields, and for anyone who isn’t a design systems specialist, adapting an open-source system is perfectly fine.
  9. AI is good at going wide, and converging is still the designer’s job. Cassie has had Claude Design throw out ‘a million different design ideas’, but picking out three screens, spotting that there’s something there and perfecting them is work she does by hand, in a way she can never get Claude to. Perfecting that first flow and its components also stops AI taking the edge off later. She has watched Claude Design take someone’s design and make it ‘look a bit numpty’.
  10. Claude is now Cassie’s guide to a token architecture she built by hand. She says it ‘probably understands it better than I do now’, and the idea of going back in herself is ‘terrifying’. She asks it to tidy up anything clunky, such as the shadow tokens, and before she deprecates tokens it checks they aren’t used in any component, so the change won’t break anything.
  11. Apply for the talk you think you won’t get. Ben Callahan, who runs the Redwoods design systems community, tagged Cassie when Hatch’s Damian Martone asked for more European speakers, and she applied assuming she’d never be picked. She planned to learn the talk like a theatre script, then spent the five days before Hatch in hospital and walked on stage with a walking stick, too tired by then to be nervous. Her advice to anyone thinking about it: do it, because the audience is there to learn from you.
  12. Claude can draft the weekly Ocado order with a skill, a list and a few months of past orders. Cassie’s setup is a skill, a shopping list in Notion, a couple of months of previous orders so Claude can work out what she buys weekly, every two weeks or monthly, and Claude in Chrome to do the clicking. She’s holding out for Ocado to release an MCP.

Chapters

  • 0:08 — Welcome, and meeting Cassie through Hack Weeks and Hatch
  • 1:46 — What is a design system, anyway?
  • 4:04 — AI as both contributor to and consumer of the system
  • 5:52 — Jonny on agents that start from scratch every time
  • 6:47 — The CRD: one prose document per component
  • 8:56 — Telling AI what any designer knows, and its unpredictable 20%
  • 10:07 — Contribution workflows, a prose simplifier and review skills
  • 11:22 — Where the system lives: Figma, code, or both
  • 13:19 — Product design leaves Figma, component design stays on the canvas
  • 14:55 — Jonny on the design system as software
  • 17:16 — Design systems as a product, and feeling more like an architect
  • 18:28 — Unily’s infinite multi-brand problem, and presets
  • 19:46 — A token visualiser built for an audience of one
  • 20:36 — Indi, AI-checked token pairs, and nested modes
  • 22:41 — Tom on brand, marketing and the edges of the system
  • 26:58 — Several design systems, one token architecture
  • 28:38 — Jonny on consistency for its own sake
  • 30:35 — Why ‘we don’t need design systems anymore’ is a trap
  • 33:17 — A minimum viable design system for a team of two
  • 36:25 — From brand feel to code, and Tom’s Mostly Working canvas
  • 38:45 — Exploration as the human part, then one flow at a time
  • 40:55 — Tom on diverging and converging with AI
  • 43:51 — Using AI to untangle a hand-built token architecture
  • 47:18 — Getting on the Hatch stage
  • 50:46 — Why design systems are suddenly in demand
  • 52:37 — Quick-fire: getting Claude to do the food shop
  • 53:55 — Quick-fire: life after AGI, a four-tool stack, and Terminal
  • 56:26 — Where to find Cassie

Mentioned in the episode


Cassie Groos


Unily


Communities and events


People


Tools and products


About the pod

Mostly Working (formerly the Near Future Podcast) is a weekly conversation with design leaders about what they're building with AI. Send feedback to hello@mostlyworking.co, and find everything at mostlyworking.co.



Find us at nearfuture.works

Creators and Guests

Host
Jonny Burch
Co-founder of Near Future
Host
Tom Harman
Co-founder of Near Future

What is Mostly Working?

A weekly podcast covering design and AI by Tom Harman and Jonny Burch. We cover both what we're seeing on the ground and industry trends, ways of working and occasional guests from the design world.

Jonny: welcome to another episode of
the Mostly Working podcast with Tom and

Jonny, where we talk about design and
AI and all of that kind of good stuff.

we are joined by Cassie Groos,
who met about 18 months ago

probably, as one of the first ever
participants in our Hack Weeks.

Tom and I were running one week, hack
sessions with designers to work out

what we could build with AI, back when
it was, like, Lovable and, the, the

early tools that were kind of crappy but
interesting and magical at the same time.

And we had a great week, and
have kept in touch since.

Then I bumped into you, Cassie, at Hatch,
where we were both speaking, so we're

gonna cover what you, what you about at
Hatch, and your YouTube video of that

talk is at, like, 30,000 views already,
so you're basically famous at this point.

I will ask for my autograph.

but, you have a, a good history in
design systems, and I think that

that's where we're gonna touch on.

This is gonna be a design
systems episode of the podcast.

Tom and I are not experts in design
systems, so we're gonna be learning

along with everyone else listening.

and, you have been working on an
extraordinarily complex design

system over the last couple of
years that we're gonna hear about.

so Cassie, over to you.

I'd love to start by just asking you,

what is a design sy-
what is a design system?

I'm gonna, I'm gonna just
gonna go straight into

Cassie: How long are they?

okay.

Firstly, thank, thank you for having me.

It's really great to be
back talking to you guys.

Hack Week was so much fun, and probably
set me off on my, like, obsession with

AI workflows as well, which is where
I've been, like, digging in deep.

design systems.

What is a design system?

my talk at Hatch was, essentially what
the fuck is a design system anyway?

Which was discussing how design
systems are evolving, in the age of AI.

We're calling it that.

Sounds kinda twee, but
guess that's what it is.

and how they are shifting from being,
I guess, a set of resources that

everyone mostly understood to something
that is, is fluid and, and changing

and evolving right in front of us.

so the easy answer is
probably what it was.

I can…

Yeah.

So

Jonny: Do, do what it was,
because I think that's, for

Cassie: yeah

Jonny: what it is.

Like, I'm, I'm like, still in, I'm
probably in, old world parlance.

I understand it as, like, a set
of tokens that might be colors and

stuff, and then a set of components
maybe built in Figma, but maybe

also the same as the ones in code.

And correct me, where,
where am I, where am I off?

Cassie: Sure, yeah.

So, so originally the, the old school way,
a set of components, a, a Figma library.

Once upon a time, a, a
Sketch library of symbols.

and then we got variables in Figma,
so designers started kind of managing

like tokens as part of those design
systems, so then it became components

and tokens, and also governance and
contribution models, and enablement,

and foundations, and documentation.

And that was kind of what you
would consider a design system.

But the kind of running philosophy is
that a design system can be whatever

your organization needs it to be.

So you can kind of cherry-pick
the pieces that work for you, but

those are generally the, the main
building blocks of a design system.

AI.

So the kind of underlying thesis of
my talk was that AI is now both a

contributor to design systems and
also a consumer of design systems.

we're obviously seeing a lot
of vibe coding and AI-assisted

development workflows.

and so that sense, AI is very
much a consumer of design systems.

Ideally, if you are building
a product with AI, and you are

using a design system, and you
have a system that is AI-enabled,

then you are gonna get better, more
consistent results in your product.

That's kind of where,
where we're getting to.

what does that mean practically?

it means that it comes with context, so
kind of more information for AI because

it doesn't know the things that we know
as designers, and the things that we

think might be obvious are less obvious
to AI, and it likes to make things up.

skills.

So actually providing the skills that
we want, you know, the consumers to

use or providing, potentially even
skills for querying the design system.

So instead of having documentation,
you can have an agent that they can ask

a question to, and it can go away and
just like come back with the answer.

yeah.

And then also things like MCPs.

You know, seeing design systems kind
of, launching their own MCPs now so

that, yeah, even more AI-enabled.

that is, yeah, the
direction that we're moving.

They're becoming bigger, more
expansive, and more complicated.

Jonny: Yeah.

And I suppose interesting what
you just said about agents

knowing less than humans.

Like, time I spin up a new agent to
do a piece of work, it's basically

starting from scratch over again.

I

Cassie: So yeah

Jonny: historical knowledge.

I can't rely on the fact that that agent
actually was the same technology that

built the bit, that bit of the design
system that I now wanted to reference.

It's forgotten that.

So,

Cassie: there's nothing.

Yeah

Jonny: so to-- So you're
basically bootstrapping a whole

new designer every time you, you
want to build a piece of design.

And so what would you tell
that designer from scratch?

that mean that then the design system has
to be far more complete in terms of not

just listing components and decisions, but
actually describing why, why they exist?

Or is, that what you're--

Cassie: Yeah.

So I think What is it that
we're giving in context?

So, so for example, what I have
developed at Unily is something that

I've been calling a CRD, 'cause super,
super creative, component reference

document, which is a semi-structured
context document that outlines

everything that a component is, so the
different properties, the different

requirements, the different kind of
behavioral expectations or specific

accessibility requirements and, and so on.

and so that tells basically the AI
building the component, everything that

it needs to know about that component,
things that might be especially missing

from Figma, and helps to kind of build
the tests that also, you know, get

used on the build of the component.

it also then serves the consuming
agent so that they know everything

about the component, including,
like, usage information.

so I think having things up front for the
agent, like, you know, it's just, it's

the same things that you might have for
a human, I suppose, in the documentation

website, but it's just provided in a way
that is more accessible for an agent.

If you send the agent to a super
fancy zeroheight like documentation

site, it has a lot of human-friendly,
kind of pros to sift through, which

just blows out its context window
and makes its little brain melt.

but yeah, it, it, it kind of needs the
same information that, that a human needs

in terms of, here is a component, here is
how you use the component, here are the

different properties of this component
and when and why you should use those

different properties and, and so on.

we do take for granted a lot of the
time that our designers will be able to,

like, infer a lot of that information
because they just know what they're doing.

You know, it's really obvious that
obviously you use, like, the red button

for destructive actions and things like
that, but, you cannot necessarily trust

AI to know those sorts of things, even
the things that seem really obvious to us.

Sometimes yes, sure.

Sometimes just, just no.

Just no.

It might just, it just, you know,
like it, it feels like purple

is a, a great color for that
instead, or it feels like red is…

Oh, it's also the brand color, so
why don't we just use it for all the

primary buttons too or, you know.

there is that kind of like 80/20
argument in that the, well, philosophy,

assumption, estimation, I don't know
how well it tested it, it is these days,

but that just it feels like AI gets
things right about 80% of the time.

and then 20% of the time it, it does
wildly unpredictable and weird things.

and so providing more
context, and also checks,

Jonny: Yeah

Cassie: help to, to close that gap.

So one of the things that, I've
been doing, so on top of the CRD

work is also contribution workflow.

So it's like a, a set of a number of
skills and a number of documents that

make it easier for non-design system
people to contribute to our design system.

So that's moving towards
like a federated model.

and within that, one of the things
that I got, which I borrowed from

a friend, is a Simplify prose.

So similar to like Simplify for
code, but just for prose, and

just constantly running that
over everything that it, it does.

And also like a review skill.

So you go through and you have
like your conventions or, or

whatever you expect it to do, and
you run it, and it does the thing.

But then you also have another skill
with the same conventions, but all

the other stuff taken out, and you
run it, and it checks the thing.

Jonny: Mhm.

Cassie: And then maybe it checks it again.

And that helps you to, to close that
gap, and just making it check its work

like over and over again kind of gets you
a little bit closer each time, because

it's not dealing with all of the context
from the initial kind of piece of work.

Tom: s- so many questions that
are percolating in my head.

you mentioned the Old World Figma tokens
or a design system living in Figma.

a lot of what you're describing there
feels, and if I'm putting words in your

mouth, but it feels a bit more code, Or
is-- Where does this stuff live, where

Cassie: Yeah.

So for me, like, sorry,
I'm, I'm a designer.

I've been working in like Figma for, for
years, and I still feel like Figma is

the central place where I can kind of
manage and control the design system.

Although I work mostly through
skills now, I still need that canvas.

So especially for like component work,
I need that canvas for just like getting

into the nitty-gritty of a design.

and in terms of managing like the
tokens, we, we built out the token

architecture with, with Figma variables,
and despite kind of missing some features

that arguably are quite essential,
we have managed to work around that

with, you know, conversions and, you
know, export, scripts and, and so on.

and so still using Figma as the kind
of like main hub for managing it.

But in terms of like source
of truth, I think my…

It depends.

It depends on source of truth for
what, when, why, and so sometimes

it's code, sometimes it's Figma.

When it's Figma, it is now Figma plus
the CRD 'cause that kind of closes the

gaps on, on what Figma can't provide.

But yeah, I, I am not in the
Figma is dead, everything lives

in code now camp like at all.

so,

Tom: And, and, and if you, if you
sort of project out for the next six

months or 12 months, do you still
see that setup being sort of similar,

a bit of Figma or a bit of code?

Or do you think, do, do you have a
prediction of which direction it's

gonna head in and where you would
like to be working a year from now?

Cassie: Yeah, I actually think that
product design, feature design, flow

design is probably moving out of Figma.

I think they may capture a
bunch of the audience with

Figma Make, which, like, great.

but the component design, like especially
for bigger, more complicated systems

where you actually need things to be
really stable or where you are, like,

handling multi-brand environments.

Like, sure, you can, you can spin up,
like, a super simple design system

with, with Claude Design, right?

But you, you cannot handle any
kind of level of complexity

there, like, whatsoever.

so I, I definitely see a visual canvas,

Jonny: Mm-hmm.

Cassie: still being the kind
of like hub of component design

and design system management.

Whether that is Figma or not is
gonna depend on what moves they make.

but they're, they're
doing pretty cool things.

They're doing pretty cool things.

They're-- I think, I'm seeing a lot
of responsiveness now to the design

system community from them that
did not exist maybe 18 months ago.

yeah.

Jonny: Interesting.

Oh, the way you talk about building
this to-- I, I suppose to build on

Tom's question, the way you describe
it feels like a fully functioning,

like, piece of software that
supports the building of software.

It's like a tool beyond p-
being a piece of design.

always thought previously maybe of a
design system as being, like, broadly some

design conventions wrapped up in pieces
of code that sort of encapsulate them.

And it feels like now it's so much more.

It's like f-philosophy.

You have to define so much about why
you're even doing the things you're doing

and, and not just that, but you need to
build all of this software around these,

like, decisions about tokens and, like,
border radiuses, you know, whatever.

you need to build layers of software
around it to make it accessible in

different directions, to make it an
easy part of an engineering workflow

so that it's testable, so that you can
work out why it regressed at some point

in time and, like, a different model.

And, like, all of this kind of stuff
seems so much more than design work to me.

and when you describe, like, a,
Figma's role in it or, like, a canvas's

role in it, I can totally imagine.

And f-from my experience recently of,
of really getting back into tools,

the canvas is so useful that you can
just be like, "Okay, I'm gonna put 10

versions next to each other and then
see them all," or, "I'm gonna see all

the variants," or, or whatever it is.

that feels like, in some ways, a
s- a small part of the p- the work.

Like, deciding, making that decision
about how something should look,

or how it should look in different
contexts is piece of work you do once,

and then all of the work is actually
making it behave forever on top of that.

But maybe, maybe I'm wrong.

And I, I've also-- I've realized, we
haven't even covered Unily and what

you're actually doing, and it might
be worth actually as you, as you sort

of this, us more about Unily and,
and the design system you're building

because it is, it's an absolute beast.

So

Cassie: Yeah.

Jonny: will help

Cassie: Yeah

Jonny: some more context.

Cassie: Sure.

I think just to go back to, like, your,
your first point around a design system

being much more than just, you know,
design, I've seen it referred to, like,

within an organization as a product
or an internal service or, you know.

So th- there are, you know, different
ways that, that that can be kind of

built upon within an organization.

Recently, I saw someone talking
about it as a marketplace, but that

I find terrifying for other reasons.

but yeah, definitely it
is much more than design.

I, I don't feel like a, a product
designer that much anymore.

I come from a very long and storied
product design history, but I just feel

like I, I've been moving away from that.

And I think a lot of design system people
call themselves architects, and that's

kind of what it, what it feels like.

One of my favorite parts is, is
developing the token architecture.

so that kind of works with that.

There's a lot of
problem-solving, and I really…

I like really complex token
architecture , solving really, like,

weird and, and convoluted problems.

So, like, the multi-brand stuff
is, is, like, right up my alley.

so yeah, for Unily it is, multi-brand,
but not just we're a company and we

have, like, five different brands and
it needs to work across those, but,

like, infinite multi-brand, where the
clients can bring their own brand and

input that, like, in runtime, via, like,
a, a self-serve kind of journey, which

in itself is, is quite complicated.

And so that requires, like, multiple
levels of, of token architecture

that can kind of realize all
those different decision points.

part of that was, creating what I call
presets, so, like, density presets,

radius presets, and different kind of
groupings that they, they can pick from.

Shadow presets, for example.

So rather than a client being able
to, like, granularly control every

spacing token and value, they get
spacious, regular, or compact.

But behind that is, like, hundreds
of tokens through, like, multiple

layers, like, powering all of that.

And this, this was all built
kind of, like, pre having

AI to help with any of this.

So it was…

yeah, it was a beast.

as one of the, the things I
was talking about your talk

recently to someone, Jonny.

So the idea of, like, building
tools for yourself that you need.

during that phase I, I built a token
visualizer tool just for myself, because

I just needed to be able to see what
I was building in a, in a visual way.

and that was one of the examples
I gave this person when I was,

like, talking about your talk.

So, so yeah, the token architecture
piece was, was a huge part of it.

and then building out the, the component
library in a way that means we can

capture, like, which Which components
are going to pair different tokens?

And then when they create their
brand, that enables us to kind of

accessibility check those token
pairings, which will all be done by AI.

and then all of this is built, for a
system that then has-- So we have like

an AI called Indi who sits on the front
end and supports the clients, and she

will help them build their intranets,
and she will do that out of the blocks

and components that, that we have built.

and the token architecture, so all
of their branding is just applied.

And so just making sure
that, that all of that works,

Jonny: Does Indi

Cassie: across…

Jonny: of skills?

This is

Cassie: yeah, Indi,

Jonny: skills

Cassie: has a bunch of skill.

Jonny: inside…

Cassie: Yeah, yeah.

She, she does.

Jonny: Yeah.

Cassie: I don't, I
don't handle her skills.

or well, different, different teams
handle different skills depending

on, on what she's touching.

But, yeah, it's complicated.

It's complicated.

but it's been interesting.

So yeah, it's just this idea of
making sure that kind of everything

you build is gonna work across every
brand, across light mode, dark mode,

and eventually high contrast mode.

And then within those modes,
there's like multiple schemes.

So there's like different color
schemes so that they can have

like variation on the pages.

And so it's just so many nested
levels of, of complexity.

and then you have also typography
and, you know, them wanting to change

everything about the typography
themselves and making sure that

that still feels like all, you know,
cohesive, like in a hierarchical sense.

So yeah, it's, it's a lot
and it, it's a process.

and I kind of had this vision for
the architecture, but did it without

knowing what the designs were gonna be.

So we have the architecture in place,
and now we're kind of finessing

different values as we work through
different features and stuff.

But yeah, it, it melts my brain if
I stop to think about it too long.

Tom: Yeah, it, it does.

There's, there's so

Cassie: Mm-hmm.

Tom: here, Cassie, and I wanted
to push the edges of the brain

melting a little bit more by

Cassie: Absolutely.

Tom: We've had a, a few guests recently,
or spoken with a few people, who are

working in brand design or in the sort
of brand systems space where there's

brand teams that are building tools that
extend or help bridge the gap between the

product experience and a brand experience.

And hearing you talk about and the s-
the scope you mentioned up front was

primarily around the product, I'm curious
how far that scope is extending or

expanding into other adjacent disciplines.

Like, are you Presumably you're making
some brand-ish decisions, and I'm curious

if you, if brand and marketing assets
and, and things that might not have

historically been in a design system
focused on product are starting to make

their way into this, or how do you think
about those sort of adjacent design areas?

Cassie: Yeah, I think less, less so.

So the way that it has always kind of
gone, and not always ideally, is that the

brand team go away, they hire a branding
agency, they develop a brand, they don't

involve the product team, like, at all.

They come back with a bunch of colors
that are completely inaccessible.

and then the product team has to figure
out how they're gonna take that brand

and make it work for the products and,
and I think that still kind of applies.

I have worked at different companies
that have given different levels of

involvement to the product team in
developing brands, but that, that is

generally the, the way that it goes.

you could probably kind of loop
background, so potentially once you

have the design system in place,
once you have the token architecture

in place, then the brand teams
could absolutely hook into that.

They could use it.

they don't always or
usually, but they could.

in an ideal world, a system should
be able to support kind of all of

the functions across an organization
that are using any of these values

or, or assets or, or whatever.

But, supporting brand doesn't tend
to get prioritized and I, I think

that also goes hand-in-hand with
brand teams also, I guess, trying

to retain their, their autonomy,
which, you know, tends to work fine.

Tends to work fine.

Tom: Yeah.

Yeah, that makes

Cassie: Yeah

Tom: Yeah, I was, I was curious about
the, how the contribution model might

change or evolve based on sort of new, new

Cassie: Sure

Tom: more connected.

and maybe to make this a bit more
specific, we-- Jonny and I were

working with a, a company six months
ago, a year ago now, who had a focus

on creating social assets, and at the
time, they were building in Figma,

some basic tooling that would give them
a, a static image generation-- or not

generation, static image guidelines
to create assets for social media.

then they were sort of starting to
explore building that in code and,

extending that as a system, and then it
started to feel a bit more like that's

a design system, but just with a, a
very specific use case attached to it.

And yeah, I'm kind of wondering
when those worlds will start to come

together or if, if they ever will.

I know the old world has-- I, I, I
share your experience with brand design,

product design, completely independent,
and then sort of starting to like m-merge

them, smudge them together when, when
they're-- push them together, when

they're sort of trying to-- w-when
that's where integration is happening.

And I think that makes sense for like
big, big brand overhauls, but I'm sort

of more curious about these sort of
gradual incremental extensions of a

brand and how it appears in surfaces
that feel similar to a product.

Or it's social media, but it does
feature the product in some way in the

asset itself, so therefore, it should
probably take the tokens from that.

And then, yeah, it just

Cassie: And all right

Tom: the complexity.

But anyway, tell us, what is the

Cassie: I hope so.

you actually do see within some
organizations multiple design systems.

So perhaps they have a design system
for a product, or they have a design

system for their products, and then they
have a design system for marketing and

social, and, and those are separate.

They don't need to be separate.

you could also have a, a setup
where you have different component

libraries, but they all feed
off the same token architecture.

That would be ideal.

but I think actually what, what
feels likely as we move towards more

AI-assisted kind of development is
that eventually marketing teams will

pick up on this too, and they will
wanna start just having Claude spin

up their marketing website for them.

And when that happens, being able to
point Claude at the company's design

system will, will be ideal, you
know, and will enable that for them.

So potentially that will
help to, to close that gap.

I did, when I started at Unily, speak
to like 40 different people across

the organization just to get a, a
lay of the land, and I spoke to a few

people on the marketing brand team.

because like ideally for me, I
wanna be able to support everyone.

but it, you know, in a very fast-paced
product environment, just getting,

getting the time and space to
expand that, that remit is, is so

challenging, and, and the product
work generally just is always gonna…

There's always gonna
be more of it, so yeah.

Jonny: I think it would-- Back in the
day when I was design system-y stuff

or, or involved in teams that were
anyway, there was a failure state

that we used to talk about, which
was like consistency over basically.

It's like we

Cassie: Yeah.

Jonny: To be consistent, so we need
a design system to make everything

consistent, and we sort of forget why
we're doing it in the first place.

Like, why does it actually matter
to make all the buttons the same?

We've audited all the buttons that we use
17 different button styles across the app.

We need just one button style.

then being why?

Like,

Cassie: Mm-hmm.

Jonny: why does that matter?

Is it because we believe that
the user experience is poor?

Is it was because it's actually an
engineering efficiency gain, like

we just need all the engineers to
know that there's one button and

they don't have to make another
decision or, like, a new button?

this is like, again, in, in like
the old world, it feels like,

agents now have this infinite ability
to recall from documentation and

operate in very different ways.

They don't take shortcuts in the same way.

They might take different shortcuts.

but I wonder if the same
thing still applies.

Like, how important is it for us to
build the design system touches every

aspect of the brand and marketing and
everything and every- everything and,

like, everyone can use versus, no, this
is the bit where it actually impacts

the, the business goals or the customer.

And the brand team can do what
they want for another year.

That's fine.

Like, just let them, you know,

Cassie: Yeah

Jonny: clear up the mess later because we
don't quite know what they need anyway,

and we'll end up, like, building all
of these new things that will only be

used in one code base or in one place.

I, I'm just wondering, like, maybe Unily
is a good example of this or not, but,

what are some, what are some traps

Cassie: Some traps.

I, I think you make some,
some really good points.

So spending a bunch of time, trying to
support the marketing and branding team

would probably be a trap right now.

It's probably not, not hugely necessary.

it's just a nice-to-have.

the points that you raised around the kind
of like value of design systems for making

things faster, making design faster,
making development faster, in a way that

is consistent and maintains quality,

Jonny: Mm-hmm.

Cassie: stands.

That, that remains true.

Obviously, agent-based workflows
mean that we can move really

fast without systems too.

but they won't be consistent.

They won't necessarily
always be high quality.

You could have a design.md

file, sure, but it will still spin
you up, like, slightly different

buttons all over the place, regardless.

And what that does is it impacts,
like, user perception of your brand.

It impacts your ability as a brand to
control the kind of, look and feel and,

and how your brand is represented in the,
in the world, and I think that kind of

like, you know, brand expression is, is
very important and is likely to become

more important, as we move forward.

And it impacts kind of user trust,
you know, and, and how quality they

think your product is and how much
they can, like, buy into your brand.

And so I think I'm seeing a
lot of, "We don't need design

systems anymore, you know.

We can just, like, tell the agent that our
buttons are always blue and it's great.

You know, it doesn't, doesn't even
need to be that consistent, you

know, so long as it works, whatever."

that is a trap.

That is a trap, and it will be,
like, really damaging, I think, to

brands that, that go down that route.

and I think we will see people,
gravitating towards trusting the brands

that have consistency, that don't feel
like they have just been spun up by,

by an AI, that feel like they have
that level of, like, human integrity

and, and control and, what are we
calling it, taste or whatever, input.

So yeah, I think as I said in my talk, m-
more important now than, than ever before.

Jonny: Yeah.

and, to be clear, that wasn't me,

Cassie: Yeah, no, no

Jonny: the need for a design system.

I suppose like, maybe the reason why I'm
asking this question is a little bit for

me, because as I think we all do, I have,
you know, personal projects, and Tom and

I have a brand for Mostly Working that is
like, you know, in its infancy and, and we

need to work out how, what to build around
it to allow us to move fast and spin up

a new page for events or something, and
know that it's broadly gonna be right.

What is the minimum viable that I or
we should be thinking about for, you

know, we-- As a team of one or a team
of two, there is no dedicated person.

There's no-- We don't have a Cassie,
however much we would like one.

we don't have an engineer
to sort of build this.

So do you have a sense of like what you
would recommend or maybe what you've

done for a project which is yours that is
like enough, but without being like, "Oh

no, I'm just building the design system.

I should get back onto the, the thing"?

Cassie: Yeah.

so I have, yeah, I have a kind
of, like, side project which is

infinitely simpler than, than Unily.

so it is just, like, a single
brand, a bit more playful.

And I use Claude to, to spin, spin up
the original kind of token architecture.

I was like, "Hey, here's some colors.

You know what to do.

Go do it."

And it did honestly a, a great job.

went through and checked it.

Everything's great.

I then, developed a workflow
to basically take…

So I still need to, I
have to do the CRDs now.

It's just, like, so much in my brain
is, like, important, but basically

a workflow now that helps write
the CRDs, so that's super simple.

Then I can do, like, rough designs
in, in Figma and give Claude the

CRD and the rough design, and it
will spin up the component for me.

and so it just really made that whole
kind of workflow really streamlined and,

and quick, and it meant that I could
spin up, like, I don't know, five or

six or seven components in a, in a day.

so I think having something
like that is great, and I am

happy to share it with you.

but I think just if you, if you
were gonna, if you were gonna have

something, like, really basic, start
with the most commonly used components.

Make sure you've got your buttons.

Make sure you've got your fields.

you know, you can, you can lean on,
like, open source systems for that.

You can edit them.

I don't usually find that faster,
but for people who are not design

system people, then that can be
perfectly fine, and there's nothing

wrong with those open source systems.

They're just not as branded.

You guys have a really cool
brand, so I assume you wanna do

something, like, really cool with
every element, that you, you build.

But you can start with those
systems and, and tweak them and

take components and change them.

Jonny: I will say that Tom
has been the mastermind behind

the Mostly Working brand.

So you, Tom, you can speak to that.

But, it feels like at the
early stages when you have…

You sort of have a few opinions
about how you want it to feel, and

that feels like brand at that point.

Like, you're, you're thinking about
brand, then you have like, you pick some

colors and maybe a font, and you have a
mark and, and like how you want images

to look and just a collection of random
stuff, and probably not very much because

you're at the fir- very first stages.

It feels to me like the next best thing
to do is to encapsulate that in code s-

in some way now, and which never used to
be the case, I don't think, because you

would s- you'd be doing it yourself and
it'd be in your head, so you wouldn't

need to worry about being in code because
you would have the taste, and it would

be slow enough that you just, like,
make decisions as you go, as you build

each page or as you design whatever.

Whereas now straight into building
stuff and giving it over to

something that doesn't-- gone
through that thought process.

So even at the very earliest stages, like,
step one is like, mm, how does it feel?

some initial elements.

And then step two is just like, and
get as much of that into a place where

you can then be like, "Now go make 10
variants, and I'm gonna react to them."

maybe we can share it,
in the show notes, Tom.

But Tom has built this mad canvas for
all of our, Tom's mainly experiments,

but our experiments around the Mostly
Working brand, and it's, like that, meme

from It's Always Sunny in Philadelphia
with, what's his name pointing, pointing

at the, strings on the, the wall.

Anyway, this canvas just
goes on and on and on.

Cassie: I'd love to see it

Jonny: like a d- is that a design system?

Did that come from a design system?

Can you use that to
build your design system?

Like, you know, where do
these all back together?

It feels like there's just, like, this
beautiful exploration you can do where you

Cassie: That is what I

Jonny: about what you're doing.

You're just, like, creating.

And then at some point you're like,
"These five things are things I like.

Now make them the, the answer."

Anyway,

Cassie: And that, I think, like,
is, is still the, the really

important human part of, of design,
and probably the other thing that

hopefully will stay on the canvas.

Can you do that kind
of exploration with AI?

Yes, you can, but it is not quite
the same, 'cause it will change

what you have in your head to
whatever it has in its head.

so yes, process for me would be that, that
exploration, throwing it out wide, doing

what we do as designers, being really
creative and, and having a lot of fun.

I probably don't go that wide.

and then

Jonny: it, it is

Cassie: take it

Jonny: when you look at

Cassie: Yeah.

Jonny: It's beyond,

Cassie: And then I would usually…

So for a product, I would usually
then have, like, a single flow.

Like, this is the design, I'm refining it.

A single flow, how am I applying
that brand and look and feel

to an actual, like, feature?

Something simple.

It can even just be, like,
the login flow, whatever.

and then from there you can
start pulling out components.

You can start building
the components from there.

So that is where I would go, like,
CRD plus here is the crazy button that

I built in my creative exploration.

Let's make that a component.

Boom.

And you start just building,
building your system that way.

and getting those, yeah, straight,
straight through into code as well.

and I think taking the time to build
some of those components and some of

those flows and making sure they are
perfect is also gonna help AI not deviate

and not kind of take the edges off.

What I have seen is, like, someone
designs something awesome, and then they

give it to Claude Design, and Claude
Design just makes it look a bit numpty.

It just, just takes the edge off it a bit,
and just everything's just, like, a little

bit wrong, and you're just like, "Hmm."

Tom: Yeah,

Cassie: Yeah.

Tom: I know what you mean.

just, I just want to add a couple of
comments on the, the tool, the, the

brand, brand-ish tool for exploration.

I found with AI that maybe the, the double
diamond as a process is, is probably dead.

But, there are two pieces of it
that I feel are still very relevant.

One is the, are you in this
expansion exploratory mode?

and there, the tool that Jonny's
referring to was sort of using

that as a starting point.

If like, if I'm trying to generate
a bunch of ideas, how do I…

Like, what are the
things I'm interested in?

What's the sort of starting source
for that, and then how do I just

keep riffing with AI to like push
different directions further and try

different things out and of expand the
possibility space as much as possible?

Then identify like what are the things
that feel like they really work, and sort

of lock those in and feed those back into
some source of truth for this is how we

think about motion, this is how we think
about animation or particle treatments

or what- whatever the, the thing is.

so that's sort of one use
case that's been quite useful.

The other has been almost on the
closing the diamond side of-- And I

did this actually the last few days.

I've been going through my personal
website and tidying, basically spring

cleaning, like tidying up, cleaning up.

Like we're not massively changing the
content or the design, I have been

trying to go through and just like, do I
really need these different text styles?

Can I consolidate them?

Do I need these different font sizes?

Can I, can I sort of simplify
them into a single, a single one?

and I found AI to be very helpful at just
helping me understand the, the sort of

whole landscape of how many different
styles and elements I'm using, and

then reducing that down or helping me.

I actually asked it to make me a tool
that would help me visualize these

different trade-offs and like here's
the existing, set of tokens and, text

sizes and styles that I'm using, and
what are the ones that you recommend

consolidating and where is there sort of
low impact of consolidating those things?

And then preview it on the side and
these different, break points to help

me understand if that was good or bad.

I found that very useful, at the
sort of inverse of exploration.

It's just like simplifying and
consolidating down and sort of trying

to h- of double down on the patterns
that feel like they really work or

the tokens that really, that feel
like they have the most impact.

So my question for y-you around that,
Cassie, is I'm, I'm curious, outside

of the sort of core process of out and
extending a design system, do you have

any tips or tactics for using AI tools
to do the, do the sort of second part

of the diamond, the closing of the
diamond, the reducing, consolidating AI

workflows that help you better clarify
what you already have in your system?

Cassie: It's interesting.

I think, so for me, how
have I been doing that?

Yeah, I think I have found AI
to be incredibly helpful at

navigating and, picking apart the
token architecture that I built.

Probably understands it
better, better than I do now.

I, like, hand-built this thing,
and now the idea of going back in

there to mess with it is terrifying.

but being able to, to go, "Hey, Claude,
this whole system arou- this whole

system around shadows feels clunky.

You know, could, could we tidy this up?

Could we do this a better way?

What would you suggest?

What are some options here?"

and, and kind of like s- focusing in
on, on small details like that, and it

being able to just, like, understand
all of the mapping throughout the

system so that I can make those changes
without breaking everything or, recently

deprecated a bunch of tokens in favor
of moving them into different groupings.

And just having AI to be able
to go, "Sure, we could do this.

This is how it would work.

And also, I've double-checked,
it's not used in any components,

and it's not being, you know, used
anywhere else, so this is not,

like, a massive breaking change.

You're good to go."

so just, yeah, yeah, little,
little things like that.

for me, I feel like that closing in on
the double diamond is … I, I imagine

it as a slightly different thing.

So I've done the, let's have a million
different design ideas out of Claude

Design, and experimented with that.

and what about if you try this?

And what about if we have, you
know, this kind of animation over

here or this kind of gradient here?

And just throwing out, like, a million
different design ideas, and then

that closing in, there's definitely
a word for that that I'm forgetting.

for me, that … converge.

Thank you.

Very soon in Newcastle.

Jonny: Yeah.

Cassie: that's still, like, from that
journey, that perspective, that's

still the human part of it for me.

That is me taking, like, those three
screens and being like, "Okay, there's

something here," and now I'm actually
gonna go in and manually do some stuff.

we still do that, I think, sometimes,
and just perfect it and get it

exactly how I want it in a way
that I can never get Claude to do.

Jonny: Totally.

Totally

Cassie: and that is,

Jonny: I, I think,

Cassie: yeah

Jonny: like is this incredible, like,

creation engine.

If you give it the right context, it
can do-- it can think of ideas that

you wouldn't have thought of just
because it would've taken you too

long to get to the point where you
could even, like create the thing.

but then the…

I mean, I think that this is like
generally the narrative in like

AI and design or AI and anything
is like, it ain't got no taste.

Like you've got to then
go and, and be like,

Cassie: You're right.

Yeah

Jonny: this is utter rubbish, but
there's something in this one, and

I just wanna pull on that thread.

And that is

Cassie: Yeah.

Jonny: That is the human that has
the context and has the skill,

Cassie: Yeah

Jonny: to, to do that.

Cassie: See ya.

Jonny: Cassie, we should move on.

Cassie: Okay

Jonny: before we do, I'll, I'll just
mention that you've, you've got your Hatch

talk, that we will put in the show notes.

We- you've got, You've also written
a long post about the CRD, which I

think I need to read again now because
I've, I wanna think CRD first, in,

in some of the stuff that I'm doing.

Cassie: Mm-hmm.

Jonny: w- really fascinating.

I wanted to just, ask you
about Hatch specifically

Cassie: Mm-hmm.

Jonny: because your talk was great.

you overcame quite, quite a lot of
stuff to even get to the stage that you

can, you can talk about if you want to.

it was your first time on a stage
like that, am I right in saying?

Cassie: Yeah

Jonny: and I think there's a lot
of people that like would like to

do that, and it's scary, and they
don't know how to get started or…

So could you just like take us through
the-- this is a real subject change,

but like through like your decision
to apply and then how you thought

through it and, and like the experience
of being on stage for the first time

in, in that way, on a big stage.

Cassie: Oh my gosh.

Yeah.

I, blame Ben Callahan, who runs the
Redwoods Design System community.

Damian, who runs Hatch, had put out
a call for speakers, specifically

more speakers from Europe, I guess.

And, Ben just tagged me in that and
was like, "You should do a thing."

And I was like, "Sure, I'll apply for
this thing because I will never get it."

and I was working on the, the
CRD stuff, so I, I just recorded.

You have to do, like, a video thing,
and you just recorded a little…

It was originally, like,
what, what the fuck is a CRD?

and sent that off.

I ha- still have not watched
that video 'cause- and I haven't

watched my talk video either 'cause
I can't bring myself to do it.

and then Damian wrote back eventually
to say, "We want you, but we're gonna

workshop the, the talk a little bit to
make it more expansive and more inclusive,

less kind of like focused on this niche
that probably non-design system people

are gonna be less interested in."

I thought I could do it
because I do theater.

So I was like, "I can get up on a
stage and pretend to be someone who's

confident on a stage, and my plan is
to learn this thing like a script.

Got it.

It's gonna be great."

did not get to do that 'cause I spent,
like, the five days before Hatch in

hospital, and I couldn't get out.

basically had to stage, like,
a breakout to get out of there

in time to come to, to Berlin.

So, and I just, like, hobbled
on stage with a walking stick.

I think I was just at that point so
tired that I didn't care anymore,

and that's where my nerves went.

so I probably would not advise
that as everyone's first

Jonny: It's an unusual tactic

Cassie: Yeah, I would not go for that.

If you wanna do a conference and you wanna
get up and talk about your ideas, do it.

It's amazing.

It's a rush, and it's great to share
it and know that the audience are

there to support you, and they are
there to hear what you are saying,

and they wanna learn from you.

And that is incredibly energizing.

and just, like, don't be scared 'cause
you can do it, and then it's over

and you've done it, and it's great.

Jonny: Yeah.

And the reception to your talk, I think,
has just been testament to the quality,

but, but also just like this is such
an interesting topic and so many people

are thinking about this stuff at the
moment and, and how it's evolving.

so hopefully this episode will do
numbers as well because we got you on.

That's what I'm hoping is, you know,
your, your YouTube audience will

follow us, fo- follow you here.

Cassie: Yeah.

No, I,

Jonny: this is just,

Cassie: I mean it

Jonny: is very cynical
getting you on our podcast

Cassie: It can't be the talk
itself 'cause obviously they

haven't seen it when they go.

So it is, the subject
matter is very poignant.

It's just really, I think design
systems are kind of blowing up right

now, which I don't think any of us
design system nerds were expecting.

But it's cool and it, it, it
makes getting that buy-in and that

support within our organizations
that much easier, which is great.

Shame it took AI to get
there, but it's great.

Jonny: There's like more product designers
that would've spent a long time on

like the, the product design, like the,
you know, designing the flows through

a product or solving the problems.

Increasingly are like some of that's
going towards the AI thinking through

it for the simpler stuff, but they're
spending more of their time the AI through

the appropriate way to build it, which
suddenly makes everyone look a little

bit more like a design systems person.

And so maybe, yeah, maybe, maybe the,
the audience, the total pie size has

dramatically gone up, of people that would
consider themselves to be in this world.

anyway, it was, it was great.

And, and, well done because we stood
together before, before you got on

stage, and I know that you told me
this story, I was like, "Oh my God.

what preparation."

So,

Cassie: Yeah.

Jonny: So brilliant work.

Right, I think we should
move on to quick fires.

Tom: you recently shared that you've
managed to get Claude to do your

grocery delivery order online,

Cassie: Yeah

Tom: at least, or at
least draft the order.

Cassie: Yeah

Tom: so trying to consolidate
this into a, a one or two sentence

answer, how can we, how can we do it?

How can we learn from what, what,
what worked, what didn't work?

so maybe the question, maybe the
quick-fire version of this question

is, if anyone out there is looking to
get their groceries delivered they want

Claude's help doing it, what's one or
two things they can try that would help?

Cassie: You need to make a skill,
you need to list in Notion, you

need to give Claude, like, a
couple of months of shopping orders

so it can figure some stuff out

And you need Claude in your
desktop browser, the plugin.

That's it.

Until Ocado bring out an MCP, please.

Tom: So this is

Jonny: So you've got tra-
you've got training data.

you've,

Cassie: yeah.

You need, you need to train it on that.

Yeah.

Otherwise you have to give it
a whole list so it knows like

weekly, biweekly, monthly.

Yeah.

Tom: Thanks for that.

Love it

Cassie: yeah

Jonny: Very smart.

I feel like that could
be a Mediumfire question.

We could ask more questions,
but let's move on.

and yeah, people can ask you,
find you online and ask you more

about shopping, if they need to.

I will ask you one of our
more traditional quickfire

Cassie: Make up.

Jonny: which is when AGI has taken
over and we're all just, you know,

chilling, we all have enough and
abundance and we can do whatever

we want, what will you be doing?

Cassie: Probably traveling.

just, yeah, bumming around somewhere in
a, in a hammock with my laptop creating

systems or something 'cause I can't stop.

but,

Jonny: I feel like with a

Cassie: hmm

Jonny: like, that likes, unraveling
complex problems, lying in a hammock

would get boring quite quickly.

You'd need

Cassie: We're gonna be doing
something in the hammock, like

Jonny: yeah.

Tom: Love it.

I'm, I'm curious about your, your
tech stack, Cassie, and if there

are any-- there's any tools or apps
you've stopped using recently because

AI has enabled you to do that thing
without using the app or product

Cassie: Bye bye Adobe.

That's gone recently.

I don't know whether that was
AI or if it was just time.

no, I d- I, I really expanded to
try out a bunch of AI stuff, and I

have just like narrowed right back
down to Claude, Figma, Wispr, and

Notion are my, like, four top tools.

That's, that's basically it.

Yeah.

Tom: Classic setup.

Cassie: Yeah.

You don't need anything else.

Like, everything else…

Jonny: acronym, that setup.

Cassie: Yeah.

Jonny: Knuf…

the last one?

Knufu.

There's not enough
vowels to make that work.

Okay.

Cassie: Det var.

Jonny: workshop that one.

Cassie: Yeah

Jonny: and the last one from me
is, I suppose it's the flip of, of

Tom's one, but what is one product,
digital or otherwise, that you love

Cassie: Yeah.

I mean, so really I could have…

And it's not very exciting, but
I, I do Claude Code probably.

I spend- Oh, Terminal
obviously is, like, in there.

So Terminal.

We're, we're all just back
on Terminal these days.

It's like being in the '90s again.

It's great.

Jonny: Hell yeah, we're all hackers.

We're all hackers

Cassie: Yeah.

Jonny: Cassie, brilliant.

really fascinating.

there's so much to dig into,
but, we're gonna call it there.

Where do we find you online?

Cassie: LinkedIn probably, Graphicgoose.

Jonny: Okay.

Graphicgoose.

Go and

Cassie: Mm-hmm.

Jonny: Goose.

Cassie: Yeah

Jonny: a, yeah, you, you,
you're in various places as

Graphicgoose, aren't you?

So we'll,

Cassie: Yeah, it will bounce all over

Jonny: you.

and, yeah, fascinated to find
out what happens next with design

systems and with your work, and,
thank you for coming on the podcast

Cassie: Thank you for having me.

It's been, yeah, really
great talking to you guys

Tom: Thank you

Jonny: Bye

Tom: Cassie