Five areas Figma need to improve on to stay a step ahead

All images by MidJourney, directed by the author.

It’s 2022. Figma has completely taken over the Product Design world over the last four years. It’s rare to see a company gain such rapid adoption across an entire industry so quickly.

With that kind of growth comes a lot of problems. The product accrues debt in different areas (both technical and UX) as a team tries to scale fast. Business and user pressures lead to certain areas of the product being prioritized and others falling below the line of what you have the capacity to focus on. A lot of aspects of a product also become a lot harder to fix at scale. These are all realities of product development that everyone should try to understand. I know this well from experience.

I don’t assume any solutions I suggest here are the right ones, and certainly not as easy or quick as an article like this may imply. This is simply an exercise in reflecting more deeply on my experiences with a product that I love and use daily and trying to identify the biggest pain points. The aim is to have a little bit of shared Figma community catharsis, but also to spark ideas within the Figma team or the community at large (hooray for plugins).

Disclaimer: I am friendly with many people on Figma’s team, have participated in a lot of user research sessions for them, and have guested on a Figma live stream. These suggestions come from a good place with the confidence that Figma‘s product team can and will continue to nail it.

Right. Let’s do this.

1. Design tokens

Design tokens are a simple concept with incredibly powerful capabilities if used effectively. If you’re unfamiliar with Design tokens, they are variables with unique names that are assigned simple values, and can be used in place of static values for colors, pixel values for spacing/sizing, fonts, etc. They are very similar to styles in Figma, but more granular and more powerful.

Currently, the only workable solution I’ve found to using design tokens in Figma is to use a 3rd party plugin such as Figma Tokens, Design Tokens or Themer. We use Themer at Onfido, but its issues are many, in both management and performance. Figma Tokens has quite a lot of traction and is much more powerful, but in my experience is kind of difficult to use, and designers need to really learn to use it for it to be viable for teams. Having to invoke a plugin UI when you want to apply color, spacing, radii, etc is a pain when Figma only allows one plugin to be visible at a time, and only in a floating window. It’s not ideal.

Here’s what I think Figma needs to do to make design tokens viable, powerful, and usable:

Support token usage everywhere

Every input that can take a numeric or text value, border radius, color, fill, opacity, X/Y, height, width, blur, letter spacing, font-face, etc should ALL be able to support using a token instead of a value.

Styles as token compositions.

Imagine a style applied to a frame that makes it look like a card and includes tokens for fill color, border width, border color, border radius, shadow color, blur, size, etc. Maybe you can then apply a card size style that sets the width, height, and auto-layout padding values. Each of these values could be overridden with other tokens or different values if required.

Support for aliases and math

(Please excuse my pseudo-code here)

Imagine you have an 8px grid system. You want to define a scale for spacing where spacing-4is equal to your base grid unit of 8px. Any number above this is a multiple of 8, and every number below that halves it (so spacing-6 = 24px, spacing-3 = 4px). Rather than specifying each token manually, you could do things like spacing-3 = {spacing-4} / 2 or spacing-6 = {spacing-4} * 3. Another capability might be adjusting specific properties with functions. Say you have a primary button background color such as bgPrimaryButton = hsl(237,91,59).
We could then specify a hover state with a slightly darker shade as bgPrimaryButtonHover = {bgPrimaryButton}.luminosity(-10). Hopefully, you can see how powerful this could be with multi-brand design systems. Changing a handful of base color values and having the rest of the system be based on these as you’d expect.

Configurable defaults

Imagine creating a new file, and your canvas color was a custom bgFigmaCanvas token that changed to a light or dark shade based on your Figma dark or light theme setting. For all teams, you could specify the default nudge settings to be your spacing token base values. When you create a new text layer, it automatically applies your primary text color and default body text size. For your iOS team, maybe you specify San Francisco as the default font, and Roboto for your Android team. This could take a lot of accidental inconsistency and guesswork out of design production.

Theme switching

Applying themes at a frame level, so dark and light mode designs can sit alongside each other easily. Have components be aware of their parent’s theme, and automatically apply the correct token values on variant change or component swap.

The Figma team has recently released Dark/Light mode switching in their own app. I have to assume they are now running into many of the same token/theme management issues that many of us have had for years. Maybe this area has become a higher priority for them internally as a result. We can hope.

2. Change management

Design systems are increasing in popularity (thanks in large part to Figma’s robust components). There are many improvements and enhancements to component capabilities: auto-layout, variants, variant properties, and interactive components. What’s still as difficult as ever, is adopting and rolling out changes to existing components and styles, in order to use these new capabilities.

The core of the problem is that if a breaking change needs to be made in a shared library, it’s a lot of manual effort for both designers and maintainers to successfully migrate to new versions of components smoothly and without breaking work in progress. Both parties have better ways to spend their time.

A few different things combined might be useful here.

Map variants from one component to another

Say you’ve made a structural change to a component like splitting Button into two components, Button and IconButton. The previous Button component had an icon-only variant toggle, but we want that to be a new component. The author should be able to specify that any component that is Button: IconOnly=True; State=Hover; should map to IconButton: State=Hover; after an update. The framework for this seems to be so close to right, with the swap library UI showing matched components or styles. This could be extended to allow the targets on the right to be manually selected, and a little more granular to include variants also. Being able to mark specific variants or components as deprecated/unsupported would be a necessary addition to this also.

Visualize changes before or after an update

When you click the “Review changes” button on the little popup in the corner, you get a list of what’s changed and some optional notes if the author included them. What you don’t get is any context about where those components are in your file, or whether their variant states or overrides will be retained after the update. There should ideally be a way to visualise what’s changed (maybe like the red boxes in Miro, or the Google docs “See new changes” feature) so that you can double-check everything looks OK in context. Even better would be a way to do this before committing to the change.

Tools to understand the impact of your changes in context

This could be inline analytics, maybe optionally showing the number of instances per component or variant. What I’d love to see though, is a way to easily jump to the context of a variety of instances in other files and preview my changes. In software engineering (using GIT), this is typically done by creating a branch, making your changes, and then testing locally before merging back to the main branch where your changes become visible to others. This is because a typical GIT branch is aware of the whole repository’s context at the time you branched, and not just an individual file, like Figma’s current branches do. This limitation (made to thoughtfully simplify branching I’m sure) I think robs branches of their power, particularly in testing.

3. Figma community

Community means a lot of things to different people. This one is based purely on my interpretation, and your mileage may vary a lot.

Figma’s community has always felt a bit splintered

The community at large feels incredibly engaged and passionate, and you can see this most clearly on Twitter, in the chat during Figma events such as Config or Schema, or on Slack/Discord.

For me, the part of the Figma community I most engaged with was the (now sadly defunct) Friends of Figma slack. The discussions there were engaging, useful, and interesting. Figma moved this community to Discord for logistical reasons, and I imagine it’s still active and thriving, but Discord is such a noisy, unstructured place that for me, it’s a lot worse for in-depth structured discussion, so I bounced off hard. Discord is simply not a place I want to be in a work context.

A content marketplace I’m browsing by myself

The Figma Community tab of the app features files, plugins, templates, and widgets available to discover, install, remix, or use. It doesn’t really integrate any of the aspects I love about the community I mentioned above though. It’s a different, disconnected thing. The people who contribute the content to this are actively engaged and generating a lot of value for Figma and its users, but this part of the tool isn’t where I connect with those creators. I still do that on Twitter, Slack, or Discord, and that’s the part that makes it feel like I’m part of a community.

There is no monetization layer yet (the change to “Try it now” buttons seems to imply one is coming though), which is odd for a marketplace. It’s always been a bit of a confused jumble of things that don’t quite fit together. Recently, there’s been some progress made on addressing some long-standing issues. Plugins and Widgets are now searchable in a context where you need them (outside of the community tab, in the file) and there’s been a big information architecture overhaul with new index pages and filtering options, but a few things still bug me.

Templates and files are still in one shared area, with no real differentiation. There are multiple ways of getting to the community tab within the app, and some of them break the expected navigation patterns in weird ways. Clicking on Community in the sidebar, removes the sidebar entirely, for example. You can also get to it from the account selection in the main toolbar, but you have to explicitly select which account you want to browse it with, and it changes the top bar completely when you do select it, hiding or moving things like which account it was you just selected.

Community needs a more coherent place in the app, or to be removed and live exclusively on the web.

Most day-to-day design work doesn’t make sense in a marketplace

The core users of Figma are designers. Often digital product designers, either in-house or working at agencies. I think people want to share stuff they’ve designed, get feedback, and improve. But I suspect the nature of NDA’s, and ownership of design work in agency situations doesn’t pair nicely with Figma files being shared in a way that’s transparent and remixable, meaning this kind of work doesn’t have a place in Figma’s current ecosystem. It still feels like Dribbble or Behance are the places for sharing work, but they also both have their share of issues that Figma could try to improve on if positioned smartly.

There’s also no place for any kind of article sharing or structured discussion, things the Slack community had in spades.

I have a lot fewer potential solutions for these problems. Community building is hard. But to summarize, I think Figma need to keep iterating on their concept of communities, possibly split their marketplace and community concepts, and try and build systems that feel like they support people communicating, interacting, sharing ideas as well as files, and learning from one another in a single place where people want to hang out.

4. Mental models and metadata

Figma is a tool primarily used in the context of working in teams

These teams usually have a multitude of processes and other tools involved in their day to day management of work. Things like requirements gathering, user research, scope refinement, ticketing and tracking of work, advanced prototyping, testing, etc. Figma’s not going to be the tool of choice for most of these things, but it should be able to integrate and work well with the tools and processes the team does use.

People try and fill some of these gaps with cover sheets, widgets, plugins, and a lot of manual effort. Our cover sheets include the ticket name and number, the designer responsible for the work, and the work status. We try and put processes in place for how to manage and structure source files, work in progress, archiving, and try to keep everything updated manually, and honestly it’s a huge hassle, that people only do effectively maybe 30% of the time.

Files could have a concept of configurable metadata fields that would enable teams to set things like work status, responsible designer, work ticket info, and have hooks to automate processes based on changes to these. Think a little sprinkling of Asana or Notion table functionality. My Figma file name should update if the ticket it’s linked to is updated. If a ticket is marked as complete elsewhere by an engineer, the Figma status should transition to completed, and be moved out of the work in progress folder to an archive.

Some core concepts also need reimagining

People have long been asking for simple folders. Now, folders may not be the best solution, I’ve worked in companies that have struggled with folder structures vs other, arguably better systems, but at the end of the day, folders fit into people’s mental models easily and flexibly. I think this ask often comes from a frustration that Figma’s capabilities don’t match our mental models.

A real world example: Right now, we have multiple teams at Onfido. One product might have multiple teams that are working on different aspects of that product. Some teams might be responsible for multiple smaller products. As a result, we have some products set up as Teams in Figma, and some teams set up as Teams at the same level.

Some of those teams then have the products they’re responsible for set up as Projects within Figma. Because we only have this layer of organization to work with within a Team, we create Projects that map to work status. So there might be a Work in progress project, an Archive project, and a Source files project. If the team is responsible for multiple products, you might have duplications of some of these projects per product.

Actual projects that the team works on (often structured as epics in other systems, but not always) are then set up as Files (not Projects , which are statuses or products or maybe something else entirely like Whiteboards). These Files then sometimes contain Pages for iterations or versions or prototypes.

You see the problem. I don’t think we’re an outlier here. I think the structure, naming, and capabilities need to better reflect the common processes that teams use and expect their tools to be able to reflect. Figma needs to be both more opinionated, and more flexible, to better accommodate common work processes.

5. Pricing

Figma’s pricing model has been a little perplexing for a while. It feels fine in some instances, unfair in others, and straight-up baffling in a few cases.

Figma is priced per editor per month, and as a customer you have a few different plans/tiers to choose from. A relatively normal SaaS subscription model.

However, it has a few quirks and issues:

Infrequent editors

Collaboration across disciplines is something we want to actively encourage, so we want our tools to encourage and enable it. The reality is true collaboration is often more than just commenting and feedback. Sometimes it’s having engineers, PMs, or stakeholders contribute in more meaningful ways. The best way to convey an idea might be through a quick text edit or a quick wireframe, but this also might only happen two or three times a month. Not worth a $45 a month for an editor license.

The current suggested workaround is to grant people edit access, then revoke that access before the billing date rolls around. This is a nice work-around for a small company using a fledgling tool who are still figuring out their pricing, but for a company that’s been around 10 years, it’s simply not good enough.

FigJam has tried to approach this problem with open periods of 24h where boards can be open to edit by non-editors, but I feel like a billing system that took into account lower usage would be much more scalable. It’s hugely appreciated that view and comment access is effectively free, but I'd much rather have a small but reasonable cost for these users if it avoided the inflated prices of editor and admin seats. Figjam costs are on top of Figma, but are incredibly reasonable. No issues with FigJam pricing here.

The pricing jumps between plans don’t reflect their relative value

The professional plan is $12 per month per user. To access the next set of features, which for most users only brings the value of company-wide libraries to enable design systems, and the most basic of branching tools, the price increases by a whopping 275%. The enterprise plan is 60% higher than that again (525% higher cost than professional per user) and brings almost zero benefits to the average user, as they are mostly administrative features.

At $45, the organization plan also gives you design system analytics, unified admin and billing across teams, and Single Sign-On support (often a requirement for orgs of this scale). The problem is these features are used by maybe 2 or 3 admins within your organization. They also don’t fill their user needs very well. SSO doesn’t let you set default roles, so everyone who joins your organization can automatically upgrade themselves to be an editor unless you as an admin change it manually. Anyone can create teams that the global admin has no visibility of, and can’t manage access to. Edit/view access for roles can’t be easily set globally and has to be micro-managed at a team level. These are issues that people paying a 275% premium expected to be ironed out and improved over time. But they weren’t. Well, they were fixed, but those improvements were bundled into the enterprise plan, which didn’t previously exist.

For an org admin at a company with 100 editors, fixing the pain points that affect only the admin will mean writing a business case for $36,000 extra budget per year, and that will scale with any extra editors added.

Collaborating with other teams should cost nothing

If you want to collaborate with someone outside your team (say you’re an agency that works with clients who also use Figma), then regardless of how much your clients are already paying Figma, they are counted as an additional editor on your account if you shared a file with them, and are charged at whatever rate you’re paying per editor.

This is absolutely ridiculous and leads to micro-management of user permissions in a way that actively discourages collaboration. Budget cycles don’t include projections on how many external designers you might collaborate with per quarter, and nor should they.

The fix here (from a customer perspective, with limited visibility on the constraints) is that collaboration between existing teams simply shouldn’t be double charged. If a file or team is shared with an email linked to an existing customer, their existing plan cost covers that usage. A charge can be incurred if it’s a new account, or the user is on a free plan. I’m sure it’s not that simple, but I’m also sure that it isn’t a problem that should be passed on to me, as a paying customer.

Existential threats

The elephant in the room is that a lot of the areas above aren’t actually existential threats; they’re iterative improvements to keep an existing user base happy and healthy. I don’t think there’s a chance that the industry will back-swing to an existing tool such as Sketch or Adobe XD. I think any existential threat to Figma’s growth and market share would more likely be a complete step-change. I’m thinking AI-assisted design, procedural design tools, or completely different interaction patterns, stuff that becomes very difficult for large companies to anticipate, take a huge risk, and self-disrupt before they’re disrupted.

Until that inevitably happens, I hope the Figma team continues to nurture a healthy respect for their core users and doesn’t ignore their evolving needs while chasing growth at all costs, as other tools like Invision arguably have.

If you want to let the Figma team know what direction you’d like to see them take, post ideas on the Figma Community Forums or the #figma-discussion channel on the Friends of Figma Discord.