Thank you so much.
Hey, everyone.
I'm John Meguerian, and today, we're
going to be talking about designing for code.
So tiny bit about myself before we get started.
During the day, I'm a senior product designer
over at Squarespace and at work and outside of work.
I also call myself an occasional front-end developer
and make a lot of side projects in code
and use it to solve problems in my design work.
And when I'm not making rectangles appear on screen,
I'm super into cooking.
I love food and wine and restaurants, interior design,
sci-fi novels, and hiking, especially
if that hike winds up at a really great restaurant.
And I wanted to start today by telling a story that I think
would be super familiar to a lot of us in the design community.
And that is, let's say, you got really
into baking sourdough over the pandemic like a lot of us,
and you wanted to share that knowledge with other people.
So you put together this little learning management
app where you can learn how to bake an amazing loaf of bread.
So you've made these beautiful mockups.
You've sourced your images.
You did the art direction.
Everything's working the way you really love it.
It clicks through well, and so you send it over
to your development team at work.
And you think, great.
OK.
I really did my job.
And then you get a ping on Slack.
Hey, it's the button on the f screen the same as the one
on the lesson screen.
I can't tell.
Or hey, should the banner have a loading state?
These images are pretty big.
It's going to take a long time for them to download.
And then you get more messages and Jira tickets.
Hey, the padding in the lesson, does
that scale proportionally when we get below a certain screen
size, or is it fixed?
I can't tell.
Or hey, I noticed one font size of 16 pixels
in one font size of 17 pixels.
Is that intentional?
Or, hey.
Should we use only the spacing tokens from the design system
or is there something else we should do because I
saw this value over here.
And so, the situation you've gotten yourself in
is you're in this reactionary response mode
where you're fielding questions about certain parts of how
this thing works and behaves in real space
that people couldn't really understand from the mockup.
And what's happened is that you've treated your design
files as output.
And at the end of the day, a design mockup
isn't final output of you or your team.
Working software is software that your users can use.
And of design files are a communication tool
that's used in service of creating that real thing.
And so, I think that design files should mirror
how they will be implemented.
They should look more like the code base that will eventually
go and ship to users then like a representation
of the app and static screens.
So today, I'm going to talk about why
you might want to change your thinking
to be more in line this way, like how to do it,
a file structure that tends to work well for me.
When to do it, and equally as importantly when not to do it.
And then summarize and say, like so what?
What do you stand to gain by thinking this way?
So we're going to start with why,
and there are a couple of key benefits that you and your team
can realize if you start thinking more
along these lines.
Design is communication, not design is output.
And the first one is that you can
use shared language for things.
So your whole team can call one component or one element
or one screen the same thing from when
it's a baby on a whiteboard all the way through when
it's a react component in your finished application.
So if you look here, we have this lesson card
from my design file, about red.
And then, we also have this lesson card react component
and all of its children.
And they're called the same things,
and this is really, really helpful for communication,
for discussions for catching [INAUDIBLE] et
cetera, et cetera.
Likewise, once you have a name for a thing,
you also have a place for it.
So with Figma, this is completely supercharged
because everything lives on a URL.
But your engineer is your software developers
have one place to find all the details
when they're implementing a piece of your feature.
So here we have this little fake Jira ticket.
This is implement the lesson card.
And then in Figma, they can click on a URL
and see all of the behaviors, all the variants, all
the states, red lines, the components that make it up,
the motion guidelines, everything
they need to implement that piece in code
is all in one spot.
And you know the return to it.
And the same thing is true for other collaborators.
Some of you that work in bigger companies that
work on teams and organizations that
have content strategists and design systems teams
and visual designers of art directors and brand folks,
lawyers even.
They can all come into that same destination that
has the same name and contribute all in one spot
and contribute directly.
The designer doesn't have to be the conduit
for all of this feedback and all of these changes.
So in the visualization, you have
Chris from content strategy changing some language.
You have Samira from design systems,
updating a color to use a different color in the scale.
You have and an art director swapping out assets
and trying things out all in real-time
and all in one central place.
And then, for you, your mockups update automatically.
If you start thinking this way, you
realize benefits in your own process too.
What you're looking at here, I know
every designers have this happen to them
at some point in the past.
You change copying a button.
We're going to say watch video and not play.
And then you have to find that across every single screen
in your mockup and change it.
But if you build up the structure
in a way that mirrors how it works in software,
software is really good at stuff like variables
and automatic updating, so you're
realizing benefits for yourself and saving yourself time
in addition to unlocking benefits
for the rest of your team.
So we're going to talk about how to do this,
and you're probably thinking at this point like yeah, great.
Those sound awesome.
Give me the file structure.
I'm not Figma config.
I'm in the file track.
Show me the goods.
And I will, but before I do, I wanted to make this point.
And if there's one thing you walk away from after this talk,
it's this, which is talk to your team.
Have a conversation about this mindset.
Ask your engineers how they lay out their applications.
Ask your engineers what they name things.
Talk about how you lay out your files.
Talk about how you're thinking about where
component boundaries are, how this thing all fits together,
how it works.
Because if you share your knowledge and your expertise
and your way of thinking, you create a climate of trust,
and you create this situation where
if your files don't wind up looking like my files,
that's totally OK.
But wherever you end up, it's going
to be a way better spot than if you weren't
having these conversations.
So I'm going to show you one way to do it,
but the most important thing is to take this mindset
and have a conversation and see what
works for you and your team.
So the basic framework that I've found helpful
when working this way basically splits your design
file into three pages or major sections
as components views and then a prototype.
So we'll get into what each of those means how to do it.
The first is components, and these are essentially
the atomic building blocks of your feature.
And the general rule of thumb I use
is if it's not a design system component, for those of you
lucky enough to work on teams that have established design
systems.
If it's not a component of the design system,
it should be on this page.
It should be in its own frame, and it should be documented.
And the way you document it is to capture
its behavior and its anatomy and its variants and it states.
You don't red line.
This isn't redlining in the traditional sense
where you say this is 24 pixels from that
or this is 2/3 of that.
What you really want to capture is the stuff you can't measure
and the design tool like there's a flexible space here.
Or you should use the text subtitle component out
of the design system for this.
Or when you hover this transitions,
and it's this easing curve, and it should take this much time.
Or there's a hover state.
There's a focused state.
There's an active state.
It comes in rounded and square, to really using this page,
to capture all of those things that you
might need to know to then go wire this up in code.
You should be able to sit right here
and do all the work you need to do
to make that atomic unit complete in the code base.
And you might notice on this slide
that there is actually a little bit of code on the page.
And if you don't know it, that's totally OK.
This is why you have open dialogue with your engineers.
But the point is to try to specify as much as possible
how this thing behave rather than its exact distances
because Figma does that for you.
So again, do capture various states anatomy behavior
of the component, but don't redline what you can already
measure using sigma.
And then you take those components,
and you construct your views.
So what you're looking at here is every discrete screen
in this feature, and it's using real content.
And if you notice in the layer list over here,
it's using almost entirely these purple component instances.
So what you do is using all those components you've
made and documented, you stitch together
every major screen in your feature or your application.
And this is when you want to bring
in your content partners and your art directors
and your visual designers and your photographers.
And everybody who's going to collaborate
on making the content real, they come in at this level.
And so, what you do is you frame out every screen,
build it with the components and put in the real content
and make those main components as well.
So you're not two layers of component in.
And the beauty of this approach at this stage
is if you can't make a certain screen a certain view,
it works as a check on yourself.
So you know that you need to go back and make a component
that maybe you overlooked or maybe split something into two
because there's a variation of it.
You need it.
And you're doing this at the level of the design
before we've invested time and cycles as a whole team, kind
of making architecture choices and making comics.
And so, it's really nice self-reinforcing way
to make sure your design is complete at this phase.
So use your components from your components page to make this.
That's a huge part of it.
Absolutely use real content.
This is a great place to raise a flag and say, hey.
I don't have the copy for this, or I don't
know what this is going to say.
And remember things like empty states,
setting screens, et cetera.
This is the chance to really go complete and make sure you
have everything covered.
But what you're not doing here is
like putting mockups and device frames
or making like 30 duplicate screens
to capture hovers is in focus and stuff like that.
You already documented that on your components page
because they're going to be built in
are much richer and more expressive
medium, which is actually code.
And then finally, once you've done all this,
you get to your prototype.
And the top line here is that this should be really, really
easy at this point.
You've already done all the hard work--
making your components capturing their variance,
making all your views, putting in the content.
So really what you're doing here is just grabbing those view
components out of your file and stitching them together
into the happy path and any things
you're interested in for a user or things
you want to show off for a stakeholder review.
So this is where you put it all together
if you're working on a feature inside of a larger application.
This is where you add the context
of your main application probe and show where these features
existing inside of your app.
But the high level is that this is
the outcome of all the work you've done before,
not the bulk of your time as a designer.
So the two here are make this out of your views
and make all the happy paths reachable with prototyping
doodles, but don't prototype every hover click or error.
You captured that already in the components
because those behaviors are encoded
at the component level and the real application,
not at the screen level, again, at design file.
And some of the features that Figma ship recently,
like interactive components and component variants,
make this incredibly easy and incredibly powerful
because you'll get the interactivity and the rich--
the rich, expressive interactions
in this prototype with no additional work on your behalf.
So, in summary, build all your components.
Make sure they're well specified.
Build views out of those components
and all the real content you're going to use.
And then, at the end, you're going
to create a prototype that's self-updating and richly
interactive, very little work, and you
use that to show off and get feedback
from users and stakeholders.
So at this point, I've talked about this before with people,
and a lot of designers at this point are like, John.
This is so much work.
It's really restrictive.
This is like-- this framework is like really boxing me in.
How am I supposed to explore?
And that brings me to when to do this and when not to do this.
And the short answer is don't do this or explorations.
I'm not suggesting that to get an idea from your brain
onto paper, you need to think in this richly architected,
like designed to code mirroring thing.
No.
Your exploration should be pen and paper.
It should be in pig jam.
It should be on a whiteboard with your colleagues
hopefully soon when we get back to the office.
This is about documentation and getting ready for production.
It's about delivery because your design file is a communication
tool, so you're communicating with yourself
when you're exploring.
Sometimes if it's as-- if it's like a quick thing, an existing
pattern where you just needed to specify
how the screens go together, maybe you
don't need to go this hard.
But for new features, regenerative stuff
where no one's seen anything like this
before, you should always take the time once you've
got your explorations in and know what you're going to do,
you should always take the time to document your designs
and make sure they communicate as much as possible to the rest
of your team.
So what does this all mean?
Why should I care?
What benefits do I gain from this?
And I had to do this.
There's this gem, and it comes up all the time.
And you might be thinking at this point
like this is a lot of work, and it takes a certain mindset
to do this right.
Wouldn't it be better if the designer could just
make the components themselves.
Should designers code?
And whether or not you have an opinion on that, what
I would suggest is reframing this question
as should we understand the tools we're using on a team.
Should software engineers and content strategists,
and everyone else understand that the limits in the strength
of design tooling.
Should designers understand how their designs are
being implemented and the limits and strengths
of the application frameworks we use and actually
shipped to our users every day.
Again, if there's one thing that you take away from this talk,
it's have a conversation with your team about all this.
Share your knowledge about design.
Have them share their knowledge about architecting applications
or how they think about component
boundaries versus you.
Build trust with each other and with your mental models
and how you're thinking.
Because if you do, you wind up in this universe where
everything is so like take so little overhead to think about
and reason about and change.
So you're getting to a point where
the same layer name in Figma is the same component in react.
That's the same thing in the Jira ticket.
That's the same thing in the copy dock,
and you're living in this world where
it takes fewer mental cycles to really understand
what you're talking about and what's happening.
You can move faster and ship things faster,
and you're going to be more correct.
There's this notion that if it's in your design file,
it's this infallible truth.
It's supposed to be 17 pixels instead of 16.
But really, that's a bug.
You made a mistake, and it probably
should have been on your spacing scale of 16.
So if you can get to this level of dialogue in your team
and everyone trusts that they're on the same wavelength
and thinking the same way, you can feel confident
that people will realize that.
Or people won't feel bad about hitting you up and saying,
Hey, John.
This is supposed to be 16, not 17.
So this is a really powerful place
to be, and whether or not you implement this exact framework
or something else, having the conversation
and having the mindset is going to really, really benefit you,
your team, your organization.
So the thing I'll leave you with is for those of us
in the room who are designers, we pride ourselves
on being really user-centric and really having a process where
we interrogate the goals and needs
and pain points of the people we're designing for.
And what I would suggest is to apply that same rigor
to your design process.
You're creating these communications, these tools
to convey your vision to others.
And I would suggest putting the same amount of rigor
and critical thinking into how you're
doing that as you're putting into the actual features
you're designing for your end users of your company.
So really if we take a second, if we talk to our teams,
if we build shared knowledge and trust,
if we think about design as communication
and think about design as an analog of working software,
we can really design our design process
and that really benefits everyone in the long run.
So thank you so much for listening.
I put my Twitter handle on here.
I'm @jmegs.
I love talking about this stuff.
It's a huge passion of mine.
So if you do try this out or if you have thoughts or questions,
please hit me out.
I'd love to have a conversation about it,
and thank you again for listening.
Have a great Config.