Key takeaways from season 2 of Dive Club

As we go deep with all these talented designers like Dan Mall, Grace Walker, Fons Mans, etc...

I am learning a lot 🤯

So I wanted to pause and share 5 key takeaways from Season 2 of Deep Dives 🤿

#1 — Organizing variables in Figma

It’s pretty easy to go overboard with variables in Figma...

So my default advice for teams is to build the smallest possible system and not worry too much about architecting for a future that might not even happen.

But after talking with designer advocate, Luis Ouriach… I’ve realized there is one exception to that rule 👇

You should always organize your primitives and semantic variables in separate libraries (even if you don't know whether you're going to have multiple brands/products in the future).

This means you’ll have a primitives library with all of your color foundations… things like a purple-300 or a gray-500.

And then you’ll have a separate library, maybe your style guide, that’s going to contain all of your semantic variables (like a background-brand or a border-strong).

The alternative strategy is to have everything in one file and simply descope your primitive variables (by prefixing with a _ or hiding from publishing).

But I agree with Luis... this setup is fragile. And the cost of getting it wrong is significant 👇

"Splitting one file into two and piecing everything back together is going to be a really challenging project."

It’s not that much more work to organize your variables in separate libraries. And this way you avoid a potential major refactor down the road.

If you're a Figma nerd and want to learn more here's the clip of Luis talking about this strategy 🎧

#2 — Pricing strategies for your first-year freelancing

I’ve met freelancers who have whole portfolios of clients on retainer. It looks pretttttty nice to have that predictable monthly income.

But I had never considered why designers should avoid this payment structure in their first year of freelancing until I had my Deep Dive with Grace Walker 👇

Because in that first year, you should be trying to raise your price with each new client that you take on…

"For every project, I did I raised my price... particularly within that first year... once I had done a website for $3k I was like ok let's do one for $5k, $8k, $15k, etc..."

That's the only way you'll be able to find your price ceiling. If you're not hearing "no" from time to time then you're not charging enough.

That’s why Grace said one of the biggest pricing mistakes she made in that first year was taking on retainer clients…

Because the more she raised prices the more outdated that retainer became 🤦‍♂️ And having to go back to clients to explain the increase led to a lot of stress.

"The retainer work I was doing in my first year ended up being a blocker to me taking on more growth at higher rates"

If you want to go deeper, listen to Grace explain her pricing strategies for her first year of freelancing.

#3 — Approaching your design system like a product

If you’re creating a new software startup, are you going to go into hiding for a year and build this perfect product that’s fully fleshed out with all possible features your users might need??

No, of course not.

You'll ship an MVP and iterate your way to success from there.

Unfortunately, Dan Mall says he sees teams make this mistake too often 👇

"The biggest misstep I see with teams is when they start a design system they look at Material or Polaris and think they need to build something close to that before releasing it internally to their teams"

But if you follow a typical product process with your design system it might look something like this:

• Interviewing other designers before building

• Getting feedback on a small set of concepts

• Shipping a minimal viable system with a small set of components and seeing how it goes

This process is quite different than dedicating a week to building a full UI kit from scratch (guilty of doing this 😅)

This product mindset applies to the rest of the design system lifecycle too! Because the best products are always trying to eliminate feature bloat and trim fat whenever possible.

It works the same way for design systems 👇

"What a lot of mature teams are doing is removing components from their design system. They're analyzing the highest impact components they have and then supporting those components fully"

If you're into design systems and want to go deeper, then you'll love ​this part of my interview with Dan Mall​ 🤿

​

#4 — Rethinking your portfolio structure

Ever since my Deep Dive with Yuan Wang, I haven't stopped thinking about how we can improve the typical portfolio layout.

I wholeheartedly believe your home page should be your sizzle reel — a single place to tell your story and share all of your best UI, accomplishments, prototypes, etc.

Emphasizing case studies fragments our narrative.

We spend so much time writing project stories that we forget to craft our own story... but what if we started thinking of case studies as more of an appendix and not the primary way people consume our work?

Here's how Mansour transformed his portfolio after listening to the Deep Dive with Yuan (top is before / bottom is after) 👀

Here are a couple more examples of this format if you're looking for inspiration 👇 (send me yours!)

• ​Nenad's portfolio​

• ​Lukas's portfolio​

If you're interested in portfolio strategies then here's Yuan sharing how you can draw inspiration from 3D designers 👀

#5 — Ignoring everything except what the user sees

As the founding designer at Linear, everything Adrien Griveau ships is near perfection.

And yet... a lot of times this is what he's giving engineers 👇

"If I'm making a small improvement I'll just take a screenshot of the app and design on top of it. Because in the end, the only thing that matters is what the user sees... not how clean your Figma files are"

In my head, I know the only thing that matters is what's in production. But it's still so hard to fight the urge to keep Figma up to date and treat it like the source of truth.

Relying on screenshots stretches me in the best way. Because if it works for Linear then it can probably work for me too 😅

More than most people, I believe strategically using components can make you a much faster designer. There are whole lessons in Figma Academy about it.

But every once in a while it’s good for me to remember that the system is not the product. And the product is the only thing that matters.

"When you're at a startup, all the time you spend designing systems is time that could be spent improving the thing you already have”

Don't forget you can listen to this special episode below 👇