Oct 11, 2022

How to become your engineering team's favorite designer

Creator of Dive

In celebration of Figma Academy enrollment being open...

Here are 7 ways to improve how you collaborate with developers:

1) Share early and often

The easiest way to frustrate engineers is to show them a design late in the process that invalidates a decision they made early in the process.

The quicker you can share ideas (even if it’s just in writing), the more easily developers can chart their path forward.

I get it though… sharing unfinished ideas is scary. That’s why I’m a big fan of the phrase “something like this”. It implies that this concept isn’t perfect and you’re merely pushing forward the conversation in order to drive alignment 👇

2) Create collaboration opportunities

I make a practice of asking “what do you think?” as often as possible. Because I’ve never met a developer who simply wants to be told what to do instead of being involved in the product strategy process.

A nice tactic I use a lot is adding future conversation points as sticky notes 📋

In this example below I have an idea I’m interested in (using a student’s intro as a first DM) and all I’m asking is if we could have a quick huddle whenever it makes sense 👇

3) Embrace the box model

All frontends are built using boxes (or "divs"). Once we adopt the same mental models our designs become much more efficient to implement.

That means using frames instead of groups and I highly recommend leaning heavily into auto layout. Soon you'll start seeing CSS as you design :)

There are a lot of responsive design strategies around how to maintain a consistent layer structure at different breakpoints... but I'll save that for the full Figma Academy lesson video :)

4) Be consistent in your canvas and file structures

There are many ways to organize your files in Figma. Do I think some are better than others? Ya, I have a whole lesson about it... but the most important thing is that you pick one and stay consistent.

Consistency breeds familiarity.

I want developers to expect all of my high level flows to be in the same place (and for breakpoints to be organized the same way too). Similarly, all of my local components and relevant documentation should always live in the same page too 👇

5) Anticipate the questions developers want answered

I'll give you a few examples:

  • Does this have a max or min-width?

  • What is the copy for the error messaging?

  • Is this a fixed width or a percentage?

  • What is the empty state here?

  • What's the logic for when we show toast messages?

  • Which of these fields are required to submit?

The less you have to make engineers ask... the more they'll love working with you. I try to document answers to questions like these at the beginning of each flow 👇

6) Design around the worst-case scenarios

The example I like to give here is thinking about responsive design...

Sure your designs look great at 1280px, but what about 1025px right before things flip to tablet mode?

What layout decisions do engineers need to make to ensure things don't break down at the "ugliest" part of the breakpoint? Which elements have min-widths and which are fully responsive?

Sometimes I'll even show both the smallest and largest sizes within a single breakpoint 👇

7) Loom videos are your friend

I'm in the business of over-communicating... and sometimes the best way to explain your designs is to create a 1-2 min Loom walking someone through how things should work.

I attach these to my flows all the time!

Just make sure everything is still written down. Video should be supplementary not required for understanding.

See how I'm embedding a Loom video in my note component below?

I hope you enjoyed this little taste of Figma Academy :)

We go deeeeep into all of the ways you can improve collaboration with engineers (everything from structuring component props to communicating page transitions in our prototypes).

In celebration of Figma Academy enrollment being open...

Here are 7 ways to improve how you collaborate with developers:

1) Share early and often

The easiest way to frustrate engineers is to show them a design late in the process that invalidates a decision they made early in the process.

The quicker you can share ideas (even if it’s just in writing), the more easily developers can chart their path forward.

I get it though… sharing unfinished ideas is scary. That’s why I’m a big fan of the phrase “something like this”. It implies that this concept isn’t perfect and you’re merely pushing forward the conversation in order to drive alignment 👇

2) Create collaboration opportunities

I make a practice of asking “what do you think?” as often as possible. Because I’ve never met a developer who simply wants to be told what to do instead of being involved in the product strategy process.

A nice tactic I use a lot is adding future conversation points as sticky notes 📋

In this example below I have an idea I’m interested in (using a student’s intro as a first DM) and all I’m asking is if we could have a quick huddle whenever it makes sense 👇

3) Embrace the box model

All frontends are built using boxes (or "divs"). Once we adopt the same mental models our designs become much more efficient to implement.

That means using frames instead of groups and I highly recommend leaning heavily into auto layout. Soon you'll start seeing CSS as you design :)

There are a lot of responsive design strategies around how to maintain a consistent layer structure at different breakpoints... but I'll save that for the full Figma Academy lesson video :)

4) Be consistent in your canvas and file structures

There are many ways to organize your files in Figma. Do I think some are better than others? Ya, I have a whole lesson about it... but the most important thing is that you pick one and stay consistent.

Consistency breeds familiarity.

I want developers to expect all of my high level flows to be in the same place (and for breakpoints to be organized the same way too). Similarly, all of my local components and relevant documentation should always live in the same page too 👇

5) Anticipate the questions developers want answered

I'll give you a few examples:

  • Does this have a max or min-width?

  • What is the copy for the error messaging?

  • Is this a fixed width or a percentage?

  • What is the empty state here?

  • What's the logic for when we show toast messages?

  • Which of these fields are required to submit?

The less you have to make engineers ask... the more they'll love working with you. I try to document answers to questions like these at the beginning of each flow 👇

6) Design around the worst-case scenarios

The example I like to give here is thinking about responsive design...

Sure your designs look great at 1280px, but what about 1025px right before things flip to tablet mode?

What layout decisions do engineers need to make to ensure things don't break down at the "ugliest" part of the breakpoint? Which elements have min-widths and which are fully responsive?

Sometimes I'll even show both the smallest and largest sizes within a single breakpoint 👇

7) Loom videos are your friend

I'm in the business of over-communicating... and sometimes the best way to explain your designs is to create a 1-2 min Loom walking someone through how things should work.

I attach these to my flows all the time!

Just make sure everything is still written down. Video should be supplementary not required for understanding.

See how I'm embedding a Loom video in my note component below?

I hope you enjoyed this little taste of Figma Academy :)

We go deeeeep into all of the ways you can improve collaboration with engineers (everything from structuring component props to communicating page transitions in our prototypes).

In celebration of Figma Academy enrollment being open...

Here are 7 ways to improve how you collaborate with developers:

1) Share early and often

The easiest way to frustrate engineers is to show them a design late in the process that invalidates a decision they made early in the process.

The quicker you can share ideas (even if it’s just in writing), the more easily developers can chart their path forward.

I get it though… sharing unfinished ideas is scary. That’s why I’m a big fan of the phrase “something like this”. It implies that this concept isn’t perfect and you’re merely pushing forward the conversation in order to drive alignment 👇

2) Create collaboration opportunities

I make a practice of asking “what do you think?” as often as possible. Because I’ve never met a developer who simply wants to be told what to do instead of being involved in the product strategy process.

A nice tactic I use a lot is adding future conversation points as sticky notes 📋

In this example below I have an idea I’m interested in (using a student’s intro as a first DM) and all I’m asking is if we could have a quick huddle whenever it makes sense 👇

3) Embrace the box model

All frontends are built using boxes (or "divs"). Once we adopt the same mental models our designs become much more efficient to implement.

That means using frames instead of groups and I highly recommend leaning heavily into auto layout. Soon you'll start seeing CSS as you design :)

There are a lot of responsive design strategies around how to maintain a consistent layer structure at different breakpoints... but I'll save that for the full Figma Academy lesson video :)

4) Be consistent in your canvas and file structures

There are many ways to organize your files in Figma. Do I think some are better than others? Ya, I have a whole lesson about it... but the most important thing is that you pick one and stay consistent.

Consistency breeds familiarity.

I want developers to expect all of my high level flows to be in the same place (and for breakpoints to be organized the same way too). Similarly, all of my local components and relevant documentation should always live in the same page too 👇

5) Anticipate the questions developers want answered

I'll give you a few examples:

  • Does this have a max or min-width?

  • What is the copy for the error messaging?

  • Is this a fixed width or a percentage?

  • What is the empty state here?

  • What's the logic for when we show toast messages?

  • Which of these fields are required to submit?

The less you have to make engineers ask... the more they'll love working with you. I try to document answers to questions like these at the beginning of each flow 👇

6) Design around the worst-case scenarios

The example I like to give here is thinking about responsive design...

Sure your designs look great at 1280px, but what about 1025px right before things flip to tablet mode?

What layout decisions do engineers need to make to ensure things don't break down at the "ugliest" part of the breakpoint? Which elements have min-widths and which are fully responsive?

Sometimes I'll even show both the smallest and largest sizes within a single breakpoint 👇

7) Loom videos are your friend

I'm in the business of over-communicating... and sometimes the best way to explain your designs is to create a 1-2 min Loom walking someone through how things should work.

I attach these to my flows all the time!

Just make sure everything is still written down. Video should be supplementary not required for understanding.

See how I'm embedding a Loom video in my note component below?

I hope you enjoyed this little taste of Figma Academy :)

We go deeeeep into all of the ways you can improve collaboration with engineers (everything from structuring component props to communicating page transitions in our prototypes).

Join 10,000+ designers

Get our weekly breakdowns

"There's no doubt that Dive has made me a better designer"

@ned_ray

Join 10,000+ designers

Get our weekly breakdowns

"There's no doubt that Dive has made me a better designer"

@ned_ray

Join 10,000+ designers

Get our weekly breakdowns

"There's no doubt that Dive has made me a better designer"

@ned_ray

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watch”

Eugene Fedorenko

"

I've been binging Dive Club lately and the quality is nuts

Literally the only show about design I watch”

Eugene Fedorenko

hello@dive.club

Ⓒ Dive 2024