Mastering Design Systems with Jeremy Butler
The Laravel Podcast is brought to you by Tighten,
your friendly neighborhood Laravel experts.
Check us out at tighten.com
and also by other sponsors you will hear about later in the episode.
Hey and welcome back to Laravel Podcast season seven.
I'm your host, Matt Stauffer, CEO of Tighten, and this season I'm joined every episode by a
member of the Laravel team.
Today I'm joined by my friend Jeremy Butler, design lead at Laravel.
Jeremy, can you say hi and share a little bit about what you do at Laravel?
Hi everyone.
So my name is Jeremy Butler.
I'm the product design lead at Laravel and I take care of a lot of the evolving design
systems and kind of the design direction for cloud, Nightwatch and Forge, and a little bit
around, you know, the Laravel brand as well.
Okay.
And I have so many questions, in part because I've actually seen your fingerprints on
quite a bit of open source things.
So I'm curious like where that goes.
But before we do that, you know, the first question we have to ask is what is the story of
you coming to work at Laravel?
So what you know, go as far back as you want or keep it as short, but I I want a story
that ends up in you've signed a contract and you're working there on your first day.
Okay, so we have to go back maybe eight or nine years.
Okay.
Because that's where really where the story begins.
So I've worked with Philip Harton, who's our senior PM here at Laravel, almost for 10
years.
And the first project that we were working on together was distressed media.
So selling adverts to pretty big companies for print, for like outdoor advertisement.
And we decided to build it in the system that we knew, which was WordPress.
And WordPress came out in 4.7 with an API.
And we thought, okay, this is gonna be it.
This is how we build our first application together, but immediately started hitting
problems.
We had performance problems, authentication problems, just all sorts of issues all the way
down, full downstream effect.
And Phil went away and he bought a book called Laravel Up and Running, which of course is
your book.
So all of this is comes back to you.
Yeah.
It is your fault.
He read it in a weekend and rewrote the full this was a national application.
He rewrote it in two weeks in Laravel.
Must have been five point something back then.
And that's really what we got into Laravel as a framework, as like a ethos of how to build
software, how to build clean software, predictable software.
And we built the next probably ten applications in Laravel until we moved into a medical
application.
And from there we grew.
The system and the the business itself grew into the NHS and the UK.
And we had to build the best Laravel application possible with the best app book, the best
Laravel team possible.
So that's where we reached out to people in Australia, like Jess and Tim and James
Carpenter and Sabrina.
And we built a team really for this medical software that was world class.
It really was.
And
Things happened there and Jess and Tim, of course, moved into Laravel itself and started
building, you know, open source systems and started to build this new application.
By that time, Phil and I had started another business again to running those channels.
That's what does we have to.
I think we've we've had five companies over 10, almost 10 years together.
So Jess reached out and said, Hey, look, we're doing something pretty special here and
we're actually gonna get the
You know, the freedom and the the funding to go chase this idea.
Do you want to come do some design?
I was like, of course.
Like we're kept it all and kept in touch.
And it's like, this is going to be great.
That turned into to Nightwatch.
And it grew to the point where we needed Phil as well.
So we got the offer to kind of, do you want to both move over and just go full time at
this new application called Nightwatch?
So really that's the that's the genesis.
is coming from having to rebuild this system into Larva all thanks to your book.
That's
Wild.
And you guys have told me that that there was it played a role, but I didn't realize it
had played that much of a role.
It was such a pivot, like it we're heading down towards you know, doom and gloom with this
application.
And yeah, just that methodology and that change in framework saved the project.
So long delay.
Thank you.
What yeah, of course.
I'm so delighted to play a part of it.
What a fun story.
Before we kind of move on with the rest of the rest of the podcast, I want to hear the
story of what you got you into kind of what you do on a day to day.
Because I know you have design chops, I know you have programming chops.
So where like where in that world did you start?
Where in that world would you place yourself today?
And we don't need to talk about the projects you're working on, but just sort of like your
evolution from like how do you imagine you what your work was gonna be, you know, how that
evolved over time.
I think most designers back in in my day kind of started in print.
It was the the most viable area to to be a designer.
I struggled.
So I was freelancing at the time, but there was all these web offers.
So I said, okay, I can design a website.
Let's do that.
And I really, really struggled to find good developers to work with.
So foolishly enough, I said I I could probably do this and started to learn.
Yeah, yeah.
It's just like
HTML looks easy and it, you know, it was until you get into all the rest of what you have
to build to to make a successful website.
Um, so my life's really just been to and fro between design and front end.
Uh I I would have thought I was okay as a full stack, but now that I'm working with people
like Jess and Tim and the rest of the Laravel teams, like I can't.
None of us feel like we know what we're doing compared to them.
Yeah, yeah.
That's the most humbling kind of movement and situation you can do is go into a an
engineering team where there's like those sorts of people and those builds in the the
community.
It's like, okay, I'll not touch that anymore.
Yeah.
Totally.
So yeah, I've kind of gone deep into design and kind of deep into design ops and design
theory and just trying to make sure that design has a voice in Laravel and within
engineering teams.
It's like this is, I guess, a way to solve problems.
A way to see solutions and kind of all get people together around a single artifact, which
is usually a design, and a user journey and a few kind of things that go user centric.
And yeah, that's really my day to day right now, is how do we make that voice a little bit
louder and a little bit more present in the product that we're the multiple products that
we're building.
Okay.
And you when I'll go in there for a sec in a second, but first we will say thank you to
our first sponsor real quick and we'll be right back.
Move fast and fix things with Honey Badger's intelligent error tracking and application
monitoring for Laravel.
This is everything you need to keep production healthy and users happy.
Get your free developer account today at honeybadger.io.
And Laravel, the mothership and also employer of our guest today.
This episode is also sponsored by both Laravel Cloud and Laracon US.
Laravel Cloud is the fastest way to deploy Laravel apps, and it also solves all sorts of
common problems that keep web artisans from shipping.
And Laracon US is the premier in-person event for all web artisans to come be with your
people, level up, and leave ready to ship faster and better than ever.
So check these out at cloud.laravel.com and Laracon.us.
So I do want to get to where you are today.
I'm really fascinated by
The ways you talk about design as a interpersonal thing, as a systemic and cultural thing
versus just a practice that one person does.
But before you do that, I want to talk about when you first worked at Larabelle, what you
were working on.
So you had mentioned that they said, Hey, we're gonna do this new thing, we're gonna get
the freedom to work on it.
So, what was your introduction to that first project?
What did you first kind of get exposed to and what was the pitch?
It started with an apology.
So I remember the first the first call I had with Jess was sorry for what I'm going to
show you, but like let me tell you about what's underneath it.
Okay.
And it was that was probably justified.
The first screens were just like, here's what we can pump out on a white screen.
Um with, you know, dark text and a HTML table.
But like the underlying core of what Nightwatch was, like the the engine behind it, was
pretty exciting.
It was pretty compelling when that plugged into
You know, the grander vision for for cloud and for Laravel itself.
It's like, okay, we're creating a suite of products and we're creating like a holistic
solution for developers.
So we started working on designs and the the freedom that we had was really just a brief
from Taylor saying, you know, dark and hacky.
Uh just as like a starting point.
Couldn't can be this kind of feeling, this kind of vibe for for Nightwatch.
And we ran with it.
And it's just like
We started designing screens like really quickly and implementing that as as fast as I
could design them.
They're kind of being implemented at the same time.
So that first six months of of Nightwatch, which was like July 2024, I think.
Okay.
until the release.
but yeah, that really just came together quickly.
It was obviously because we'd worked together for a number of years before, it was very
familiar.
Like
We we knew the team, we knew our strengths, we knew our weaknesses.
We just kind of clicked and really ran with it.
So Yeah.
Yeah.
And so those first days you didn't have PM, right?
So you were just been told, here's a whole bunch of data tables, here's dark and hacky.
Who was actually defining, you know, the user journeys in the UX and you know uh because I
assume you weren't just doing UI at this point, right?
You're probably doing broader stuff.
So like who was defining what and where did you fit into that kind of workflow?
So s Phil and I were still running the studio.
So I got to lean on him a lot, even though he wasn't officially on the project.
Got it.
And yeah, a lot of it was kind of pre-thought by Jess and Tim of just like what this
should be.
And of course, Taylor as well.
And yeah, we we really just found the strengths in that and tried to magnify it.
It's just like, okay, how do we kind of cut down a lot of the the noise in the system?
Because observability
is that is trying to like find a signal in a whole bunch of noise.
So yeah, a lot of it was kind of pre thought, pre chewed, and that made it really easy to
kind of go that next stage and that next level with it straight away.
Yeah.
Okay.
That makes sense.
I want to talk about your kind of process as a designer and then we'll move on to like
what you did then versus what you're working on now.
Do you have a tool that you love to use more than anybody else?
Do you have any processes as a designer that you think are any different than, you know,
that that that are unique to you or kind of like what's your workflow when you go from
I've been told dark and hacky by the boss and I've some developers have given me some some
HTML tables through to the final design?
Yep.
There's really a few different methodologies that I kind of like to approach.
And this is only after like years and years of maturing what is product and what is
design.
Yeah.
so there's there's design thinking itself.
So we kind of look at macro, micro uh lenses over the product is like overall, what's the
user experience, what's the u user journey versus what's a button next to an input?
Like that's kind of
Super, super granular.
But yeah, with the design thinking, you go through the like the viability of it.
And this is what we do as the the product team.
So can we make money off it?
You know, is it cheap to run?
Are we able to make the books, you know, balance by creating this product or creating this
feature?
There's the desirability, which is what we in design probably work the most in.
It's just like, can we make this compelling?
Can we make this valuable to a user that they're happy to spend?
X amount of dollars on it.
And then like feasibility.
And that's where we work with engineering.
It's like, okay, we've got this big grand scheme of ideas and and kind of direction to
take.
Can you do it?
What do we need to change on our side?
So it makes it easier on your side.
And yeah, I think that's a lot of the work that we do on the product team.
And then yeah, there's all the human-centric kind of approaches as well.
It's just like, how do we build?
solutions that have empathy kind of baked in.
So the the newest user is comfortable moving through a system like cloud versus the most
experienced, you know, DevOps can move through the system.
Maybe at a different plane, at a different level, but like they both get the same outcome.
And that's kind of what we're trying to do a lot of the way through.
So
Okay, so what informed you?
Because again, like I said, like there's many designers who are very excellent and
talented div designers who would have just talked my ear off about Figma, who would have
talked about design systems, who would have talked about, you know, and you, you know,
within your first hundred words were like empathy and user journeys and all that kind of
stuff.
So what informs that being the way you think about design versus, you know, practical
implementation details and gradient maps and stuff like that.
You know, like what's what what's the source of that?
Probably a lot of failures and a lot of mistakes along the way until the point of just
like I think so I approached like systems thinking as a way for me to fix a lot of my kind
of flaws in design.
It's like, how do I fix something bigger than just the screen that I'm looking at?
And how do I think about the user when I'm sitting here trying to create a solution?
So I kind of I was drawn to systems thinking and like, okay, how do I
take ten steps back and and think about the whole picture.
And instead of thinking of things in parts, I think about it as a whole product.
How does everything work together?
Yeah, I kind of dove deep into that and deep into a few different approaches of just how
to think about problems themselves.
And they're not magic and they're not perfect.
Like these tools are there just to guide you.
And any guide is to try and get you to some endpoint, but you will trip and fail along the
way.
But it it's better to have guide rails, I think in
Mm-hmm.
The way that we approach software.
Um, so we can bounce back quickly.
So I still I mean, I love to get into data as well.
So
Yeah, talking about that seems like that might be a natural transition because a lot of
people whose whose work in their particular career is really targeted on on individual
contribution.
That is is most common when the whole thing is about what I am building and what I'm
delivering.
But everything you just said sounds like something that makes a transition to leadership
more natural.
But I don't want to project that on you.
Did you find that that was something that happened before you stepped into leadership?
Or is it something happened after or did they happen together?
Because obviously, like your journey at at Laravel has been one, but you were already
leading, you know, agency work for years prior to that.
So like where where what was the timeline of the two?
Growing as an agency leader, growing as a leader in design spaces, starting to look at
design is less just kind of like pixels on paper and also systems and people and all kind
stuff.
I think it kind of happened at the medical company.
So I was head of design there, and Phil was like head of engineering.
And we had to pretty much pitch, we're pitching to fairly large medical companies, as well
as like the NHS.
And we you can't pitch a product based on how it looks and you know how you interact with
it.
You have to pitch it on the underlying currents of what you're trying to solve.
So we were kind of drawn to all of that and trained as well.
In how to think about the the bigger problem and the bigger solution.
So we could actually have those conversations with fairly large bodies.
So that kind of came naturally then to the agency when we're talking to clients who are
either being burnt by another software company or burnt by the industry itself and would
come in and try and say, Hey, let's change the lens on this.
Like let's think about it from a different angle.
The solution is good, but the execution might be wrong, or the execution is good, but the
timing was wrong.
And we try and piece it all back together.
And again, you can't do that just with pixels on a screen.
They've seen that they've kind of they can appreciate good design, but what they're
looking for is vision and direction.
And those kind of conversations have far deeper kind of contextual meaning when you when
you want to chat with people.
Like you have to go deep.
Okay.
That makes a ton of sense.
So talking about your journey, let's talk a little bit about your journey from joining
Laravel initially to work on Nightwatch through to where you are today.
Kind of what what steps have you taken?
What roles have you had and where have you landed now?
Yeah, so when we started Nightwatch, that was awe consuming and I was, you know, back into
the front end and I was I was as happy as could be like mostly breaking things, but like
building screens and like this is exactly how that animation should be.
I'm gonna spend a day executing that because that's
Are you working in like Framer and React at this point, or are you purely working the
design side right now?
At that point?
was that was all Figma and React.
So we'd done a little bit of React before.
I think almost everyone in View was like previously oh sorry, everyone in Larva was
previously in View.
Yes.
so got to kind of skill up in in React at the same time.
Then we got to a point where like Nightwatch was up and running.
And I was saying, like, okay, now what?
I can work on some new features, but you know, the dev side of things, um, that's gonna
continue on its direction as well.
And I started working on the the new Laravel website and a lot of the branding work.
It's just like, okay, while I'm here, I'm gonna do something that I think is kind of
personally hits where the the framework is evolving to and where kind of AI and you know
agents are kind of leading us towards.
So I built the the latest Laravel.com website.
Um and then really from there it was okay, how do we
use some of that approach and some of that thinking into cloud as well.
and that's kind of where it's only I guess in the last few months I've started working
more deeply in cloud and more kind of deeply across our three products.
Yeah.
Where did cause I like I said, I I saw you do some work in open source.
I know you worked on the like the era page and some other things.
How deep were you involved in any open source work?
Was that just a few little touches?
Yeah, I think we really wanted to do a lot of I guess some of the local experience of
Laraville.
so when you're developing on your machine, how do we make that better?
I mean, we've designed a few concepts that sitting in Figma, but we also got like the
exception page.
It's just like, how do we make that something that's useful?
Uh, some of the great Twitter comments back is just like I'm purposely making it fail so I
can see this page again.
It's like, okay, that's pretty good.
I'll I'll take that.
Love that.
Working on a few things with the open source team, but they're kind of in development at
the moment.
Okay.
So we'll hear about them months down the road and we'll be like, Jeremy, I see what you're
doing.
I see what you were not telling us about in the podcast.
Love that.
Very cool.
Okay.
So at what point was your role officially because I assume that you weren't product design
lead when you first joined.
So when did that transition happen?
Or tell me if I'm wrong, and that's actually was your role on day one?
I think it was kind of towards the end of last year it started to evolve.
And then I guess over the last four months it's been officially like let's really go hard
on this.
So Okay.
All right, that makes sense.
And that's our natural transitions.
We'll pause to thank our next set of sponsors.
Laracon AU returns November 4th to 6th in Brisbane with deeper learning, practical
insights, and ideas that will stretch how you think about building with Laravel.
Get your tickets now at Laracon.au and come hang out with me and Jeremy, because we're
both going to be there.
Okay, so we have kind of caught up to today.
We're at the point where you are the product design lead across those different three
different products.
One of the things I want to ask is
how much of your job is design, like on the ground?
How much of your job is managing people?
And how much of your job is leading kind of design efforts across the products?
So, you know, I'm I'm I guess those are like kind of three spaces.
One of those like individual contributor work, one of those managing people, and one of
them is like leading individual contributor work from a design perspective, but more
leaderly.
Like where are you?
How much are you doing of each of those?
So my kind of scope is really within the design direction.
And so I'm working like deeply in the the design systems.
Just like, how do we make sure it's something that can scale?
And by that I mean like it's quick to make designs, it's quick to make evolutionary
changes to our systems.
The people management side.
So I kind of share this role with Jason Beggs as well.
Okay.
So he takes care of people management.
And takes care of a lot of the UX quality of like the execution that users get to see.
Yeah.
And kind of between the the two of us, we share a vision of like how do we move forward as
Laravel with design attached to everything that we do.
Yeah.
So that's that's really interesting.
And I guess we've got now a dedicated product team, um, which is led by Joe Dixon.
And
That's the first time I think within Laravel, products always been there, design's always
been there, but it's never been like a pillar and a discipline that stands outside of
engineering.
So now that we've got that, like it's a extremely strong voice and it's kind of a product
led evolution and solution company, which is really, really great, especially for the
design team to kind of have this place to explore and have our freedom of our own
processes, our own disciplines.
So yeah.
And that's very fun.
I think I talked to Jason on the podcast right before he was moving to the design team.
It's an untraditional arrangement having, you know, you and Jason kind of co leading
there, but it also if for anybody who knows the two of you, it's also brilliant.
Who set that up?
Was that a Joe thing?
I I think so, yeah.
So between Joe and leadership is just like how do we have the best of all worlds together?
Love that.
That's so good.
Okay.
So what does your day to day look like right now?
Obviously, you are working on these broader systems, but also you also have to deliver on
deadlines for products and stuff.
How much thinking are you doing?
Do you sit in Figma at all still?
Like what are you actually doing every day?
So I I guess I'm still like an individual contributor.
Um kind of are still either pushing code or pushing pixels.
And so I've got like my own kind of projects or my own kind of tasks that everyone else
has.
Um I think about half and half is like I get to step out for half of it.
Okay.
Look, something's not right here.
It's this system's or this kind of loop is making a bit of noise.
Can I step out for a day and like fix that for everyone?
And then jump back in.
Um so yeah, I get a really good mix of high level thinking.
And then I mean, I still love it day to day, just moving pixels around a screen until it
looks right.
So Yes.
It's good.
And that's what I imagine.
You know, you strike me as someone who loves the big thinking and also loves getting your
fingers dirty, which you you you mentioned.
You're like, you're, hey, when I got back and night watched it, I was able to just do the
thing.
Um, and as someone who's kind of gone through that in my own journey, I I I definitely
recognize that leadership without the opportunity to practice sometimes you miss out on,
like you said, those little frictions of like, wait a minute, this system's not working
quite right.
So that's that's really fun.
Um I know that.
Usually when I talk to people who are involved in anything product at Larival, the answer
of what you're working on right now is uh you'll see in a couple of months, is there
anything you're working on right now that you can tell us about?
There is kind of a lot more that we're doing around the metrics in cloud and how we
present that and some of the the learnings that we've got through Nightwatch.
So that'll start to evolve and and take place.
The latest bit of work was kind of around the managed queues.
Um keep watching what's happening there.
every kind of system is now evolving and kind of meeting a a bar.
so everything is moving at the same time.
There's a lot that might be shown out.
uh
you four weeks before Laracon, you're gonna not be able to tell me much.
Yeah.
Yeah.
Okay.
So obviously quite a bit of the future for you is tied up in the things we just talked
about.
But as you look six, twelve months out in your role at at the company and in the community
and the organization, how do you feel about like what are you excited about?
What are you looking forward to?
What the changes at at Laravel?
What are the changes in the ecosystem and in the environment that you're like, this is
something that's you know got my energy and my attention.
So I think I was deeply captivated around AI and kind of agents in the system and how we
represent them.
So that's evolving, I guess, even like what Taylor did with just the the Laravel SDK.
It's like that is now a first class citizen of the framework.
Um so it's how do we support that and how do we encourage and grow that to the point where
newcomers choose Laravel because it is the most viable solution for
AI engineering effectively.
So yeah, over the next few months, I'm sure that's going to keep evolving and growing,
both in Laravel and in, you know, AI, the marketplace itself.
So yeah, we'll keep thinking and we'll keep kind of making sure that we're the the best
option and the best choice for for the rest of
That makes sense.
I mean, you mentioned kind of like working on the layer of a landing page and thinking
about marketing and branding.
How much of your, you know, whether or not you're actually doing it in a day to day, if
you had your choice, how much of your job would be communication and marketing, and how
much would it be user experience and user interface?
Again, like to split that in half.
Okay.
The the two play together so well.
So I guess one of the initiatives that we've got within the product team is like how do we
stop the seesaw of like products ahead of marketing and the the communication?
And then it can get ahead of the products because you know, we want to talk about new
things and we want to kind of reassure people that we've got a direction and a vision for
where we're taking both cloud and and Laravel.
So yeah, it's kind of making sure that those two things happen together and it's like
this.
coexistence that feels natural.
So yeah, I I really like playing in both spaces and kind of I guess communicating what
we're doing in a really clear way.
Okay.
Well that makes sense.
And it makes sense that you're doing it for people and then you want people to know about
what you're doing and you want other people to know that they should want to know what
you're big doing.
It's all kind of a big part of part of the whole thing.
Okay.
So I'm about to wrap on our time talking about you at Laravel.
But before I ask you questions about a few completely unrelated things, is there anything
else about your job at Laravel, your journey to come here, or anything else like that you
wanted to make sure we got a chance to talk about?
Only that if you can come to Laracon US in Boston, but also AU.
We've got a a magic spot in Brisbane and we love international guests.
We love national like we love Australian guests as well.
But there's something special when someone's traveled so far.
Cause I think the flight, my flight to Boston is like twenty something hours.
So it's a decision that you have to make.
And yeah, when we get people coming to Brisbane, it's something special.
They've they've traveled a long way.
It's
Special for so many reasons.
It's special because the Australian Larville community is the most welcoming Larville
community I ever visited, and that says a lot.
It's special because the conference itself is designed very intentionally to be a space
where people can feel welcome and get to know each other and learn and whatever.
It's special because Brisbane's gorgeous.
Like Imani and I visited Brisbane and we're like, are we going home or are we just staying
here?
And I'm I'm sure it's gonna happen again this year because
Yeah, it's worth that crazy trip because my gosh.
So thank you for mentioning that because it's it's an incredible conference.
of course Michael Durand does one of my favorite human beings in the entire world.
So that didn't doesn't hurt either.
So yeah, hundred percent with you.
Definitely come to both.
Okay.
So I've got, you know, one of the things I do ahead of everybody's interviews is I kind of
like look up, you know, is there so there's times where I'm really active in social media
and times where I just completely disappear.
And so I'm just like, you know, I know these people, but I might have missed entire
periods of their lives.
So I've got your Twitter profile up and I've got useMods.com and useClassy.com.
And I need you to talk about at least classy because I haven't heard people talking about
classy and it's beautiful.
And I so please tell the people what is it, what does it do, and what kind of brought
about your interest in it.
So useClassy allows you to write multiple class lines and it will collapse them all and
make it a so when v kind of compiles, it'll make it a single class.
So you can kind of separate your your media utility.
So you can have a separate line for all your
I guess your your smalls and your larges and your dark themes, all on separate lines.
So you can classify it and sort it separately to each other.
And yeah, it kind of came about just because in my IDE it was one big long line and I had
to horizontally scroll so far just to make sense of anything.
Yeah.
And then we we got into the the hacky pattern of like in React, you can separate that on d
in it within an object.
Right.
You can separate it.
And that felt a bit funny to me because I couldn't do the same in my Blade template and I
couldn't do the same in my view template.
so yeah, I just sat there when I should have been on holidays, I think, a few nights and
just went, okay, I'm gonna learn a little bit about VET, because I hadn't played like
deeply within it.
And yeah, came out with after a weekend with a little plugin, a little VT plugin that does
it all for you.
it so much.
I love it so much.
I don't really use Vue and React very much because if the CEO of the company is
programming, it's a hacky side project.
It's not client work, right?
So I'm always doing Blade or LiveWire, something that just allows me to get the thing out
quickly.
So my team uses Vue and React every day, and I don't get to.
And I'm like, uh, but I want to use this because it's and for those, you know, like first
of all, just U S E C L A S S Y dot com, useClassy dot com.
Check it out.
It's a lot easier to see it than for us to tell you.
But I will just say like the simplest thing is if I were in view and I would say class
equals P six, and then as a new property, I would say class colon hover equals P dash
eight.
That's it.
And it's so much, especially the example on the website is so, so, so good to start seeing
like, yeah, if you have the same hover or large or group hover, whatever, apply especially
with the more complicated ones where it's braces and ampersands, whatever, and they're
being applied to multiples, it's so much clearer to group them like this.
And this is a really fun way of seeing that this is not just pixel push pushing, right?
This is this is thinking about people, humans' interactions with the code they're doing
and thinking about affordances and it can be so anyway.
Freaking love this.
Thank you for building this.
I've never used it.
I hope I get the chance to actually write a few React projects one day again.
So very, very cool.
Are there any other side projects you had that you want to share?
I know you have, you know, the use mods.
But do you want to talk about that?
Are there any other side projects that are kind of on your mind or something you haven't
published yet or something you're tinking around with that you want to talk about?
There is one.
So DSLinter.com.
It's very much in an alpha stage, but it is working.
And it's to lint your code base for design systems.
So it'll tell you everywhere that you've incorrectly used the design system or you've
injected your own hex values that break tokens.
And it will give you accessibility scores and maintain not maintainability scores and all
sorts of things over effectively your design system and your tokens.
So let's talk design systems and tokens.
If I were to build a brand new project tomorrow and Jeremy Butler was the design leader of
my project, what things would you say, this is a organizational tool, you should use
storybook, you should use this, that, or the other.
What would you be like?
Everybody should be using this when they're building a design forward, you know, user
centric layer well application.
Yeah.
So governance is a big thing around design systems.
And it's like how do you manage and maintain it long term?
Because the the natural thing for any defined system is to bend and break and bubble out.
It's so you how do you bring it back in?
And how do you accept that things do progress faster than what the the rules and the
tokens can accomplish?
Uh so that's what this system kind of does.
It gives you that holistic score and understanding of what's happening.
I
Haven't kind of fully completed it yet, but it can replace parts of storybook if you've
written it within TypeScript.
I can pull out the types and I can say, I know what a button is and I know all the props
for a button.
Here's a preview of the button.
It does get more complex the more depth I guess those components go into.
And then the basic rule for for me for design systems is how to keep it as primitive as
possible.
As soon as it becomes business logic, you move it into the actual design itself.
It doesn't belong in the design system.
The design system is there to establish like the baseline.
What is this product?
What is the experience of this product?
And yeah, trying to keep it as maintainable and as small as possible.
I love that.
This is the stupidest thing I'm gonna say all day.
I'm sitting on DSLinter.com as you're talking, and up at the top, the logo allows you to
hover over something and it shows the the little marching ants for anything you're
hovering.
So first of all, I'm just having a great time with that.
But second of all, I keep making the little circle and I keep finding where the circle of
my my magnifying glass or whatever cursor overlaps with the circles that you've built in
there.
And it's just so pleasing.
And I'm like, You're such a freaking designer.
Like of of course.
Of course it perfectly slots in here in the way that is itching the my brain in a certain
way.
So this is so fun.
that's really, really cool.
if somebody heard you say everything you've said for the last five minutes and they're
like, Jeremy, what's a design system?
I can't ask you to teach us all about that in the next five minutes.
What would be a good place for somebody to go look if that's a thing they're interested in
learning more about?
So there's there's a lot of good design systems to to work from.
You've got Ratex and you've got Shad C and you've got all these kind of component
libraries.
The design system itself is what's lying underneath.
So the first place I'd probably send people to uh is let me find the website so I get it
right, is lawsofux.com.
Okay.
Because you can create great components, but you need to understand like the
fundamentals and the principles behind, I guess, good design and good usability before you
get into pure just pixels and presentation.
And I think this is the same lesson for people designing with AI as well.
It's just like you can absolutely design great systems and you know great UIs with AI.
But in the same way that you need to know the fundamentals of development and engineering,
you need to know the
fundamentals of good design as well.
And that'll help you further than I guess any great prompt or skill that you can import is
just like uh establishing a good sense of taste and a good sense of what's right and
wrong.
And yeah, there's great checklists out there for design systems as well.
Go find them.
Um they'll give you a dot point of what makes a good button and what you need to remember
about making a good button.
Looks like Laws of UX has the website, but it also has a book and a poster.
Uh have you heard anything about this book?
Is it worth considering if someone wants to dive deeper?
Or are you like, let's just start with the website and go from there?
So they do have a book with O'Reilly on Amazon as well.
And I desperately want to get some of the posters around my office.
Um, but it is a kind of a reflection of the website.
So the website's the best place to to start understanding and learning.
Amazing.
I love when I learn things on this podcast.
This is wonderful.
Yep.
Thank you for that.
Okay.
Okay.
Since we're coming up to time, I did ask you if there's anything else you want to talk
about with your Laravel journey.
Was there anything else other that's going on in the world that you just wanted a moment
to talk about?
I know that you'd mentioned AI a little bit.
Is there anything in your brain that you're like, you know what?
I have a platform, I've got a microphone, you must listen to me, or are you feeling like
you got everything out?
Definitely around my journey, I think I've got everything out.
I'd only kind of say like be curious and kind of learn some more frameworks that sit
outside your day-to-day work.
Um, that's really kind of accelerated my problem solving abilities with like system
syncing and just like keeping laws of UX there.
And the other tab I've got is untools.co.
Which again is just frameworks for uh I I guess breaking through problems.
If you've got a barrier in front of you, there's usually some guide rails to help you push
through it.
And it's much better than sitting in a room trying to think through it yourself.
So yeah, they're not magic.
They're not intended to be an absolute guarantee to to solve a problem.
But you'll progress two or three steps forward, and that's usually enough to unlock enough
to.
Create a solution.
So
That's great.
you say the name of that domain again?
Untools.co.
Okay.
Tools for better thinking.
my gosh.
I have so much learn to learn.
I mean, the third tool here is the Eisenhower matrix, which is the urgent versus
important.
And I reference it at least once a week in business settings.
So I'm like, yep, I clearly love this.
So wow.
Just learning the whole time.
Jeremy Butler, you're great.
Glad I can help.
so if other people are like me just aghast with how much they're learning in this podcast
episode, how do they keep up with you?
Um I'm on Twitter and I need to be more active on Twitter.
Um so it's my handle's horrible.
So apologies, but it's J R M Y B T L R.
So I've just taken I've taken all the vowels out.
So
funny because I often have ways that I silly silly pronounce people's Twitter handles and
with yours I'm just it's it's always just Jimbutl Jalimbutol I'm like tumblers, you know
there's always something in there.
So yes.
Well as always we'll make sure we link that in the show notes.
We'll link all your sites and everything like that um to make sure it's all in the show
notes.
So my friend, it was so good to spend time with you.
It was so good to learn from you once again.
And thank you for your time, especially because I know the you know, you woke up early in
the morning to to record with me and I appreciate that a lot.
No, thank you so much.
All right, for the rest of you, thank you for hanging out.
We'll see you all next time.
Creators and Guests
