I've been thinking about semantic component naming conventions, specifically t-shirt sizing

We normally talk about this with variables – "what happens when you need something in between small and medium?"

I think it's a component issue too. Take this chip set with sizes Each size (base, small, large) is in itself an indication of...something. But what? Would a consuming designer know? I'm not confident

As a maintainer, I hope that the small size is used in specific scenarios, but nothing about "small" tells someone where that is

The more I talk to hiring managers and senior designers about what they are looking for in designers, the more I back up the theory that portfolios shouldn't be X, Y, Z case studies, but explorations of your obsession with details Showing deep, deep examinations of your solutions AND what you didn't deliver is a really great way to show how you approach solving a problem

A slideshow of solutions doesn't show anything below the surface, just a public-facing polished mockup

There's something bugging me about icons

Take a look at these two components, what's wrong? 10 points are on offer That's right! There are two problems:

1) The left padding is optically too large
2) The gap is too loose

Been asked a lot over the past few days about how to get started with colour variables, so here are some pointers 🖍️

Hope this is useful! As usual, before we get started here are some T&Cs:

• These are my opinions, take with a grain of salt!
• You will need more or less of these options, adjust to your team's workflow
• Tokens are opinionated, bring your microphone
• Tokens are angry, enter with care

I think it might be time to reconsider whether atomic design helps or hinders the creation of designs and systems

It’s been the de facto rule for looking at interfaces for a long time, but I find that sometimes it can actually create more confusion 💫 Atomic design is great! The issue we face though is that it’s best suited for frontend code architecture, and not necessarily within design files

It helped me understand the construction and component composability at a foundational level, buuut I want to flip the script a bit

Some more "styles in Figma" thoughts

Let's take a look at the four types of colour styles you might build / encounter in your systems 🎨

• Raw values e.g. #CC8700
• Base tokens e.g. Yellow/400
• Global tokens e.g. Warning/Primary
• Component tokens e.g. Alert/Warning/Text The last layer (component tokens) may be overkill for your needs, and you might not need to get that specific!

The "levels of abstraction" are down to how sophisticated your system might be, and you may not even need...any of the last three if you're okay with raw values😄

Here's another thread about managing Figma styles 🗂

It's pretty hard to know how far to push naming conventions on styles, and you can end up in some heavily nested folder structures if you're not careful

So let's take one component and work it out! As usual, these are thoughts / ideas!

There's not necessarily a perfect right answer, but hopefully this sets you up with something to think about 💡

When is one component actually many components?

I've seen a lot of cool component props examples recently, but I think we're running into a world where component maintenance is being prioritised over usage

Taking a tweet component as an example, how could we structure it? First things first, identify the component types

1️⃣ Tweet – single
2️⃣ Tweet – media
3️⃣ Tweet – threaded

Notes: Names are illustrative; media has many types and would require another thread in itself; there's probably more types!

Let’s talk about Figma design system libraries again, only this time...file names ✍️

What should we call the libraries?
And how is this impacted by their contents? I’ve used this before, but the starting point is always

“One file or many?”

This impacts naming conventions straight away

We spend a lot of time talking about component structure, but the library files themselves are often ignored

So what goes into structuring a good Figma component library?

Here are a few tips, hopefully a good starting point 📈 The first thing we want to decide is whether we use one file or many files

Both are fine! Single file is best for smaller projects, or when you're thrashing around at the start of a bigger system project

Separate files are best for collaboration, performance, and versioning

There are a lot of questions at the moment about colour tokens and Figma soooo

I thought I'd thread some thoughts on it to create a healthy discussion in public 🧂 Some assumptions first:

• This is *in Figma*, not talking about code
• You have a Figma design systems team set up
• You're at least splitting up styles and components into two files

During my office hours sessions, I get asked a lot about what skills are important for designers to learn to get "to the next level"

So thought I'd run a thread with some advice that I find myself given out consistently 📣 Visual polish

There's currently a problem in the hiring market with designers failing to demonstrate visual flair in their portfolios

This means an ability to show the artistic / finer details of your designs, but there are a few key things you can focus on to get better

Really happy to share a new best practice mega article 🕺

Over 6 thousand words, there's advice on:
• Structuring teams in Figma
• Structuring projects
• Structuring files
• Layers naming (yes!)

You might want to grab two coffees for this one 📚

figma.com/best-practices… For team structure, there are a few main approaches to align to:

1️⃣ By lines of business
2️⃣ By platforms
3️⃣ By initiatives
4️⃣ By pillars

I'm playing around with the idea of managing styles in Figma slightly differently

Let's take a look at:

• Styles as components
• Contextual, semantic styles
• Simulating "aliases"
• HSL colours

🔎 Before we get going, let's take a look at the components under the hood

I've set up a few "helper" components for styles:

1️⃣ Colour
2️⃣ Typography
3️⃣ Placeholder
4️⃣ Icons (will talk about this another time)

For a recent freelance job I used a lot of red lines for how components responded to screen sizes 🖊

The focus was mostly responsive behaviour (the developer was comfortable in Figma) but was happy with the result!

Will show an example here in the spirit of learning in public! Here's the full view of the two menus (pre and main) and broken down into sequences

To make it easier to digest, I always included assets (icons) alongside the component

Sections come in REALLY handy for grouping content ✨

I recently went through the iCloud upgrade process, and my systems brain was very confused by their usage of...buttons (of course)

🗣 Here’s an unsolicited analysis of those buttons because who doesn’t like talking about buttons? First things first, and the main reason I’m doing this, is because I thought “hang on, there are a lot of different styles being used here"

It turns out there are 6 variations

This might not actually be a problem, but it’s the variations within variations which caught my eye

Anyone interested in a little pop quiz?

It's about the most fun topic ever – "breaking changes" in components 🤓

Question 1️⃣!

Would you consider this a breaking change? We are changing the layer order Question 2️⃣!

What about this one, is it a breaking change?

We are consolidating the layers of the component, by placing all the existing menu items inside a new auto layout frame

Interviewing is really hard & asking the right questions is something we're all told to do, but I rarely see examples

Questions help clarify:

*️⃣ Design's value
*️⃣ Teamwork
*️⃣ Growth
*️⃣ Expectations
*️⃣ Risk
*️⃣ Business health
*️⃣ Impact

Here's a few for your back pocket 👖 Is design valued?

❓ Can you explain how the last major feature you shipped was chosen?

This helps clarify if there's a "product process", or if the CEO picks what you work on

❓ What's your approach to design debt?

Do the team clean up debt, accept it, or ignore it?

Just hit publish on another helper component resource 💡

This one is called "Helpers: Components and tokens" and allows you to indicate:

1️⃣ Component token/style values for documentation
or
2️⃣ Variant component sticker sheets in user flow files

figma.com/community/file… The style/tokens supported are:

• Color
• Font style
• Spacing
• Border radius
• Border style
• Effect style
• Code component name

There's also a "customisable" option in case you want to make your own

It's common during the handoff process to provide screens to our engineering teammates by "throwing designs over the fence"

We've all been there!

This puts pressure on devs to play a game of spot the difference, finding minor changes between screens 🔎

We can simplify this 📣 The red circles are the true differences, sooooo why are we duplicating *everything* from each screen?

This is inefficient from both sides:
– Designer must track identical screens, with changes doubled* every time there's a modification
– Developer is playing spot the difference

Component props can be hard to wrap your head around, so let's go step by step creating a variant set with nested icons and text properties!

Buckle up 🤠 Create styles and icons – Place these inside a frame called Icons. This will be useful later!

Then:
1. Create an instance of your icon
2. Resize it a few times (16, 24, 40)
3. Create a component set called "Icon wrapper"
4. Add “nested instance” & “preferred instances” props