Luis Ouriach - How are design systems changing?

Basically overnight, LLMs may design systems way more important.

So how should we think about what a system even is in today's world?

By now the system becomes the centerpiece of all successful engineering work.

The more we rely on a tool to create our code,

the more we rely on a system to tell that tool what to code.

How is this changing the shape of design orders

in the way that we collaborate as a team?

That starting from anywhere philosophy is the new way of working.

You might start in a document, you might start in a canvas,

you might start in a front end, you might start in any of those places.

But ultimately you're going to be bouncing through the tools.

Welcome to dive club. My name is Red and this is where designers never stop learning.

Today's episode is with Louis Aureche,

whose role as a designer advocate at Figma

means that he's constantly helping teams navigate today's changing landscape.

Especially when it comes to design systems.

So we're going to do a little deep dive into all the trends that he's noticing today

and what it all means for designers.

But first, I asked Louis to give us a rundown of everything that's changed

in the world of design systems since he was last on the show.

The last two and a half, three years since we spoke about Figma's variables launched.

Everything's on the table and everything has changed.

But you still have threads at the same.

So I would say that there was a over indexing on the importance of tokens

getting that right, refactoring systems that took an enormous amount of time.

Some companies took a year, two years to get to that point of refactoring.

Once that felt stable, the industry threw us a curveball

and introduced artificial intelligence, LLM-based code generation

where people started to rethink what systems actually were and what their purpose was.

At least those at the forefront.

And that made me a bit scared.

I think it made a lot of people a bit scared about what that meant for their roles

and what their daily output would like, be like.

Then let's say that was a year ago, plus now we're in a position where

there's a little bit more stable in what that workflow looks like.

And we started to see probably thankfully the importance of documentation

in consistent and predictable output.

So I'd say there's been swings back and forth between everything being important,

nothing being important, and now we're landing at a position where

all those things you have been doing are exceptionally important

for the new workflows that we're trying to establish.

Yeah, I'm smiling because I've also had my own little vantage point,

just interviewing people.

I've interviewed 200 people since we last talked,

something in the ballpark of that.

And there was definitely this sentiment around how design systems are dead,

yada, yada, yada, and everything's about speed.

Design systems just get in the way.

And the pendulum has swung to the complete opposite end where everyone's

doubling down on design systems because it's so clearly a driver of speed

and all the documentation they wrote is actually really valuable,

just not for people anymore.

Yeah, I would say to be totally honest, January 2025,

I thought we're all toasted.

We need a couple here because our jobs are no longer relevant.

And that was just thankfully a temporary feeling,

well, a couple of months.

And like you said, the importance of those docs,

whatever format they were in before,

is going to be the foundation of everyone's workflow going forward.

You might just be written slightly differently

and for a different format, for a different output.

But guidelines are becoming paramount for everything we need to do.

Yeah, maybe we can just go a little bit deeper there.

You said the purpose of systems has kind of shifted as a result of AI.

What's behind that?

A lot of people looked at systems as a team,

kind of potentially in the corner,

doing their thing, raising the bar of quality,

and making sure that businesses can scale efficiently and at speed.

But now the system becomes the centerpiece of all successful engineering work

because the more we rely on a tool to create our code,

the more we rely on a system to tell that tool what to code.

And the less we invest in a system,

the more we're going to generate just honestly rubbish

into our systems that will just pile up like a landfill

over the next couple of years,

and somebody's going to have to fix it.

So unless we now treat those systems as a centerpiece for change,

then we're going to end up in that situation a few years

where a consultant's going to have to come in and fix all the mess.

You recently published an article called a genetic design systems.

Can you talk a little bit about your thinking there?

This isn't a new phrase at all,

but people want to automate a lot of things,

and we're in a process now figuring out what can be automated,

what should be automated.

And I speak to teams who do want to automate the generation of their components,

and speak to teams who absolutely do not want to do that,

and want to automate some other aspects of it.

It might be token pipelines,

it might be some aspects of documentation,

but we're moving to a world where a lot of this work can be done via tool,

or an LLM, whatever frame that you want to put on it.

And we have to decide as an individual, as a company,

or even as a team within a company,

what are our roles actually now,

and what are the tools taking over,

and decide that as soon as we possibly can before that decision is made for us.

Real quick message, and then we can jump back into it.

An even smarter version of Lovable just released.

This 71% better at solving complex tasks,

which means it can do more work more autonomously.

There's more intelligent planning,

prompt queueings, you can stack requests while Lovable works,

and my favorite part, there's automated testing,

which means Lovable now tests your apps like a real user.

It opens its own browser, navigates flows,

investigates edge cases, and catches bugs for you.

And the best part is when it finds a problem, it fixes it right on the spot.

My genuinely believe Lovable is the easiest way to build software today,

so head to dive.club slash Lovable to try the new release.

You know what I'm excited about?

The Granola MCP.

It allows you to connect your AI tools directly to your Granola meeting notes.

And as somebody who's been vibe-coding a lot of tools recently,

this releases a pretty big deal,

because my meeting notes are some of the most valuable contexts that I have,

and not I can find specific topics,

pull out action items, and get any question answered based on my meeting history.

This is all available today, and I'm already building with it like crazy,

so if you want to join me head to dive.club slash Granola MCP,

that's Granola hyphen MCP.

Now onto the episode.

I want to tap into your perspective as somebody who does work with a lot of these teams,

given your position, and you see a lot, you see what's working,

you see pitfalls to avoid.

What are some of the most innovative techniques or processes that you're seeing teams

adopt as a result of everything that's changing with AI?

What I'm seeing is a lot of people feeling empowered,

and that could be on one side, a technically curious designer.

On the other side, it could be a design curious engineer.

Well maybe in the other angle of this triangle is a product manager that doesn't feel like

they can ship, and all of these people are feeling like within reach,

they can get closer to production, or maybe just a higher fidelity.

I'm very nervous about saying everything can be production now,

because maybe that's not the point, maybe we can get a higher fidelity prototypes

that we can test and validate a lot faster, and still throw them away,

because that is the point of prototype a lot of the time,

is to just test an idea.

But what is stopping anybody in this process from contributing to that?

And I see this internally, if Igmo or externally with other teams,

where people are for one to the better phrase, bleeding into another person's

job description.

And I think that is great, because we are teams.

And historically, whether we like it or not, people have worked in their own silos.

And you pass a engineer a file to build, or a product manager passes your PRD to investigate.

The question is why are we all contributing to all these phases with expertise?

It's not saying expertise is not required.

Absolutely, we now get an opportunity to become even bigger experts or larger experts in our field.

But we all collaborate tighter as an individual unit, and not relying on those silos.

I know a lot of the answers for this episode are going to depend on the type of team.

So maybe we'll hang out in bigger company land for a little bit first.

Like if somebody's listening, and they haven't actually taken many steps

in order to empower non-engineers to reach this higher fidelity level of prototyping,

or maybe have more access to what exists in code.

What are some of the baseline things that teams are doing that are taking

advantage of the moment that are, you know, just should be top of mind for pretty much

everybody in today's era.

And this is a non-zide-guisty response, but hanging out together as a team more,

and building rituals that allow you to collaborate synchronously, asynchronously.

That is a Slack channel. It's a document.

It's a figmify or other file that you prefer to collaborate in.

But doing that as a unit and not saying, I'm the product manager, therefore I own the PRD.

I'm a designer, therefore I own a design.

And I'm an engineer, therefore I own the high fidelity version of this idea.

It's a designer having access to the code base.

It's an engineer contributing to the PRD, and it's a designer just flexing in and out of these phases

of the process. I'm seeing so many speaking of large company land, so many large

enterprises, giving themselves a very aggressive Q1 target of basically reinventing their process.

And that is exciting. It's a little scary.

That's what we're viewing now is that design process that we thought was true is up for grabs

because things can be done faster as a cross-functional team.

We always wanted this. This is not a surprise or anything that is kind of out of ordinary.

Speaking to CTOs who are telling me that this is not a design leader, it's a technical leader.

CTOs telling me that they're able to work a lot more efficiently now.

And my question back is, what are you doing with this spare time?

And their response is building more products.

People are seeing that their opportunity for growth is wider now,

and they can make more products based on user feedback, which they can also get faster and build

better businesses.

When processes up for grabs, I do think a lot of teams maybe get overzealous.

I've even seen it from time to time. I'm sure that you have as somebody who is in more of that role.

For that scenario, are there pitfalls to avoid or signs or signals that would point to the fact

that, hey, maybe we are chasing the wrong thing?

Yeah, for sure. And this is linking back to the system's centerpiece.

I've had a concern for a while that design systems being a siloed team

means that people can just say if someone else is job.

And to me, a design system is a bar of quality in an organization,

and that's everyone's job.

So the thing about reinventing process means that there's an opportunity for

you to say it's somebody else's job or not.

And we still have to have clear lines of responsibility and output expectations

on each individual. The designer is still doing something specific to a designer's role.

It's not all the PM can contribute to prototypes now.

Therefore, I'm not going to make one.

So we have to have this level of acceptance of what a role can do at a bare minimum.

Plus, and that plus is defined by your industry, by your company, by your team, by your leadership,

by your experience, and your level of the organization.

The more optimistic person is looking to widen their skill set to become more generalist.

The pessimistic person is freaking out in the corner and thinking,

I don't know what I can do now because I can do everything.

It's also an organization to decide the bare minimum of what the expected output can be or should

be, and the designers are stretching into different angles that they feel like they'd like to.

For me, that looks like, as the closest opportunity is to become a better writer,

as a designer, write more documents.

Because that is, in my opinion, the best way to communicate an idea,

you could use audio, you could record your voice, regardless,

writing down before you commit to a pixel is the best way to get buy-in for an idea.

And you're not going to get the ability to ship an idea unless you get buy-in.

So a document is still central to that for me.

Kind of a spicy take in today's world, actually.

Like the prototype as the new PRD is the jargon.

Well, the thing is that, as soon as you commit to a pixel,

someone's going to have an opinion on the visual design,

but you need to get it signed off.

That in a forward thinking organization,

you have to have a design leader, a product leader,

whatever the title is, sign off on your idea before we commit to it.

And the best way I've seen to be able to do that is to write

a document of your findings and your plan,

and to huddle around it as a cross-functional team,

add comments, ask for other ideas, maybe add a loose mock-up of your idea.

But before we go and build that IFTELity prototype,

let's make sure we're building the right thing.

And that goes against my instinct, by the way.

My instinct is to commit to pixels as soon as possible.

I don't know, I do both.

I see value in both, for sure.

So if anything, I think I just appreciate the more nuanced take,

because it's very easy to come on here and say prototypes instead of PRDs.

I want to double down on the team structure piece for a second.

And maybe I'll just toss a hypothetical your way.

So let's say that you're brought in as a consultant for a,

let's say like a series B org that's growing,

and they're feeling the pain of having basically made no investment into the design system

up until this point.

They don't have any dedicated people.

There's no dedicated squad that's working on the design system.

So given almost like a blank canvas,

what would be some of the opportunities that you would pursue,

and what types of systems or people would you put in place to steward it moving forward?

Firstly, I would say that's my point about quality.

Quality is everyone's job.

And quality is everyone's business.

And if we don't accept or pursue that,

we should be treating ourselves as failing.

That is something I just feel deeply.

We have to have a high bar.

And that is company dependent, what that looks like.

But if we're not pursuing that, there should be consequences.

Because we're going to attract less customers,

we're going to sell less business,

and we're going to produce less revenue.

So that should just be sown into everything we do is what is our definition of quality?

And how do we get there?

That is regardless of the system,

because I think that the pursuance of quality gets you to a system.

Before you even know it.

But tactically, I guess you need a technically curious designer and a design curious engineer.

And for the system not to be an afterthought or a side project,

or something you're doing on top of extra work,

it should just be a thread through everything that you're producing as an organization.

So are we building components as a system?

We don't need to put the label on it.

Because I worry that putting a label on something like design system

can introduce conversations we don't want to have about budget,

and hiring and specialism versus a front end engineer doing a really good job.

And the designer doing a really good job to me produces a system as a byproduct.

When we start to scale it up, so your scenario,

you're building another product.

The easiest one is introducing dark mode.

That's when you have to start systematising properly.

Things like tokens.

That is a conversation we can have at that time.

But by that time, because we've all done a good job,

we have CSS variables, and we can extend them.

If by that time we have raw values across our front end,

we haven't done a good job.

And we would know that as we're building it,

that slack is just not going to fly anymore.

I'm feeling that even in my own work,

like the difference of even just putting checks in like a cloud MDE file,

where it's like, hey, we don't use raw values in these places.

Here's how we reach for certain types of components.

And it just is automated in like a GitHub review, you know?

It's amazing, actually.

Like you can feel how a very small amount of investment

into what this system should be, or maybe your language,

like where the quality bar should be.

And then how much the LLMs help you continuously hit it with every single PR from that point?

It's amazing.

It really is.

Let me present the other side of the scenario, though,

is that because we can generate anything we want as speed,

and so much of the success of an early stage company

is how much it makes the end user feel,

how much they want to return to you.

That is incredibly important,

which arguably means deviation from the system

is the wind or the key,

because we need to be able to attract people differently

every single time we talk to them.

So what does an infinitely flexible brand look like?

Because we're boiling it down to the brand at this point.

And that might mean that raw values are fine,

because for this permutation of the landing page,

we're experimenting.

And the soon as we get into like a systematization,

we're committing to something.

So there is definitely an argument of due tokens matter anymore,

or absolutely they have to be there from day zero,

because we're thinking about scale at every moment.

And we have to dance between these two worlds

of experimentation and committing to quality.

Experimentation can also mean quality,

but an over tokenization of something

can mean it's so robust we can't deviate from it.

And every stage of your product or organization

has to figure out where you lie on that line.

And maybe because everything can be generated,

it can take you half a second to scan a code base

to see raw values.

Does the tokenization actually help you at that point?

Or are you pushing the pixels around because you can?

So the world we're entering now is a raw value fine,

or if it's not, then how do you manage that?

If a raw value is fine, let's just limit them

to what the brand feels like.

And that can be written in the document,

that are the guidelines that you're talking about.

We can express what the brand should make someone feel like,

and rely on the other lens to get us there.

And this is where I like dance over my own words,

because in some ways, deep down I'm thinking system, system, system.

In other ways, I'm thinking, all the teams I talk to,

every single day, you struggle with this word adoption,

that people are not using the right thing in the right place.

And that world is just going to be flipped upside down.

Now, it's really happening.

It's really happening, yeah.

Even the word system is weird now.

Because the point of abstracting something

was to minimize the amount of knobs that you have to turn

in order to make changes that scale across the code base.

But now it's like the pain of that has diminished so significantly

where it's the difference between a 10-second LOM call

and a 25-second LOM call.

Like, I don't care, you know.

It's still going to be able to find all of the things.

So, like, what is a system at that point?

And I do kind of like how you're bringing it back to brand, actually.

And like the feeling that you're trying to evoke

because the specific way that that is constructed,

I don't know, maybe it does mean less.

No, I'm not sure.

It's weird.

Like, it doesn't fit into my box anymore.

The challenge we have, and this isn't a new point at all,

but if we rely just on generation of code

without a very strict indication of brand feeling,

we end up with all the things looking the same.

Yeah.

And honestly, that is fine for the majority of cases.

But if you really want to take your scenario

of the received a ton of funding,

we need to accelerate that is not good enough anymore.

So we have to figure out what that looks like,

what that feels like, what the tone of voice is,

what the imagery is.

And it dials us back out of what is a component

to what is the company's system

of approaching acceleration.

So taking the label of design system

at off what we're doing,

he's going to help.

And he's going to bring you out of the corner

and out of the silo

and to the center of an organization's change.

It's almost like the baseline quality line for a product.

But if you only stayed at that baseline at all times,

then it's probably going to be a boring product

that someone was to vibe code in a weekend.

So it's like given the baseline now,

where do you strategically deviate from the system

and do things that simply don't exist

in the set of rules that we're getting to the models?

And there's elevations there.

The person spinning something up by themselves

a weekend might help them secure some funding

to develop it further.

So that doesn't mean that thing you built in 12 hours

is what you should ship.

It's just a validation point for something.

Then you accelerate all the way up to the top of the line

where you've got this fully fledged tokenized system

which you can expand and even acquire

and merge companies into

and build out a more robust brand

in a more horizontal way.

But you have to figure out where you are on this line

which won't shift to understand what level of fidelity

you need at every single point of a product,

not just the system,

because the system feeds a product,

product feeds a system.

It's like a lot of the value proposition

of a system was in making sure

that things are consistent and standardized.

But it does kind of feel like we're going to be getting

a lot of that out of the box.

So that's not enough anymore.

Like you have to kind of find ways to make it

so that there is a level of attachment to a product.

And I don't know, even I think Shatzian

played a huge role in this.

There's so much network effects around

what the modern web stack is

and the more that we kind of spin this flywheel

of like everybody's building a tailwind,

everybody's building a Shatzian,

everybody's building a top of a vessel.

The baseline is rising, right?

It's like a good, clean, consistent design

is table stakes in many ways, you know?

I don't want people to spend their time reinventing

something that already exists.

I think that those days are limited.

But making it feel like your brand

is where you can put the energy

on top of a system that is already proven.

We've spent so much time trying to figure out

how to make accessibility someone's priority

or a company's priority.

And if you can get that out of the box,

take it.

You don't need to go and custom spin up your own

version of a pop-over component.

You've probably been sold.

And that is amazing.

The quality bar of, like you said, is higher.

So let's focus on what will help us sell more products.

And that might not be the most attractive proposition

for the picks of pushing designer.

That's the job.

And that's exciting.

You can get closer to revenue and showing impact

and getting closer to that promotion

that you're desperate for,

because you're able to get better access to stakeholders.

I want to dig into workflows and kind of the practice

of a designer.

Again, just kind of tapping into your vantage point

of somebody who's talking to a lot of teams.

And the first thing I'd love you to take on

is how wide is the gap right now

between enterprise and startups

in terms of the way that designers are operating

in these systems, but also just more broadly,

like approaching their day-to-day role as a designer.

Whatever the heck that still means now today.

It feels like it's getting wider.

And the reason it feels like it's getting wider

is because the access to tools is so vastly different

based on your security standards as a company.

If you're in a legacy enterprise organization,

it might be really hard to get an AI tool signed off.

If you're a high-flying startup,

you've probably just got these things out of the box.

You sign the contract and you just have these tools.

So the have and have nots or the digital divide

is something that we used to call it.

In this microcosm, it seems to be getting wider.

It does give me a little bit of concern

because I don't want people to feel like they could be stuck

in a role and not be able to get out of it

into a more progressive organization.

If they're in one that doesn't give them access to tools.

So that's something that the industry needs to figure out.

Pronto, because that could be a potential problem.

But how people are working,

the startups are high-flying.

They've always been doing that.

They're always trying to push the boundaries.

But what I have noticed is that people want to get

to production a lot faster.

They want to almost skip design.

And that is a potentially dramatic phrase.

But it's how it comes across.

To I have an idea and I want to get it live on a domain

now was the easiest way to do that.

And that was the conversation I was having last week.

And on the enterprise level,

through an enterprise software,

you've got millions of users.

You have to be a bit more considerate

about how to release something.

So that then looks like,

how can we shorten the time to production?

What tools can we use to accelerate feedback on this?

Or how can we increase the amount of users

that get access to a beta?

Or how do we use feature flags

to ensure that a subset of the audience can test this thing out for us?

What's the community approach to our software?

How can we build a team of people that we can rely on

for consistent feedback because they care about us?

And that is a playbook that I think everybody will use eventually

as you go up the stack from startup to enterprise.

But thankfully for me and for us is the community

people users passion is still incredibly important

for the success of an idea.

It's just that we're doing it faster,

but we can't skip the quality no matter how fast we want to move.

One thing that dive club has made abundantly clear to me over the last year

is that the practice of design is changing.

And the old process of getting feedback

just doesn't quite cut it in today's world.

That's why I'm excited to announce

that in-flight is officially in open beta.

It's the feedback tool that I've always wanted

and it's built for a world that moves at the speed of AI.

So I can share my prototypes,

give context and video walkthroughs,

In-flight makes it easy to get the exact feedback

that I need to move forward,

whether it's voting on directions

or maybe even getting the green light to ship a new idea.

And all of this is available in a single link

that I can drop into Slack

or maybe even share with power users

to test out a new prototype.

I use In-flight every day

and it's totally transformed the way that I share work.

So I'm excited for you to try the product

and if you ever want to jam about it,

just email me at ridatinflight.co.

I can't talk workflows without asking you

about the cloud, MCPE release that you just dropped.

I think it was literally yesterday.

So what are some of the things that that unlocks

in your mind that you're excited about?

It really does get me pumped for the world

that I thought I was entering

as a professional a long time ago

where I have an idea.

I want to test it properly.

I want to get it into a browser

and I want to feel it.

I want to know interactions,

I want to know transitions, timing

and being able to go from the canvas

to the browser, test it

and be like, that's actually not quite right.

Let's go back, let's riff on it.

That world for a non-technical designer

is going to open so many doors

because you can communicate what your intent is so much faster

because you can push it further.

It's a little phrase that we kind of throw around internally

is not faster but further

and that enables people who aren't technical

to jump in the browser, test something out,

open the aspect, say all that spacing should actually be 12.

It shouldn't be 10 or 8, or whatever it is.

Let's jump back into Figma and have 10 versions of this thing

spinning around, push that one to the browser,

push that one to the browser.

Still not quite right.

Let's come back via MCP or whatever we're using

and have this feedback loop for ourselves

without involving an engineer

that might take days or weeks to come back.

It's through no fault with their own, just through process.

So that's part of the process feels

like we could speed it up massively.

The key to unlock it even further is the system.

If you can push from your canvas to the browser

and back all connected up to a system that lives in a repo,

then we're going to iterate so much faster.

That is to me the gold mine of what we've been doing.

Yeah, same.

I close my eyes and I picture just having those two windows

side by side at all times.

That's how I want to work.

There's an element of yes, it is the system

and they're pointing at the same thing.

But sometimes I also just want it to be a whiteboard.

I just want to be able to quick scratch

and no, no, no, like this instead

and just immediately have that go to cloud or codex

or whatever I'm working.

And fluidly moving in and out, it feels like we'll look back

on the last, I don't know what it is at this time.

The timelines are blurring in my head.

The last three to six months as this blip on the radar

where we had this false choice as designers

where you had to kind of pick this path

and it was very difficult to traverse to the other one.

And as a result, I wake up every day

and I'm like, am I even a designer anymore?

Because a lot of times in the startup environment

like you're describing like, I just

don't bend up a local host, bring an idea to life

and hit send, you know?

And all I'm doing is writing code.

I'm still a designer then.

I don't know.

This is the beauty that the role is getting wider

and you tap in and out of whatever makes sense to you.

When I first started and I was contributing

to front end professionally,

I stopped because things got so complex

to set up an environment.

I remember Docker and NPM install and react and bundling.

And I just thought, that is not where I am right now.

Firstly, I've got no idea what you're talking about

when you say these terms.

And if it takes a couple of hours for an engineer

to help me set something up,

we've kind of got the wrong path.

So we reverse out of that into a design

of being able to do this without thinking

about what any of those things mean.

The idea wins.

It's not a technical barrier that you have to jump over

and pushes people further away, which is what happened to me.

Push me further away from production,

have more into the polishing pixels on the canvas kind

of persona.

And now we can reverse out of that one

and maybe meet somewhere in the middle

where the canvas is very important for ideation, collaboration

and general direction exploration.

But the browser is where we commit to it.

We bounce back and forth between these different mediums

to get the right idea, which I think is just exactly

what we want.

I love the idea wins.

It definitely feels like that's what we're headed

in that world and pretty bullish on designers.

Anybody with an idea is the beauty of this.

I like the word maker because it kind of doesn't define

specifically your role in an organization.

If an engineer wants to play around with interaction details

absolutely go for it.

If a designer wants to tweak the border color on a card

because they've supported the better contrast

against the background in this particular screen,

please go and change that token value.

Don't feel restrained by the process that was before.

I like how multiple times you brought it back

to collaboration too, because something

that I'm feeling a lot is like, yeah, I'm empowered.

For sure, I'm empowered, I can do a lot.

But sometimes it kind of feels like especially in a remote

company, it's just me and my agents.

No, all I am doing is just wielding my agents all day

and I end up collaborating with Claude

so much more than other people.

And I don't know, it's like it's one of those tiny

little signals where I'm like, huh, this feels weird.

I don't know, I don't know what to do it yet.

It's so much is changing.

That do you think you're learning?

Oh, I'm learning like crazy.

I think that bouncing back and forth between you

and a tool to get more sure of your idea before you commit

to, hey, everybody, what do you think about this?

I don't see a problem with that.

Outsourcing, everything you do to something

is where I get a little bit more concerned.

Because we are the experts in-seat

to bring something to market.

And if we're outsourcing our ideas, our output,

our definitions of anything to a tool,

then we just need to ask ourselves

what we really want to be doing.

And I would feel deflated as a maker as a creator

if I was just pressing, like, go, go, go all day on a tool.

Sometimes I do.

If I'm making me think of a plugin and I'm coding it,

I absolutely don't look at that code.

But if it works, I'm happy.

But I still have the idea.

I'm laughing because yesterday, basically,

all I did was work on front end and I use conductor now.

And I basically, it's Pavlog's dog a little bit

because you just live from one of the two

of the conductor horn to the next.

It feels like I'm playing this black and wool game.

Where it's like, all right, that agent needs me.

OK, now that agent needs me, now this agent needs me.

I feel this trap sometimes where, like,

going back to what you were talking about earlier,

it's so important to get by and into be sharing early and often

because when you can play ping pong with an agent all day

on your idea and go way further than previously possible

as a designer where I'm sweating the details

on every single part of this front end architecture

and all the hover states and interactions and everything,

it's tempting to just keep refining and keep refining

versus popping out and be like, hey, hey, I'm working on this.

Like, there's a couple of directions

that I'm thinking where that came very, very naturally

when my process was slightly more defined

and always started with me, you know,

hitting F on a canvas and drawing the rectangle,

whereas now I can jump much further as step one.

A lot of pros and cons, I guess we'll put it that way.

Don't get me wrong, I will start in code two.

And I think that starting from anywhere philosophy

is the new way of working.

You might start in a document, you might start in a canvas,

you might start in a front end,

you might start in any of those places,

but ultimately you're going to be bouncing through the tools

at some point, you might start in a slack thread,

to be honest.

And that will always come back to a process

that goes linearly through these phases

if you want to keep riffing and get the best possible output.

But yeah, I don't have problems starting in code

because sometimes you need to feel something to know what's wrong

and it can take a lot longer often

to draw out on the canvas than to say,

hey, generate me a web page for this thing.

I'd be like, now that's all right.

I would say though, these tools are not for,

hey, make me an app or hey, make me a website.

That's just not how they're designed

and not necessarily how I think we should be using them,

but boiling it down to real specific,

even like component level creation versus broad,

please solve the world for me.

Don't do that.

You need tools.

I got a YouTube comment today

and it was some skeptic saying like,

I haven't yet to see an AI design that solves a real problem.

And I'm like, hold on a second here.

What is an AI design mean to you?

Because to me, that's like assuming all we're doing

is just saying, make me a website.

I was like, I'm using AI to get a level of control

but I've never had before in bouncing in and out

of tools constantly.

But don't get me wrong, the average person

who starts a restaurant, they need a website.

And if they can get that done in 15 minutes,

they're going to take it and that is totally fine by me

because if I can go and read the menu with a website

and it looks kind of nice, I can get the contact details

and they're whether based and all the prices are,

I as a consumer also wouldn't mind that.

When we started to talk about software

renting a much different game

and that's where make me a software doesn't fly.

I'm helping my buddy right now

who's starting a local contracting business

and he really wanted a website.

And I ask him questions, what do you want on your website?

He has no answers, he has no idea.

So make me a website is not only valuable

because maybe the skill is not there

but also the ability to articulate what you want

is not there for the vast majority of people

who do not do design or do not operate in software.

So being able to just spit something out on the page

is probably the easiest way to even arrive

at what you actually want because you can see

and be like, I don't want that, I want this instead.

So I do see a ton of value in that.

Additionally, this isn't a new thing either

because we've had the ability for people to go

and spend $5 on someone making them a website for a while

and that made more makers or more people

who cared about websites in this case.

And the way that that's the same way I look at this now

is more people are going to be able to create their ideas.

We're not in a position to tell people

what they can or can't make.

So as soon as that restaurant website

needs to open another chain or another store,

then they might need a better website

and that's where they probably engage in a professional

to build a better system.

All right, so it's one thing to talk theoretically

about how the world is changing.

I want to talk a little bit about your story though

because you drew us this picture of January 2025

just a little bit, you know,

if there's a nervousness about where is all this going?

What does this mean from my role?

Obviously, everything has changed from that point.

So can you talk a little bit about your personal journey

with AI and where these inflection points are?

Yeah, I took a while of self-reflection and rearing.

The thought was about to happen and came out stronger.

I can't even tell you the amount of react courses

that I've bought over the past five years.

I can remember at least three or four, two or three.

Yeah, it's going to help you about it.

If you're calling me out on this,

I haven't finished any with them because I just don't

have the interest or time,

but Q2 last year, 2025,

I thought, hang on a second.

I could make plug-ins as a very easy entry point

into why I've been trying to learn.

I pull up an AI tool in that early days, early days.

That's funny to say that.

In the early days of this,

it was an enterprise chat GPT license

and that was asking me to help me make a plug-in,

copying code from the browser into my IDE.

Like a caveman and it worked.

And I thought, all right, okay,

we've got something really powerful here

where I can jump over those courses

that I wasted money on

and shipped a plug-in very quickly.

A week, two weeks, something like that.

Then it got faster a couple of days.

Then it was a couple of hours.

And I think I've published maybe five or six

feed more plug-ins or which it's over the past couple of months,

which is kind of nuts because they work.

They solve problems.

There's thousands of users.

People are giving me feedback.

It's open source.

People can look at the GitHub repos.

They can contribute it to if they want.

I received GitHub's star on one of the repositories.

Look at what the hell's happening here.

That's amazing.

And I think that is what we have on the table.

Is the ability to make utility tools

for our use cases at speed using these tools.

So I've gone from the chat you put in the browser,

copying code back and forth,

to a more integrated workflow,

where I'm using a tool that allows you

to have LLM's based in the IDE.

And I was chatting, balancing back and forth,

rewriting, rewriting, rewriting,

getting back into Git workflows and branches

and all that sort of stuff.

And hosting my code and GitHub pages for landing pages.

This just opened doors that I had previously closed.

And I'm able to work faster on these ideas,

get them out faster, get validation faster,

and solve problems.

So all of these plugins or widgets

have come from just conversations

with their community about what they're struggling with

and spotting an opportunity to help.

So in effect, able to do my job better as well.

It's inspiring because I'm also the kind of person

who has bucked more coding courses

than I care to admit.

I went through a whole bootcamp.

I don't actually think I ever technically graduated

from it, but I spent all the money.

They still took all my money.

I just didn't get the gold star at the end.

I think I actually had some giving up of hope.

There was like a couple of years.

I was like, I'm never going to be able to do this.

Like, I'm not even going to do this.

And going back to your word, empowering, I guess.

Like, I don't know, I'm at the point right now

where if I have any free time at all,

I just want to build things.

Like, I just feel like I can just shoot lightning

out of my fingertips, you know, it's amazing.

So I've been keeping a Google sheet

of startup websites for a couple of years.

There's probably 800, 900 websites in this Google sheet.

I've had a goal of just putting it somewhere.

And two nights ago, I opened my laptop on the couch

and just chatting away and saying,

I want to make this website.

Here's my Google sheet.

What can we do?

And they planned it out.

We'll be all something.

And then I close the laptop and haven't done anything

with it since I can make a bunch of new stuff.

And I still don't finish them.

But I'm still able to feel like that hour russer

in the evening was really useful to just explore.

And I can explore a higher fidelity.

I used to work with a guy over a decade ago, an engineer.

And I would just come to him on a daily basis

with like, I've got a new startup idea.

Let's build the Twitter for this

or let's build a new property management website.

Whatever it was.

And he'd say, yeah, I've got some developers

that I've got in my contact book.

Probably going to cost us 50, 100,000 to make it.

And I think, OK, end of the idea.

And now I'm thinking, spend a couple of days

prompting away and probably realize the idea is not good.

But at least I've been able to flex that and test it out.

And maybe one idea, one day, will mean something to me.

I can commit to it.

But instead of committing financially now,

it's committing with time, a little bit of money.

And I can monthly subscription.

As a designer, I'm thinking, I'm not alone in this.

Sometimes you just want to throw things at a wall

and feel what sticks and probably most of the stuff

doesn't.

And that's OK.

But we can do it faster now.

It also changes what the definition of success is, too,

because when software is expensive in order to be successful,

it has to have some semblance of scale.

It wouldn't make sense for you to make something

for your immediate group of friends in a world

where you are having to spend the amount of time

and money required to do it.

But now I've made a Super Bowl app just

for my family, just to play games together

while watching the game.

And 15 people used it.

And it was a massive success.

And I will totally do it next year.

And again, yeah, talk to me about two hours.

The key thing, I think, though, is just

because we can make something doesn't mean it

has to be widespread or has to have mass appeal.

Because the reality is, if you wanted to do that as a business,

that's the wrong place to start.

You need to go and market the idea now, rather than build it.

And I've also worked on sort of startups as a side project

where that hasn't been the focus

where a couple of years have been sunk into building something

with no one who knows about it.

And that market has shifted.

And that won't change just because we have access to the tools

and we can make things faster.

We can get it into production.

Doesn't mean there's any eyeballs at all on it.

And no one's going to sign up to this thing.

So keep it tighter, keep it the scope smaller.

And maybe something for your family is the best place

to get that itch scratched.

There's a phrase that I'm on a mission

to use as often as possible on this podcast,

which is the niche economy.

Because I totally, that's where this is headed.

You can create something that solves a problem

for 1,000 people, kind of what you're doing

with your female plugins.

People wouldn't look at that and be like,

that's your startup or that's your business.

But all of a sudden, well, what if you could do that

20 times as a designer?

You just solve any problem that you can find.

So given that, given all of your explorations,

given this windy journey of the last 18 months for you

that probably feels like a lifetime,

you know, it does for me.

How the heck are you thinking about your career

moving forward, given where you're at?

Honestly, don't know, because I've never known.

I've never planned my career.

I've just taken the shots that have come up

or put in a different way.

I've taken a lot of shots

and some of them make the basket and some of them don't.

But I would not stop shooting.

And I don't know where that ends.

The industry shift will settle inevitably.

And things will boom up and down.

And I'm kind of just holding on

and focusing on what I like to do,

which has helped the community at scale

build better software.

Where does that go?

Hopefully just better software.

What does my role and that look like

using my platform to enable people to do that?

Do I have a one year career plan?

No, two, five, 10?

Absolutely not, six months.

No.

Three months?

No.

The amount of things that are changing on a weekly basis

needs to, I think that it's a fruitless task

for someone like me to try and plan their career

because I can't even rely on a company's roadmap

at the moment to know where I fit in that.

And that's for everyone.

So I'd say I'm going to continue doing what I enjoy,

pushing that as far as possible,

putting as much pressure on that as possible.

If I'm not enjoying it, then what's the point?

Do you feel pressure, though,

essentially, who is in more of like an education role

to keep up with everything,

especially given how quickly it's moving?

That is difficult, I'll be honest.

It's being resigned to the fact that I will never know everything.

I didn't, and I will never will.

The market getting much wider is kind of crazy, the tools,

the expectation on designers to in some places

become a lot more technical.

I'm never going to be able to talk at the level

of a full-time React engineers.

That's just not going to happen.

But hopefully I can help facilitate the conversation

between the designer and that engineer

to build a better workflow for them in that company.

So yeah, I do feel a personal pressure,

not professional pressure,

to just know what is required at what elevation

to get the work done.

And I'll figure that out.

It gives me the opportunity now to lean into different parts

of the role, different parts of the industry,

and to find new enjoyments.

That to me, the last year has been getting back into GitHub

contributions.

That me in the next 12 months, who knows?

I'd hate to lose touch with the importance of writing.

I'd hate to lose touch with the importance of quality bars,

pixels are still incredibly important.

Personally, I've been focusing visual design quite a lot,

so that's always going to be there.

It's open.

But take my shots.

I think I have someone who has always

just been the ultra-early adopter everywhere.

I was obsessed with scrolling on product

hunt every single day for years, try every single tool.

I just came so naturally to me.

And I think I've wrestled with this reality

that I actually can't be that person anymore.

It's impossible.

There are too many tools.

Too much is changing every single week.

And so it's almost like a failure state to try.

But then you have to develop new razors to use internally

to figure out, where do I invest my time?

What is worth pursuing?

Why is 80% of my Twitter feed open call hacks?

I don't even know.

It's a little bit intense as somebody who

is just trying to hang on for the right.

And I'm sure everybody feels that, which is why I was

asking the question, because I know you do feel

some pressure to stay up to beat the stuff.

I do events every week.

And people always put their hand up

and be very honest and say, let's get.

I don't know what to do.

And that is tough to hear.

But we have the platforms to enable people

to understand what is possible.

And I think that you can easily

paralyze by limitless possibilities.

Even what you talked about then about opening Twitter

and seeing a specific type of content,

you can just be flooded by people seemingly

doing very similar things.

I think that's probably one of the reasons

other than the obvious why Twitter community felt

like it failed a little bit, because people didn't know

where to fit in or didn't know what to talk about,

because everything just felt like everyone was saying

the same thing.

So communities are still very important,

where people don't know where to go to find

their like-minded people.

They're just going to be fitting like they're alone.

So community is still incredibly important

for people's careers, satisfaction,

and to know what to do.

I just don't know where it is a lot of time,

because it feels to be a fragmented.

I want to try a little bit of it out there question

before I let you go, because I think

there are a lot of narratives out there right now.

And some of them are probably quite safe to ignore,

and they're just overblown.

Some of them, there is some truth in designers should

kind of take it seriously.

I'm wondering if anything comes to mind for you

in terms of a narrative that there's not that much

truth to it right now.

You can safely ignore this, whereas actually this is

where the world is heading, and we can't just bury our heads

in this end as designers.

I went to my parents' house at the weekend,

and I felt a very strong tonal shift in dinner conversation.

My parents didn't go to university,

but AI was raised as a topic of dinner conversation,

or after dinner conversation, after a few glasses of wine.

And the prevailing thought, at least in my circles,

it's probably negative first when it comes to this stuff,

but people were just telling me their use cases.

My brother has a finance background.

His wife is a psychologist.

My sister works in admin tasks for a company

that sells fire extinguishes.

These people are not who we are,

but they were talking about how their jobs,

their lives have been made easier with these tools.

So my prevailing narrative that I think we tell ourselves

is not the mass market-consumered narrative.

And I think that as the dust settles,

people will find real use cases that help them every day.

And that's hard for me to somebody so into it, to see,

because I get hit on Twitter with negative thoughts all day.

But I can see through it,

to the everyday consumer has a use case for this.

My friend, who works in marketing,

he has a personal open AI subscription with projects,

and he's got tons and tons of documents running all the time,

helping him immensely with his everyday life.

He's got ADHD, he helps him a lot.

So I take myself out of the negative first mindset,

which is as a natural pessimist, quite difficult.

My personal one of a narrative that I have,

but don't project necessarily is whether we like it or not,

as designers, makers, people, most software sucks.

And people don't really care about the pixels.

And that has been a challenge for designers

me included in previous roles,

to convince people to care about it.

But the role now is, because there's so much software

on the market, because there's so many websites,

so many businesses, we have to focus on sales,

we have to focus on getting revenue and getting users

and science ups and acquisitions.

So the pixels are secondary to the success of the business.

And we can come to the pixels at a point where it makes sense,

or not at all, as we generate more things,

more software is going to be created,

more websites are going to be created, more apps

by people who don't have a design background.

We just got to accept that and not try to fight it.

There will be roles that you go for

where your manager or manager's manager

doesn't really care about the pixels.

And that is a fight not worth fighting,

I don't think at the moment.

I was thinking about my own answers.

I think there's a narrative right now

where people who maybe are slightly more skeptical

of AI say, the blurring of roles

is just because businesses want to pay less

and of course they want you to do more.

And that's what's really happening,

but everything will settle.

I don't really believe that's true.

I think that we have drawn an artificial line

between a picture of the front end and the actual front end,

just based off of the technical capabilities

that were available to us.

And I think that the actual front end

will fall under design.

And that it actually is just a whole collection

of things that totally fall under the definition of UX.

But as an industry, we've refused to admit that.

And so we've just punted it off to front end engineers

who don't really care about the details as much as us.

But that at some point we're just going to realize

that's just UX design and that's the new role.

There are more businesses being created.

The hopeful argument of smaller teams

means smaller teams in more places

on more problems being solved.

As a person who enjoys that startup accelerated pace

kind of atmosphere, that's exciting.

But for somebody who enjoys working

in very large organizations,

that might be the opposite feeling for you.

But I do see more startups, more opportunities

to raise money and build your own ideas now.

Yeah, I totally agree.

It's like there was a line,

this is my economic brain thinking,

but there was a literal line on a graph

where if you could not generate this much profit

based off of this problem, it's not worth pursuing.

It doesn't make financial sense to do this.

And that line has just fallen.

There's whole subset, there's this whole category of problems

that previously nobody had the financial incentive

to solve that are just wide open.

Look around you, like local businesses, oh my goodness.

There's so many problems that anybody listening to this

is totally capable of solving on their own, fully.

Take your shot.

Take your shot.

Yes, yes, I like it.

Well, I can't think of a better line to end on

than take your shot.

And Louie, I appreciate you coming on

and giving us a little bit of like the insider scoop

but also just telling it how it is

because I think you're feeling this like everybody else.

You know, it's a crazy time

and sometimes it's good to just shine a light on the reality

and I appreciate you coming on today

and doing that with us.

It's always fun.

Thank you very much.

Pleasure as always.

Before I let you go,

I want to take just one minute to run you

through my favorite products

because I'm constantly asked what's in my stack.

Framework is how I build websites.

Genway is how I do research.

Grenola is how I take notes during crit.

Jitter is how I animate my designs.

Lovable is how I build my ideas in code.

Mobbing is how I find design inspiration.

Paper is how I design like a creative

and raycast is my shortcut every step of the way.

Now, I've hand selected these companies

so that I can do these episodes full time.

So by far, the number one way to support the show

is to check them out.

You can find the full list at dive.club slash partners.