Using camelCase for component properties in Figma

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

Messy beginnings

My first attempts were questionable.

Here, take a look at the property list of the sample 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 discern their meaning from their vague names. So occasionally, I’d call them a grammatically correct question.

And Component Properties (which came out 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 enthusiasm for Variants came from my 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 fully work. But I look back on his announcement as a major breakthrough.

And just as I was thinking about it, I realized that I could apply a developer’s naming convention to component properties. It would make my designs easier to translate into code, as well as address my naming dilemma. 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 every 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 this, people follow conforming naming conventions — such as camelCase.

Why camelCase?

Here’s how that 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. This way people can refer to them by the same name in both code and Figma which eliminates misunderstandings.

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, eliminating 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 on any separators between words.

Personal style guide

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

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”