Subscribe
Share
Share
Embed
Tom and Jonny are joined by Domingo Widen, Staff Product Designer on the Front-End Infrastructure team at Fin (formerly Intercom)
Domingo shares how designers at Fin have moved from prototyping in sandboxes to shipping directly to production, and unpacks his team's mission to build the platform and tools that let every team move from concept to production faster with AI.
The conversation traces the story of getting designers into developer environments — from a top-down mandate and painful early setup sessions to a smoother, engineer-assisted process — and how that groundwork now lets designers self-serve with Claude.
Domingo introduces "Surge Intelligence," an encoded knowledge base that powers design-system skills so AI can enforce front-end conventions without a human policing every decision, and describes the PR-style review process for designers who want to contribute their own skills.
The back half explores where design is headed: the enduring value of human judgment and "taste" built through reps, the edge cases only builders learn from experience, and why Domingo believes AI will keep design work capped around 85% for a while. They close with quick-fire questions on tools he wishes existed (a home for aligning on live prototypes, since Figma hand-off has broken down), his favourite product (MyMind), and what he'd do with his free time in an AGI future.
Chapters
0:00 – Intro & welcoming Domingo Widen
0:52 – How the Front-End Infrastructure team works today
2:20 – Is Domingo still a "product designer"?
3:49 – Splitting time between infra, design system, and product work
4:22 – Getting designers into developer environments: the origin story
9:45 – Optimizing the setup process with engineering
14:20 – From constant support requests to a self-serve steady state
11:29 – Claude as a fallback for technical hiccups
12:14 – Enforcing design consistency without slowing the company down
14:02 – Introducing Surge Intelligence and how design skills read from it
15:57 – Serving both designers and engineers with shared knowledge
18:13 – Do designers see AI codifying their instincts as a threat?
20:09 – The 85% problem: where human judgment still wins
23:52 – Codifying skills: the PR-and-review process for Team 2X
25:11 – Human judgment vs. automated skill approval
26:15 – Predictions for how the designer role evolves industry-wide
28:20 – Foundational design knowledge that AI won't replace
30:37 – On "taste," reps, and gut instinct
32:38 – The superpower (and blind spots) of designing in code
34:24 – Is Claude enough, or will tools fragment further?
36:20 – The missing tool: aligning on live prototypes instead of Figma
39:28 – Zooming out: is this a temporary infra push or years-long work?
41:12 – Why this becomes "training the brain" rather than a one-off project
42:56 – Optimizing for designers, engineers, and PMs alike
43:56 – Quick-fire: coffee, drawing, and life after AGI
45:37 – Quick-fire: the product Domingo wishes he'd designed (MyMind)
Useful Links
Domingo’s website: https://www.domingowiden.com/
Domingo on Linkedin: https://linkedin.com/in/domingowiden
Mymind: https://mymind.com/
Podcast feedback: podcast@nearfuture.works
Near Future workshop (Aug 13th): nearfuture.works/build
Find us at nearfuture.works
Creators and Guests
What is Near Future Podcast?
A regular podcast covering design and AI from the founders of Near Future, a boutique AI consultancy focused on teams that care about craft. We cover both what we're seeing on the ground and industry trends, ways of working and occasional guests from the design world.
Tom: Hello, welcome to the Near Future
Podcast, , where today we have our
second extra special guest, Domingo
Widen, who is a staff product designer
at Fin, formerly known as Intercom.
Domingo works on the front end infra team.
We're gonna learn more about that
today, and we'll hear about some
of the exciting, things they're
working on and how they're working.
I wanted to also set a bit of
context for the start of this
episode that Domingo and I used to
work together, years ago at Monzo.
Super fun to work with you, Domingo, and
it's nice that we can return to a light
touch collaboration like this to, hear
how things have been going since then.
But also, you shared some really cool
things at a Mostly Working event which
we ran in January or February earlier
this year, an AI and design morning where
you came and gave a demo of what you're
working on and how prototyping works at
Domingo: Nikorov
Tom: We're gonna, kick off with perhaps a
little bit of an update on how things have
gone since the start of this year, , in
terms of how the team is working today
and how you're working on the team today.
Domingo: Thank you so much
for having me, first of all.
Things are continuing to evolve in the
sense of we are all using AI more and
more, and I think designers are getting
really comfortable with actually going
in and shipping a change to production.
So that's been the biggest shift that
I've seen in the past six months.
Designers going from, "Hey, I'm gonna
prototype something in this like sandbox,"
to, "Actually, I'm just gonna prototype it
directly in, in production, and I'm gonna
create a PR, and I'm just gonna submit
it, and then it will get approved or I
will work with Claude to get it approved."
So that has been the biggest shift.
If-- Designers are way, way more
comfortable with doing that.
and yeah, my team basically for context
as well, for everybody, my team is
called Front-End Infrastructure.
We own the whole front end of the
application, and our mission is to
build a platform and tools so all
the teams can ship faster, safer,
use AI and like just get from
concept to production the fastest.
Whether it's building prototyping
tools for designers to building
pipelines for engineers so they can
ship React quicker, quicker as well.
So we own the design system,
we own security in the front
end, we own a bunch of stuff.
so that's kinda what we do
and how things have changed.
Tom: Domingo, just to clarify, so
your role these days, is it still
in the world of product design?
Would you consider it, would you
consider your professional role product
designer, or has it shifted or evolved
into something more infrastructural
Domingo: I think it's a mixture of both.
I do, go and help with
teams, so I float around.
So over the past few months,
for example, I've been helping
with a team called, Operator.
So it's a product that we're
building which allows you to
configure Fenn directly with AI.
So because I have a good overview of
all the patterns across the system, I
tend to get tapped to be like, "Hey,
can you just go and help that team?"
And like influence how they're building
certain patterns, and it's really helpful
because then I bring that information
to the infrastructure team and say,
"Hey, I think we just need to build
a new navigation for these folks."
Or or, "These folks are, like, taking
way too long to code certain things."
or, "Actually, we should change
this design so we can help them."
So I tend to f- split my time
between, like thinking about the
infrastructure, the skills, the
tooling, the design system, and all
that stuff, but also going in and,
doing product design and prototyping
myself and helping others essentially.
And also a little bit of evangelizing
that I do across the team.
Just "Use AI.
Use it now.
Use it more."
Yeah.
yeah
Tom: Are there any, Slack
reactions in Fin for Domingo AI?
Domingo: Yeah, there is like a, they
always, the team always makes fun of me
sometimes because they say that, I should,
start having my own YouTube channel,
because I've been doing, I've been
doing, a few interviews like these ones.
I enjoy it.
I enjoy talking about how we're
working, and I have the privilege of
working in a place that w- allows us to
experiment, so why not talk about it,
Jonny: Domingo.
Nice to see you again.
I was at the Mostly Working session that
we ran in, or I, attended in, I don't
know, February, something like that.
that was this crazy time when were
appearing, and the Opus models were
getting really good, and it feels like
people were moving from-- or designers
were moving from AI as something
that I should play around with to
AI can really power things for me.
And, I think much has changed in
the six months since across the
industry, but I remember you demoing
what you had built and telling a
story around what you'd built at
Intercom to get a hundred designers.
Is it about a hundred
designers, something like that?
running, prod as part of the infamous
now Q3 or Q4 goal to get every
designer shipping something in prod.
I remember it being talked about
last year in twenty twenty-five, and
everyone was like, that's crazy."
And now it feels like not that
crazy, But, Intercom have always
been first to all of this stuff.
I suppose w- to get to an actual question,
I-- it would be-- I think it'd be really
interesting to just hear you talk through
the process you went through to get
from no one can do this, no one-- no
designers feel comfortable, to everyone
has done it, and how much of that was
hearts and minds in helping designers
comfortable in the terminal, and h-how
much of that was building infrastructure.
I think for anyone that want-- any
designer listening to this who's "I really
w-wanna get everyone going," was your--
how would you, recommend you do it now?
And maybe it's different to how you did it
because the tools are different, but yeah.
what was the pain?
Domingo: So When we started, I was one
of the first ones to do it, and you all
started because I was working on a big
Intercom thing redesign at the time, and
my engineer was exploring with a lot of,
color tokens and stuff like that, and I
just wanted to be able to do it myself.
we already engineer-- the engineering
team was already dabbling with AI,
and he, said to me, "Why don't you use
set up your developer environment?"
And, I was one of the first designers
to go through the process, and it's
a, complicated process, setting
up your developer environment.
every engineer that comes in into
Intercom, Finn comes in and needs to
spend, the first half a day or day
just installing all the things and,
making sure everything is secure.
so I did it, and I, saw the
benefit, and I started dabbling
with AI, and I saw others as well.
And, it became apparent that when you're
in there and when you have an AI tool,
you can start a-asking questions about
your code base, not even prototyping.
You can start asking questions
around what are the edge cases?
How is this data structure?
Why should Iâ¦
How does this work?
Is there any other file, files
that are using the same component?
And how many other pages
are called this way?
You can really use your own code base
as a knowledge base to understand your
product, to find edge cases and to work.
so the-- I can't say that
it happened organically.
I think the leaders within
the organization, theyâ¦
Some of us did it, and the leaders with
the organization, they saw the potential
of, everybody being in code as well.
and Tom, our head of design, he set
up a mandate saying everybody should
be on-- in-- set up in the developer
environment by, I can't remember
what it was, but, by a certain date.
That was stressful, for a lot of people.
A lot of people didn't want to do it, but
we went through the process of, we s- we
wrote a lot of guides on how to do it.
We worked with engineering.
Engineering was really open
as well, which helped us.
They were like, "Yeah, sure.
Why don't-- We'll help you out,
and then why don't you do it?"
And they gave us engineers to, help us
write the guides, and, we, we run multiple
sessions where we will spend, three
hours on a, room with an engineer, and
everybody will be setting things up, and
somebody will be like, "Oh, it's blocked.
I don't understand what's happening."
And then the engineer will be like,
"Actually, you have to run that
script again," or, "Actually, you
have to run that script again."
so the process at the
beginning was like that.
It was very difficult and-- but then
we optimized it and, we worked with
engineers to, make it a bit easier.
And we actually spotted problems
because we-- one of the things that
we told engineers is like, "It's
really difficult to set this up,
and it's not very user-friendly.
Why are you forcing your engineers-"
to go through a process that is
not user-friendly, And we then
influence that back intoâ¦
We have a team called, Team Builder Tools.
So Team Builder Tools is the team
that manage all their organization's
engineering tools and all that
kind of stuff, and then theyâ¦
or developer environments and stuff
like that, or security, or pipelines.
So they were like, "Okay,
actually, you, you were right."
And so they, also im- helped us improve
some of the processes, the scripts, so
they are shorter, so we have to do less
things, and they helped us write a guide
that is pretty, is in a pretty good space.
The thing about all of this is, once
you set it up once, then it's done.
Then the problem becomes teaching
designers that they need to start
behaving like the engineers.
every time you open your developer
environment, you need to pull your
changes, and and you need to pull
the latest from master, and you need
to make sure you update because we
might have launched a new version of
a package that you haven't updated.
So thatâ¦
Once we went through the process
of everybody set up, the problems
after that has been like, "Oh, my
developer environment doesn't work."
it's because you haven't pulled your
latest from master, and it's because
you haven't updated your package.
and now we are l- we went through
the whole process and we are in a
stage where, designers are likeâ¦
That nobody's asking about it.
Nobody's asking it's broken.
People are using Cloud to, self-serve
or, everybody's kn- knows it.
So it's mostly, serving the new
designers that are joining that are
like, "Okay, need to set it up again."
And then we help those specifically.
So that was a very long-winded answer, but
I, hope it gives you a sense of the story,
Jonny: Yeah, it makes sense.
I think you, you start with Mechanical
Turk or with, human-powered support, and
then you build infrastructure around it.
It's cool to hear that the
engineers get to benefit as well.
it's ridiculous that it takes a
non-technical person to set up a
good developer, a good DX on, on,
your first day that it's the design
team that forced that to happen.
Domingo: Sometimes things break and like
I've, gone into a situation which is
like something broke for m- for me like
last week, and I couldn't get it to work.
And my engineer was like,
"Have you asked Claude?"
And I was like, I, was just like gonna
ask this engineer how to help me out.
And I'm like, "Yeah, I should ask Claude."
And obviously Claude has a lot of
knowledge because the infrastructure
teams have been building a lot of
knowledge into our Claude instance.
So we-- It's good at it.
So yeah, it helped me get
out of It, it now works.
I didn't have to involve anybody.
Just Claude just fix it.
Jonny: to ask actually about, your,
in your role as arbiter of consistency
and using the right components and
using them in the right way and
leaning on the conventions, how much
of that is hard encoded versus you're
building a bunch of skills, and
you're getting people to use those
skills, and most of the time it works?
like how, much can you guarantee
that you get that consistency versus,
it's shaping rather than, like a real
exact craft, if that makes sense?
Domingo: Yeah, I I stumbled upon this
role, so I've always-- I've never
have to work on design systems until
now, and I realize that, in a lot of
companies before or even at Intercom
at the beginning, the-- there is always
the consistency problem, and there is
always a-- the design system team or
the person that maintaining it, it feels
like, they're policing pe- policing
people or slowing people down or saying,
"Hey, you, don't have this component.
Don't go there because it's not ready
yet, and then you have to build until
it's ready, so you can build it."
And I just realized early on, and I told
my team, like when, I kinda started doing
this, I'm like, "This is not gonna work
because we can't slow down the company.
We're moving really fast.
It's something that we're known for,
so we need to build-- we need
to be open, so like for the
consistency not to be there."
Jonny: Yeah
Domingo: and we need to try to
enforce things in a different way.
Like the-- I can't tell a team,
"A, you shouldn't do this right now
because it's not ready," b- if a team
can build it in an hour with Claude.
They're just gonna do it anyway.
So I think we've been thinking
a lot about how to en-enforce
our patterns in a different way.
So like the thing that we work on
right now a lot is I still go and join
design critiques, and I tell designers,
"Oh, you should have not used that,"
or "Have you thought about that?"
Or "Yeah, maybe use it, but be aware
that you have to change after."
but what we work right now is we--
our design system is called Surge,
and we basically started playing with
skills, and we realized that they
kinda no- don't work all the time.
So we realized that skills are
only as good as the knowledge
base that they read from.
So we've been working on this this
thing that we call Surge Intelligence,
which is like a collection ofâ¦
It's-- It basically encodes how
the front end is built, not only
design-wise, but also e-engineering-wise.
So it's like the best practices for React,
the best way to do imports, the best
way to use color, the best way to use
typography, tokens, the best way toâ¦
when to use a button, when not to use a
button, when do you use an input field.
And it's all essentially MD files that
are all structured in a way where then
now what we've done is that we rewrote
those skills to read that, those files.
And every time those skills run, I
guaran-- I can guarantee that Claude
will read the design files from Surge
Intelligence, and it will give you
an answer that is informed by us.
So that way we can extend our
influence without us being there, So
if a, if an engineer is like asking,
"Oh, is this page designed well?"
Then Claude will automatically, with
the word design, will trigger into Surge
Design, Surge Design skill, and it will
just be like, "Oh, let me just check
the files from Surge Intelligence."
And it will be like, "Oh yeah,
actually you didn't use the
area label for this stuff.
You should have used this area label."
and it's okay, cool, done.
so we're still improving it But
it's how I see the future, where
I'm building the, not the brain, and
then this thing is going and helping
you, but I don't have to be there.
I don't have to, be in
all the conversations.
And partly we're doing it a lot because
there is engineers working-- There's
engineers working without designers
because they can just build features on
their own, and there is designers working
without engineers as well, where they
are also building features on their own.
So we need to have, really powerful AI
tools so they can get their job done.
That's the mission.
Tom: Surge Intelligence sounds super cool.
of that audience split that you
mentioned, engineers and designers, do
you serve them both equally, or do you
find that your time is more spent with
engineers or more spent with designers?
How do you think about
that audience for this?
Domingo: s- we serve them both equally,
but there is more engineers, essentially.
So we are optimizing things to be
really easy to understand for engineers.
When it-- especially when it comes toâ¦
Because one of the things I'm slowly
encoding is decisions on when to, use a
pattern or not, or like what is a, when
should you use a secondary button and why?
And like, how big should it be?
And make sure that it's this big
when this is happening alongside it.
So there is a lot of design
shared knowledge that we know.
We like, we look at a page and
we're like, "Yeah, that should
be a secondar-secondary button.
That should be primary."
But our engineers just don't necessarily
train into that, so we have been trying to
really encode some of those decisions so
an engineer doesn't have to go through it.
Because I wanna allow
them to just build a page.
So they, the designers, they don't need
to waste their time QA-ing these pages.
They can actually put their time
creating vision, and what's next,
which is what I think designers should
be spending their time, essentially.
yeah.
Jonny: Yeah, it's interesting you--
when your audience is engineers,
you have to layer on an e- an extra
thing that if you were working with
designers, you could s- fairly safely
assume through the interview process and
working at Fin that they would be able
to decide which button's appropriate.
so I suppose if you're building these
skills for designers, it's very much
about filling in the, engineering
half, like use the right component
and make it semantically accessible
and, like all of this kind of stuff
and build, write the code in the
correct way, so coding convention.
But then if you're working with
engineers, actually the missing
knowledge is the design process,
so it becomes more about UX.
so they're quite d- they're probably
quite different skills, and you need
both for the different audiences.
suppose it just makes me wonder
if side is seeing this as
threatening to them in any way.
if you've got designers like trying
to codify their knowledge so that they
don't have to do that anymore, do they
see that as "Now I have more leverage,
I can do more important things"?
Or is that, not how
they're thinking about it?
Domingo: I don't think anybody,
here, at least here, is
thinking about it as a threat.
And I think it's becomes--
it's because of the way we
approached AI from the beginning.
Like, we're building AI agents.
We were told very early on,
use AI to make it faster.
It doesn't matter.
Yeah, just use it.
And I remember at the beginning, we
were even allowed to have subscri--
any subscription that we wanted.
I could just try all the tools and
then fi- figure out the w- the way
that, that one that was faster.
Now, obviously, like through the,
through learning, we landed on Claude.
Claude is way better.
You can really s- build
infrastructure on Claude.
but we've always had the men-
the mentality in the company of
this is not gonna replace you.
This is just gonna make you faster
to do all the things, and then you
need to have the critical thinking
to make the decision yourself.
one of the reasons I One of the, triggers
for me to create certain intelligence is
because I also saw designers doing this.
s- designers automatically started
writing their own skills to help their
engineers in their teams QA things because
they didn't wanna spend time QAing,
Jonny: right
Domingo: And so I was like,
that makes sense, right?
Like they-- nobody wants to
spend time QAing, and they wanna
just create the new things.
So it makes us realize
actually, yeah, thisâ¦
There is a lot of like jobs
that designers don't wanna do
and that could be automated.
And there still need to be a
pass, a design pass on everything.
but if an engineer can get
it like 85%, that's great.
Then we canâ¦
We 85%, we can put it
in front of our user,
Tom: Definitely.
That
Domingo: we can start learning, And then,
okay, let's do another pass if we want to.
yeah.
Tom: Yeah, that makes a lot of sense.
And something that hearing you
talk about it makes me think of
is there are two, two questions.
One is X number of designers who have,
built their own skills to codify their
own instincts, what does the pipeline
look like for getting that design insight
into the stuff that you're building?
Or is this sort of Domingo-led and
everyone else has to up to that?
And then I guess related to this is,
have you found there is a line where
can codify to a certain stage, but then
maybe that's the 85% you're referring
to, but where is it really difficult
to apply, an AI-defined bar for what
is good and where does it require
that human input in the process?
Domingo: so the-- in terms of
skills, designers are-- anybody is
allowed to create their own skill
and the way the skills work, they
run on your own machine, basically.
we do have a team called Team 2X,
which is like 2X, going faster.
It's like you go-- we go two X faster.
They basically maintain the skills for
the whole organization, and they have a
big repository where we have actually--
we've-- what we created for Claude is like
plugins that then we attach skills to.
And then those plugins, when you install
your developer environment and you install
all your things, those skills are there,
and those skills were approved by us.
So there is like two levels of skills.
There are skills that are like global
for everybody, like the ones that
we create for Surge intelligence.
That's like Surge design,
that's for everybody.
Surge content, that's for everybody.
Handoff, that's for everybody.
But then a designer might have their
own small thing that they created
for themselves on a day-to-day.
They should still be allowed to.
Everybody can contribute to the master
big 2X repository, but they-- there
is a process where you go through.
So you actually open a PR and the
Team 2X go-- sees it, and then there's
a bunch of extra AI review on your
skill to make sure it's as good as
the skills of the master repository.
And there is conversation that
happens because designers are
saying, "Hey, the main intelligence
skills doesn't do this and this.
Can we have it do this?"
I'm like, "Okay, cool.
Let me justâ¦
you use it in your local for now.
Let me just put a change for the
master one or like just open a
PR and then I can upgrade it."
And then like it basically
works very much like GitHub.
It's, GitHub basically.
We're like, "Open a PR.
I think the skill should be this,"
and then we change the skill because
it's all kind of a repo basically.
so that's like the first
part of the question.
Yeah.
Tom: Got it.
And that requires, it
sounds like human judgment.
Like people are pinging you on Slack or
whatever and saying, a thing," and they
wanna augment what already exists, and
then you go through that process together.
It's not fully automated
Domingo: It's not fully automated.
You, you-- We go through a
process of should we change it?
I'll read it.
And, then the thing that is automated
is once it g-it gets into the
repository, it doesn't get approved
for everybody until there is a process
that Claude goes through within those
skills where it improves it based
on certain criteria that our teams
define for security and for speed and
for conventions and stuff like that.
Yeah.
so that's the first part.
I can't remember the second
part of the question.
Tom: it w- it was around the line for
what is codifiable versus will always
require human judgment, and is the line
you have in your head of what is feasible
to get that to, or is it a matter of time?
in, in a few months, will you
be able to get it to 90 or 95%?
And I guess I'm trying to r- really
understand the sort of human leverage,
in the process of getting something
live, especially something that
is built by an engineer that has
AI judgment into it in some way.
Domingo: I still think it's,
I think it's a matter of time.
I still think it's gonna be 85%
for a long time, because humans are
really good at, creating patterns
between multiple things they see.
like just spotting, spotting the things
that are related to each other and having
critical thinking to say, "Actually, I
don't think this is the right thing to
do for this user, because I've had a
conversation with that user and, and this
is what they're actually referring to."
So there is, there is--
the decision-making should
be like, it's human.
It's a critical thinking to spot whether
you're tackling the s- the right problem.
one of the things I tell people sometimes
in this is that you should read.
Everybody should just read.
Read books, Read sci-fi.
Read, because reading, you ha- you're
gonna spend a lot of your pro- time just
reading and de- decoding information and
figuring out, is this the right thing?
Is this a bad thing?
And I've noticed that
also AI tools are veryâ¦
They wanna please you, so they will go
to great lengths to code the thing that
you're asking them to code, even if
sometimes you can put as many safeguards
as you want, but it will still do-- they
will still try to break the rules to
please you, which will then result in
weird u- design or, duplicated design or
things that maybe don't make sense or,
things sometimes that if you think about
them critically, you didn't needed to
build that for V1, You could have built
half of it, but because you could do it
with AI, AI just build the whole thing,
and now you're in a position where you
have to "Do we need this whole thing?"
so I think humans are very good
at, "Maybe we should start smaller.
We don't need all the, all of
this," when AI will be s- will
tell you, "I can do everything.
I can plug in a database.
I can do it really, fancy for you."
But that maybe that's not
what you need, for a user.
You use-- you might just
need a small, slice.
and yeah, that's the fight.
I still think it's gonna
be 85% for a, while.
Yeah.
Tom: Makes sense
Jonny: Domingo, w- I think what you
described yourself as is maybe this
hybrid type person that lots of people
seem to be talking about, where you're--
you may be a designer as your first
study, but then you turn into just a
builder, generally, or you do a little
bit of product thinking and a bit of
design and then a lot of building,
and that's just what you are now.
I'm interested to raise it maybe a,
out of Finn-specific, how you feel this
is gonna drive what a designer does
m-more generally across the industry.
Like w-what are the
patterns you're seeing?
What's your predictions
for the future around this?
will, w-will we all end up in
these, design ops, devopsy roles?
How many people are gonna be
still shipping products in a more
traditional product design way?
d- turning into design engineers, everyone
wants to be one of those at the moment.
and, what's the role then of, the
pure creativity, divergent thinking,
all of the stuff that maybe AI
is a bit less good at the moment?
Domingo: that's a big question, huh?
Jonny: about seven questions.
Domingo: theâ¦
I, think the designers of the
future are all gonna be building.
Whether the things that they build
goes live to the user, it's unclear.
You might actually d-don't go live to the
user, But we are all gonna be prototyping
in the real material, It's just, it's
so much better to be able to join a
product review or a big presentation
and actually open the product yourself
and say, "This is what I think the
vision should be, and this is how we're
gonna help our users," versus showing
a Figma click-through that is gonna
be like, I don't know if that's true.
Is that possible?"
So it really helps designers sell the
vision of the things that they're trying
to accomplish across the organizations.
I think everybody sh- will probably beâ¦
become very comfortable with that
state, being able to just go in and
ship something to production because
AI tools are gonna be so good that they
can actually do that, or being able
to just work on vision pieces where
they can prototype the whole thing
and then give it to the engineers to
fr- to the engineers to, decode it.
Some things that I don't think
are gone, are gonna go away are,
I think designers are veryâ¦
One of the things I find myself
doing a lot is trying, going back
to traditional mediums, especially
now that I am using a lot of AI.
things like paper and pencil and,
trying to, just do some drawing on
paper and trying to think about, the
future and how things could work.
I think there is still gonna be a
benefit of designers, especially
understanding design, and, like, all
of the things that make design good,
all of the things that make UX good.
Those fundamental pieces of information,
they should, a designer should still
know them very deeply, in the same
way a engineer will know very deeply
when to use a database versus another
database, to code in a certain way for
it's safe versus another certain way.
Even if they're not coding, they
have that foundational knowledge
to be able to do their job better.
So I think that foundational
knowledge still gonna be
important for every discipline.
But when we are now going into the process
of, building, we're all gonna be a bit
closer to, the things that we're building.
It's not gonna be like, "Oh, I'm just
gonna pass this design over the fence."
It's gonna be, I did this yesterday,
which I said to an engineer,
"I think I can do that myself.
Why don't you let me design, build
and design that fix myself, and
then you can get on with the more
complicated pieces of the, work?"
And he was like, "Yeah, cool.
Do it."
And then obviously I used Claude,
and I, previewed it, and it worked.
And I tested it, and it got shipped.
But I think- Is we're all gonna be a bit
closer into that and, we all have to--
need to have that flexibility to be able
to, lean into each other's, positions.
I think the foundational knowledge
of, what is good design, what is the
right problem to solve, that should--
that sh- it shouldn't go away.
You should still understand this because
that's what gives you the critical
thinking to examine a prototype and be
like, I think that's not very good."
or,
and
Jonny: Are we talking about taste?
Domingo: ah, God.
The
Jonny: That was a, bit
Domingo: Yeah.
Jonny: but also,
Domingo: Yeah.
Yeah.
Jonny: think, everyone is trying to,
decide whether taste is important,
what taste even is, I wonder if what
you're describing a little bit is you
can't the hours of looking at stuff
and thinking about things and playing
with other products and building things
and them being not very good, and you
thinking, why is that not very good?"
you just need to go through the reps
enough to be able to build up what
Domingo: I like that
Jonny: instant gut on, I can look
at something and just know that it's
right or wrong, and I can reason why.
Domingo: I actually love
that way of putting it.
I might steal it.
This whole idea of, you just need to spend
time looking at things because I think
taste is-- There is engineering taste,
there is design taste, there is, strategy
taste, if you wanna call it taste.
if you talk to a principal engineer,
when they look at something,
they can immediately spot.
They, "Oh, I think that's not gonna
work," or, "I think that's gonna
give us a problem in the future."
and that is also a form of taste, in the
sense of, they know what they're talking
about because they've l- they've seen it.
And I think I like your framing, which
is we-- people need to use-- we all
need to develop that knowledge by going
through the process of shipping product,
of, trying or, and designing more and
designing new things and designing
multiple things and figuring it out.
So I like that a lot.
Yeah.
Jonny: One thing I have found when,
building-- when designing in code more,
with, with AI to support is there's a
set of edge cases or, failure states
and things like that are-- that a
software engineer is uniquely good at
knowing about that a designer finds it
hard to know about because they just
don't have the building experience.
They haven't built the thing, and then
the form needs, failure state or it,
it-- There needs-- There's some way in
which it can get messed up by some race
condition, and there needs to be s- The UI
needs to do something in that situation.
A designer doesn't know that because
they've not ever built it before.
And I feel like those kind of things,
that is now a superpower that designers
can have because you'll say to
Claude, "Build this form," and Claude
will be like, "I built the form,
but I also did all the other stuff
that you wouldn't have thought of."
so there's that-- that's amazing.
You read what Claude's built,
and you're like, "I wouldn't have
thought of half of those things."
But then at the same time, you look at
it, and you're like, "This is mental."
w- no one would enjoy using this at all
because there's way too many things in it.
And, it's, quite hard to just-- to pin
down exactly one stops and the other
starts, and one is much more about,
f- and, it's less-- it's harder to
quantify maybe, and the other one is
very practically like, "Here's how I
would write the test suite for this,
and I'm gonna make all the tests pass.
And, I have knowledge of all
the tests ever written, ever.
So I'm gonna write all the right tests,"
They're, two quite different things.
but it does feel as a designer,
you s- you get some stuff for free
straight away, even if some stuff
is, is-- AI's pretty useless at.
I did have one, one last question
then I'm gonna hand over to Tom 'cause
I've been asking loads of questions.
and I'm just curious, in this new world
that you describe, is Claude enough?
is Claude the tool that we end up
using as designers, like Claude
plus, local development server?
are we gonna go further with tools?
is there a tool that you wish
existed, for this kind of workflow?
Domingo: I, yeah, I don't thinkâ¦
Claude is what we're using right now.
I think it's gonna change.
we should al- be open to change as well.
so if, a new one comes
in, let's just use it.
I think the, m- I think models
are com- they're gonna converge.
I, in, in many ways I feel, like this
is getting, they're getting really good.
But one of the things I've been learning
a lot around is like when to useâ¦
And partly because I'm paying for my own
Mac subscription on the side, and I wanna
be, I wanna have some economy in the way
I'm using my tokens, co- token economy.
So I've been using things like
I'm gonna use Fable to plan, and
then I'm gonna use Sonnet or 4.0,
4.8,
like Opus to execute, and then I'm
gonna use Fable again at the be- at
the very end to just review as a,
principle, and then you start likeâ¦
I think that's gonna be very
interesting, like just playing
with models and you can see like
Sonnet is pretty good at executing.
so I think things will change.
The tools that I wish existed, which is
a problem that I find myself having all
the time, is I go through this whole
process of building things and like I
just build a bunch of designs and Iâ¦
it's already in production or like it's
in some pla-playground that I build and
I have an experimental build, and then
what I find myself going throughâ¦
I have this discussion on a weekly basis,
which is I talk to some of the designers,
I'm like, should we put this in Figma?"
And should we, sh-shâ¦"
and it's "Sh- should we do it?"
And, weâ¦
The thing about it and the, real problem
that we're missing is like Figma is really
good to sometimes put things on a page and
have a presentation and align, like align.
Let's align.
Let's align on this.
Let's add a couple of comments, align.
This is version one.
And then I think builds
and experimental builds and
prototypes are s- it's not good.
you still, you're like hunting
for the latest link or or you're
asking yourself, "Is that live?
Is it live?
Let me just go check it."
It is live.
It was shipped yesterday.
And you're like, "Oh, So I think I find
myself, like to-today after this call,
I have to go to Figma, and I have to map
something because it would be really good
for our team to align on like the state of
play, And I think nobody has cracked that.
Like they've, there isâ¦
Figma has this thing code to Figma
where you can do it automatically.
It's terrible.
It doesn't work.
It, doesn't, it's not true.
It does, it looks like an,
entirely different thing.
So s- designers end up taking
screenshots and putting them
in Figma and annotated them.
So it's just this kind of this
alignment tool, like this like
Jonny: Yeah
Domingo: coding infinite coding canvas
where things are code, but also you can
comment and you can align and you canâ¦
Basically, we are trying
Jonny: it's
Domingo: to replicate, yeah
Jonny: it's, slower than the actual
code base to, to put stuff into?
You actually then do have to wait
Domingo: Yeah, it's just a pain.
It's just--
Jonny: feet all the time.
Yeah
Domingo: Yeah, it's a pain, and
it's just oh my God, I, I-- Because
I do think, whiteboards are great.
you
having a whiteboard, running through
things, putting a sticker, and then
showing it to somebody and being like,
"Hey, I think this is what we should do."
that doesn't go away, and I
think we've tried to replicate
that with Figma, with Miro.
It works really well in those tools,
but I think now we're all, coding
and building prototypes, so we're
like, "Okay, but how do I take
these prototypes and align on them?"
So you have to take screenshots
of them, put them back into Figma,
and be like, "This is version one."
Or some of us, we don't even do that.
We're like, "Oh, let me just
show you my latest build."
But then wh- when you don't do
that, then you end up missing
the, "What was that version again?
What did we ship last week?"
Jonny: Yeah
Domingo: That's-- I wish
something like that existed,
Tom: when I saw the state of the, of what
you were working on back in February,
early this year, and specifically, you
walked through an example where you were
Claude Code to, basically audit your
code base to understand variations of
design patterns that have been used,
and you were using that as a way to
consolidate, the design system and the
sort of and, various things like this.
the team, and what you're doing now
with Surge Intelligence sounds like
step beyond that in terms of, almost
zooming design judgment out to apply to
a broader range of people and unifying
things across the wider business.
I'm curious how much of that you think
is a temporary problem, or a temporary
infrastructure that needs putting in
place, and in six months you'll move on
to something else, versus this being a two
or three-year that you think you'll face.
Do you have a sense of what that future
looks like for the shape of this role
and this type of infrastructure layer?
Domingo: I think it w- it willâ¦
Once we have things in place,
it will be-- There's gonna
be less time on it, for sure.
Which means that, Because a lot of the
work that we have to go through right
now, it's like we have to re-examine
some of those decisions and be like,
"Why do headers work this way?"
w-why is-- How should they be composed?
And we have to write them and, figure
out the best way to write them for
AI, so AI can do them without us.
So I think there's gonna be
a big lift to get it set up.
Then we're gonna see, like maybe less
time put on it, and it's just more of aâ¦
more about maintaining it, adding new
things, or, doing, big ch-shifts into,
maybe we're redesigning everything
again, and we need to do it again.
so it's gonna be less time, but I do
think that there is gonna be some form
of infrastructure team, like our 2X
team, like a builder's tool team, like
dedicated in every company to just fig-
ex- Because when I'm not doing that,
I'm exploring new tools and exploring
new ways to com- use AI for the team.
so the-- This is gonna be important
because I think the codebase keep
growing, new patterns keep getting added.
There is more use cases.
There is more complexity, so you have
to continually train the tools so
they kind of-- they understand how
to apply th- certain things better.
but yeah, it's not gonna be the big, the
biggest lift in the future because it's
gonna be like a normal thing that we do,
What I don't think is gonna happen is
that we're just not gonna leave it and
not touch it, which some teams do in, in,
like in the old school design systems.
You, build like a bunch of it, and then
you leave it, and then you kinda justâ¦
You let it die.
I think we're gonna con- continuously
work on, on, on, the, on this type
of infrastructure because it makes
AI better at coding, designing.
So why would you not want to make your
AI better at coding all the time, you can
help all your engineers, in one go without
even nee- without even-- without them even
knowing that you're get- helping them.
It's not like before where we have to
go and enforce it, and we have to say
to a team, "Hey, you should use this."
Now we-- It's happening because
Claude is already doing it, so
I think it's gonna be, likeâ¦
It makes sense to continue
to train these brains,
Tom: Yeah Got it.
So yeah, hearing you talk about it
like that is less of a ship goal of
establishing this infrastructure for how
you work and more of an outcome, which is
that you're optimizing for the design team
or accelerating design at Fin as much as
you can anyone who is shipping anything,
which
Domingo: Yeah.
Tom: designers and engineers right now.
Domingo: yeah.
And also, there is some PMs as well
using this kind of stuff to, prototype.
Some marketing people using
their stuff to prototype.
So I, justâ¦
I would quite a future where a designer--
because e- as much as you hire for them
and you talk to designers, sometimes
they put things on a page and they
start questioning comp- components.
They're like, "Maybe the
input fields should do this."
And you're like: But
why are you doing that?
you're wasting your time.
you're literally wasting your time.
And I wanna get it to a point where,
AI can just do all of that for them.
It can just be like, "This is the
optimal page for your use case."
And then their time is, "Okay, but what
is the use case that we haven't seen?"
Or, "Do we need to do a different
product entirely because
this doesn't work for this?"
And they canâ¦
All of those low-level decisions, it
could just be done for them, essentially.
I think this is gonna be different
for more creative disciplines like,
graphic design, like campaign design.
Those things will still need theâ¦
But, if you're just designing a flow
and there is an optimal way to design
a flow, do you really need to redesign
the flow every time you design the flow?
Or should AI just design the flow
for you, and then you can just
focus on, like, where is-- where
are people dropping off and why?
And, is this the right flow for
this, or should it be another one?
I don't know if that's a
good way to explain it.
but yeah.
Tom: Yeah, that makes sense.
Excellent.
Thank you so much, Domingo.
We will wrap up with a couple
of quick-fire questions.
have one picked out that I'm gonna ask.
we started recording, Domingo, you
mentioned about how you just moved
into a new house, and y- you were
talking about Vitsoe shelving, super
nice forever lasting shelving for the
house, which inspire this question.
I'm definitely leading,
you down that path.
That wasn't actually my intention.
It was more just to set context.
But anyway, the question it made
me think of is that, when AGI
takes over everything, and you no
longer need to design or be coding
things in for Fin, what will you
be doing with your free time?
Where will that energy go?
Domingo: I will be doing two things,
and this, it's just gonna sound the
most tech bro thing, the first one.
But the first one will be like, I'll
probably go be making fancy coffee
somewhere, and going very deep into
what is the right beans to choose.
and the second thing then, and that
I will probably be using is drawing.
So I-- You don't see it here, but I do,
like I have I have a whole easel here
that I have on the side of my desk.
So where I like, I can, I do
drawing, so I quite like it.
so either drawing, make- making
coffee, painting miniatures.
Yeah, stuff like that.
Yeah.
Tom: That
Jonny: Go ahead, man
Tom: very, yeah,
Domingo: sir.
Jonny: you don't subscribe to any
of the stereotypes of someone who
works in tech at all, Domingo?
Domingo: I know.
At all.
At all.
At all.
Yeah, it'sâ¦
Yeah.
Wow.
Tom: Love it
Jonny: the coffee nerd
arc is alive and well.
w- quick-fire question is m-maybe
more basic, but what is the product
that you look at that makes you
think, "I wish I'd designed that"?
Product you love to use.
It can
Domingo: This
Jonny: product,
You're not allowed to say
Vitsoe Shelves
Domingo: a physical product.
I'm not allowed to say Vitsoe Shelf.
That is tough.
there is a product that I keep coming back
to, and I tried to build this on my own as
well, but I just keep coming back to it.
it's called MyMind.
and I built a version of
it locally that it does it.
I've used all of the inspiration tool
version things that are in there,
but I just keep coming back for it
because it's just really simple,
really nice, really nicely designed.
It has really nice onboarding,
really nice interactions, and it
really, promotes, your spaces where
you can save your own inspiration.
It has, this, after you ser- reach
certain milestones on the things you're
saving, you get these, 3D cards or
achievements, and then they unlock
backgrounds, and it just really feels that
you have a s- a garden of inspiration.
I keep coming back to it.
I really like it, the product.
I think it's done by Tobias van Schneider,
which is, the ex-designer of Spotify.
And I think I've left it.
I tried to build it.
I could come back to it.
I really like it, and I think
it's really important for
designers to just save things.
Save, look at things, prune them.
when, in, six months, look at them
again and be like, "I actually don't
like this inspiration board anymore.
Let me just prune it."
Because that's a part of developing what
you like and what you don't, essentially.
Jonny: Yeah, I
Domingo: So Iâ¦
Jonny: were talking about earlier is like
they're the b- they're the reps, right?
that's the--
Domingo: Yeah.
Jonny: you're exercising your
judgment every day and building
it and changing it and yeah.
Domingo: Yep.
Yeah.
Jonny: my mind as well.
Domingo: Yeah, I use it a lot,
Jonny: building a bookmarking tool
Domingo: Yeah, I've tried and it just-- it
works, but it's just not it's not as cool.
yeah.
Jonny: yeah.
Domingo: so
Jonny: do it.
Tom: he'll do it well
Jonny: Yeah.
So are we done?
Should we wrap?
Tom: that's it.
Yeah.
Domingo: Try it
Tom: any final things you wanted
to mention that you didn't
have a chance to, Domingo?
Domingo: No, just thank
you so much for having me.
This has been great.
Jonny: where do we find you online?
Domingo: I am on X, and on LinkedIn, and
I have a website that I haven't updated
in a while, but mostly X and LinkedIn.
Yeah.
I will answer in those channels.
Yeah
Jonny: Awesome.
Thank you, Domingo.
Tom: Yeah,
Jonny: been fascinating
Domingo: Thank you so much, guys
Tom: If you have any feedback on the
podcast, good or bad, please drop us
a note at podcast@nearfuture.works.
We'd love to hear it.
Oh, and one final thing.
Last week, we announced a new
workshop we're opening up to
individuals to build your own
design tools on the 13th of August,
find out more and grab your spot
over at nearfuture.works/build.
Catch you next week.