I have beef with status emojis in component library Page names

It really grinds my gears that the best way to communicate the status of work in Figma is using emojis in Page names. I think this sucks. And I’ll detail why in a bit.

But I also admit that emojis in Page names is the best way to do it. And lots of people do it. My team does it. Figma’s team does it! If you didn’t know, Figma (company) designs Figma (product) using Figma (product). Check out this screenshot of Figma’s design system UI2, and look at the Page names. Green and yellow dots. I'm certain those represent the status of those Pages' contents:

Screen Shot 2022-11-16 at 11.14.39 AM.png
Screenshot of Figma's UI2 library with status emojis in the page names

Figma even mentions status emojis in Page names in their documentation on Pages!

Add visual clues to help collaborators identify appropriate work. Like "spacer" pages to create more distinction between pages or emojis to communicate purpose and status.

I should make it clear my beef lies solely with status emojis. I've got no problems with emojis that are static. The former tend to show up in component libraries. The latter tend to show up in local files. Static emojis job is to make wayfinding a bit easier. Here's an example of each:

Dynamic emojis in a component library’s pages:

  • ✅ Card
  • ✅ Accordion
  • 🚧 Button

Static emojis in a local file’s pages:

  • ✏️ Draft space & inspiration
  • 🔬 Related UX Research
  • 🍜 Prototype A
  • 🍜 Prototype B
  • 💻 Handoff specs

The first set of emojis are dynamic, fluid, and ever changing because component libraries are always in maintenance mode. Which means those green checkmarks should be understood as "stable" rather than "done" (component libraries are never actually done). These emojis ones are the problematic ones.

Contrast that with the emojis for the local file example: they are purely there as navigation symbols, related to the Page name and nothing more. They probably won't change. Unless someone decides they prefer spaghetti 🍝 over ramen 🍜 for their “prototype” pages.

Okay, now I'll cover the aforementioned list of grievances.

Here’s 3 reasons why I think status emojis in Figma page names suck:

<h2 id="reason-1">Figma isn’t a task management tool</h2>

Figma isn't a project or task management tool. Never has been, probably never will be.

That being said, the fact that folks with editor licenses can mark an object on a page as "ready for dev" tells us that Figma clearly recognizes there's a need for some process related features. There's two advantages this has over manually putting emojis in Page names:

  1. The Page gets automatically flagged as having "ready for dev" content on it, basically the same as using a ✅ emoji but even better because you can see exactly what content on that Page is "ready." You could manually build custom annotations to do the same thing, but that's more time and effort on your part.
  2. It simplifies your process. "Ready for dev" is a binary state. Either something is ready, or it's not. If you want to get really fancy, you may even be able to use Figma's API to send out notifications to stakeholders when something is marked "ready for dev"! I guess you could do that with emojis too, but leaning on Dev Mode feels more reliable than an emoji. Anyway, this binary nature means that the lack of a "ready for dev" marker can be understood as any other part of your process, like QA or review, in progress, launched, live, or published.

If you're on the free plan, or the binary nature of marking something "ready for dev" is too restrictive for your team, there's also plugins!

After I first published this post, Paavan recommended that I look at Andrei Iancu's Pagger plugin. You can use it to assign statuses to pages as tags. You can run the plugin 30 times for free before you need to buy a paid license. It's quite impressive, and directly addresses my beef with status emojis in Page names. The plugins' tags leave the Page name unaffected... but as far as I can tell, you can only see these when the plugin is open (they won't appear in the actual Page panel UI, just the Plugin UI).

Personally, I will probably not use this on my team for a whole host of reasons. I'll eventually write a post about why I'm so plugin-averse. But don't let that scare you off from it! If Pagger seems like it could help your teams workflow, absolutely check it out.

My point is that native Pages, as they exist today, are designed to name a collection of things. That's it. They let you enter a strings of text... manually. Pages are not "smart", they don't have an opinion about what they contain because they don't know what they contain! All that context has to come from you. Until/unless Figma introduces some AI thingamabob, Page names must be edited by hand. And this lack of opinion and awareness of Page content is a good thing. It requires you to think. And this nudges you to develop your own opinion on what makes a "good" Page name.

But for all that good thinking exercise, you are creating more work when you introduce status emojis. More clicks, more keystrokes, and most importantly, one more thing you and your team must remember to keep updated. This becomes meta work. Most people hate meta work. There are more valuable ways to spend your time and things to burn one of your brain’s memory chips on.

I think folks already know or feel this to some degree. But as much as we'd rather not update emojis in Page names, we still do it. It is undeniably valuable.

Duplicating information can create confusion

Very much related to number 1, but separate, is that you’re probably duplicating information that’s already stored in a much more appropriate place. Figma isn’t a project or task management tool... but Jira is. So is Asana, Trello, Monday, and ClickUp. And Airtable, Notion, and Coda can all be made into task trackers too. You are probably using one of these, or something verrry similar. And hopefully the work you’re doing on your component library is being tracked in whatever tool you’re using for tasks.

Those tools are much better homes for information about the status of work. It's what they're designed for. Not only do task management tools help answer questions like “is the <span class="figma-component">❖ Button</span> being worked on?”, but also “who is working on <span class="figma-component">❖ Button</span>?”, “what other work is blocking the work on <span class="figma-component">❖ Button</span>?”, “why are we updating <span class="figma-component">❖ Button</span> to begin with?”

And I am incredibly sympathetic to everyone who wants to bring that context directly into Figma. It’s where designers live most of their days. But when you copy/paste static information, you risk doing more harm than good. Not only is it more work to bring the information into Figma, but it can get out of sync.

Imagine a product manager trying to figure out if <span class="figma-component">❖ Button</span> is actually “in progress” (because that’s what Jira says), or if it’s still “blocked” (because there's a 🧱 emoji in Figma).

By the way, Jira people: Figma’s Jira plugin is a great bridge between the two tools. And if you use a different tool look around the community, you might find a plugin or widget for it!

<h2 id="reason-3">You end up needing to publish components that haven’t actually been edited</h2>

This is the big one, y'all. I spent a long time trying to solve this mystery.

Have you ever opened up a library’s “Publish” panel only to see there’s dozens of components that you never even touched?

You start to wonder “maybe someone else changed something...” so you look through the version history (which gives you weak clues, but clues nonetheless). You spend 15 minutes Slacking a team member trying to figure out what happened. But the investigation ends in shoulder shrugs for each of you. You don't really want to sink more time into figuring this out. You've got other work to do! So you start to feel pressured to just hit publish and be done with it. But you’re nervous. Nervous because you don’t really know why that component was marked as "modified" to begin with, and neither did your teammates. Nothing about it looks different!

Is the file haunted!???

No ghosts... but I'll tell you what: it was probably because someone changed the Page name.

What does that have to do with the components on that Page? Well, if you have multiple published components spread across multiple pages in your component library, then the Pages act as “folders” in the asset panel. And when the component’s “folder” changes, that means the component is technically impacted too.

Don't believe me? Here’s a demo video to prove it (which Luis Ouriach shared to his audience of 50K twitter followers):

This isn’t a big deal when the Page names goes from “🚧 Button” to “✅ Button”, because presumably some work has happened that needs to get published anyway. Not the end of the world.

But what if your library is set up so you have multiple components on a single Page? Something like “Icons.”

Well, the first problem is now your status emoji isn’t even doing its job very well. If the Page name gets updated with a construction-fence emoji to read “🚧 Icons”... how is anyone supposed to know which Icon is getting worked on? The answer is probably in your task management tool (*cough* where it belongs)!

The second problem is that even if you’re only working on the <span class="figma-component">❖ chevron-right</span> icon, every other component will be impacted when you change the Page name. So not only will you be publishing <span class="figma-component">❖ chevron-right</span> with good publication notes (and you are writing good publication notes, aren’t you?), you’ll also see that every other icon component is suddenly showing up in the publication panel too! Even though you never edited them.

Actually, I'm going to embed that Luis tweet I linked to earlier, because while he's addressing a different topic, it is very much related:

An advantage to divesting from the "one component per page" organizational schema means status emojis in Page names become kind of impossible to implement.

Imagine you organize your components by atomic level:

  • Atoms
  • Molecules
  • Organisms

I doubt you'd use status emojis on those Page names, because it'd be impossible to tell which components you were talking about!

Which brings us full-circle back to the <a href="#reason-1">first point</a> about using Dev Mode's "mark ready for dev" feature. If you do that, you get the little green "ready for dev" icon for free next to the Page name, but it will lead you to the specific object on that page that's actually ready.

<div class="horizontal-rule"></div>

Maybe you’re expecting me to have an alternative solution... if I did, this part of the blog post is where I’d talk about it. But alas. Pages are the best thing we have to communicate status of work in Figma. It’s the only chunk of Figma’s interface that 1) we can edit and manipulate and 2) is globally available no matter where you are in the file or what you have selected.

The best thing you can do is be aware of this reality.

Beyond that, you might consider being more thoughtful about the order of operations when publishing components. Instead of:

  1. Make edits to component
  2. Publish changes for that component
  3. Update the Page name emoji from 🚧 to ✅

you should flip 2 and 3. Treat the updated Page name as part of your component publication. And this goes for folks on plans with our without branching! If you do have branching, the only extra tip I can offer is to do your status emoji updates in the main branch. As of publishing this blog post, Figma doesn't do an awesome job in its diff-checker to call out Page name changes when you're reviewing a branch. I find it easier to:

  1. make my branch
  2. do what I need to do
  3. merge to main
  4. update status emojis Page name in the main branch
  5. publish the updates

And this isn’t to say we’re stuck with this! While I have no insight into what Figma works on, virtually every release I’ve seen shipped has been for the better. I trust this is on Figma's radar.

So until (unless?) Figma gives us something better than static text strings for Page names, the 3 points above are important to be aware of. None of them are major dealbreakers, but they are minor annoyances. And minor annoyances add up over time.

I hope this makes you feel you can approach Page naming and component publications with more confidence!

<h2 id="change-log">Change log</h2>

  • Current version
    Updated to account for the release of Dev Mode's "mark ready for dev" functionality, introduced as an open public beta on June 21, 2023 at Config
  • June 5, 2023
    Unknown changes, sorry!
  • May 29, 2023
    First publication