Using camelCase for component properties in Figma

Since Figma introduced Variants, my work on design systems has become so much easier — both in the context of maintenance and adoption. Yet, when I first tried to use this feature, I was scratching my head. How should I name all the properties? Up until that point, I didn’t follow any particular naming convention. Would my lack of guidelines be enough to remain organized?

Messy beginnings

My initial attempts were questionable. To get what I mean, take a look at the property list of the example component.

It’s far from perfect.

Out of habit, I capitalized every word — unless I was in too much of a hurry to reach the SHIFT key. My consistency continued to go downhill with phrases and compound words. I couldn’t make up my mind about the punctuation rules either.

As much as I wanted to keep boolean properties short, sometimes it was too difficult to recall the meaning from their vague naming. So occasionally, I’d call them a grammatically correct question.

And Component Properties (that launched one and a half year after Variants) allowed me to change text strings and swap instances — meaning that one element could have multiple properties. How do I deal with that?! Apparently, with an awkward pair of parentheses.

There has to be a better way.

Rediscovering camelCase

Much of my hype about Variants came from an appreciation for Dylan Field’s (Figma CEO) recognition of how rewarding it is for designers and developers to share the same language when building components.

Yes, it’s been almost three years since that acknowledgement. We’re still missing a lot of advancements in our tools to make it work completely. But I look back at his announcement as a major breakthrough.

And just when I was thinking about that, I realized that I could apply a developers’ naming convention to component properties. It would make my designs easier to translate into code, as well as address my naming dilemmas. And that’s how I started using camelCase.

What’s camelCase?

camelCase is a way of writing a compound word or phrase without any spaces or punctuation. To make it readable, you capitalize each word — except of the first one (at least in the lowerCamelCase variant which I’m referring to).

Why is this naming convention common among developers? Most programming languages don’t allow spaces in identifiers (such as functions or variables), making them difficult to name with multiple words. To deal with that, people follow compliant naming conventions — like camelCase.

Why camelCase?

Here’s how that same component property list reads when I use camelCase.

Much better. But why is that?

As camelCase is a developer-friendly naming convention, they’re more likely to use identical names for the properties in code. If that happens, people can find and refer to them by the same name in both code and Figma. This eliminates misunderstandings, as you’re all pointing fingers at the same things.

It’s easy to stay consistent. No more capitalization or punctuation dilemmas; you can focus on the actual work. Plus, when the name is just one word, you can write it in lowercase, which means zero typing gymnastics.

Readability-wise, it’s good enough. Sure, five word names might be difficult to scan. But that’s not the case in most situations. And camelCase makes for short names because you don’t waste space for any separators between words.

Personal style guide

After using camelCase for component properties for the last two years, I defined a style guide. Mind that this is what I use for personal projects. When working with a team, I follow their naming convention — and only suggest camelCase if it solves a problem.

1. To name component properties, use lowerCamelCase.

2. For boolean properties, use “true” and “false” values.

3. Don’t use punctuation marks.

4. Use Arabic numerals to write numbers.

5. Don’t use emojis.

6. Treat abbreviations as words.

7. Avoid naming text layers “content”.

8. “Leading” and “trailing” instead of “left” and “right”.