Figma - Worth the Hype? Absolutely - Clouded Judgement


A couple weeks ago Okta released their annual Business at Work report - a great review on how businesses got work done in 2020. As part of the report they highlighted which applications grew the fastest to support new working styles, particularly remote work. I received quite a few requests from folks to do deep dives on some of the companies mentioned in the report as most of them are private without as much public visibility. The chart below shows the fastest growing apps from 2020 in the Okta ecosystem. Today I’ll be talking about Figma - how the product works, what makes it special, and the opportunity in front of it.


Quick disclaimer - I’m not an investor in Figma (not now or in any previous roles), I’m simply an admiring bystander! With that as a quick background, let’s dive in.

In simple terms, Figma is a modern, collaborative design system. If you’re creating a website, an app, a piece of creative marketing content (or anything digital really), before you start coding / building, you need to design and iterate on that design. The design file (or vector editor as it’s appropriately called) in many ways is the blueprint that’s given to front end engineers. It’s a graphic representation of what will ultimately be coded up by an engineer. Let’s use the example of a mobile app. Ultimately product teams can’t just articulate to engineers what they want the app to “look like.” They have to give them a design! And Figma is the platform to create them. I’ve pulled an image from Google below that shows how designs are created in Figma:


There are many intricacies to design - There are simple aspects like where the header goes, what the background color is, etc. But there are also complex aspects to the design like what effect a button has when it’s pressed, how the app “transitions” when moving from one page to another, etc. It’s very important that all of these details are ironed out in the design so the engineering team knows exactly what to build.

Why Is This Important?

In today’s world, every company is becoming a software company, and elegant UIs and customer experiences are table stakes. As we’ve seen the rate of software development skyrocket, so too has the need for designers. If your product isn’t easy to use, visually appealing or intuitive it will be crushed by competition. Because of this, the need for designers has grown tremendously! Over the years we’ve seen this play out in the ratio of designers to developers. Dylan Field (the CEO of Figma) authored this article ~3.5 years ago that highlighted this trend. The image below (from the article) shows the number of engineers for every designer at varying companies. As this ratio decreases, the number of designers goes up. Companies are hiring more designers than ever before, and this trend has continued through 2021.


A few years ago it might have been easy to look at this market and say “there really aren’t that many designers in the world, this market is just too small to support a big company.” For reasons I’ll get into later (and for what I mentioned above), this has proved to be too simplistic of an assumption! As is generally the case, a cloud version of a previously non-cloud product often times greatly expands the market. Here’s a recent tweet that captures the market sizing sentiment:

What Makes Figma Special?

Before getting into what makes Figma so special, it’s important to understand how the world worked before Figma was around. I’ll go through the typical workflow of a designer (pre Figma) and highlight where challenges arise.

Desktop Vector Editor Applications: Limited Collaboration

The predominant vector editors on the market a few years back were Sketch and Adobe (with products like Photoshop, Illustrator, InDesign, and more recently AdobeXD). These were great, powerful products, but they weren’t collaborative or cloud based. They were desktop apps (Sketch now has a cloud product, but that is a newer development. And XD is Adobe’s recent cloud product). What does this mean? It was very difficult to collaborate. If I created a mobile app design and wanted a colleague to view it I’d save the file in some sort of file system (like Box) and tell my colleague “go grab the file Design v1” from the Box folder. Or maybe we didn’t even have a file system and I just emailed the file. My colleague would then open up Design v1, make some changes, save the new file as Design v2 and email me when it’s done. However, what if during that edit my colleague used a new font he had downloaded locally on his on computer? When I open up Design v2 instead of seeing text I might see something like “$%^@@#$$#%&.” I’d have to go back to him, ask which font he used, download it locally on my computer, and then get back to work. There’s an abundance of other similar issues (like color palates) that are incredibly difficult to manage with desktop based vector editors.

Version Control: A Nightmare

Another difficulty that originates from desktop app vector editors is version control. I hinted at this above, but maintaining a hierarchy of the most up to date version of any given design file is quite hard to do. Two people can’t be working on a file at the same time, and most people end up adopting a system of appending “v1, v2, v3,” etc to the end of file names to denote which version number is the most up to date. Here’s a few examples of where version control can turn into a massive headache. My colleague finishes up his work and tells me “the latest version is saved down in Box.” I hop into Box, and see v1, v2, and v3. The only logical assumption is v3 is the most up to date. I grab v3, spend 2 hours making edits, and go to save as v4. But wait! When I hit “save” I’m prompted with the message “v4 already exists, would you like to overwrite the changes?” I frantically email my colleague and ask her what version she “saved up to.” She tells me v4….. The latest file wasn’t synced up in time, and I grabbed an old version and made changes. There’s no way to merge my changes with her changes in the original v4. We now have to go back and start over…

Another example - My design team finally finishes up a design on a Friday afternoon. We name it vF (short for “final version”), send it off the the engineering team to build, and head out for the weekend. But wait! We quickly realized on one screen of the app we designed we put the “login” button on the top of the page. We forgot our initial instructions were to put the “login” button on the bottom of the page so we quickly change it, save as vFF, and email the engineer that there’s a new “final” version.” The engineer comes in on Monday, sees an email that says the design is done, quickly see’s vF in the Box folder and grabs that. Codes up the app, and only once he’s done realizes he used the wrong “final version.” This example was simple, an easy fix. There are far more severe issues of the “vF nightmare” that aren’t so easy to correct.

To solve this issue, companies like Abstract jumped in with a modern version control system. They’re an amazing company. They brought many of the same principles / syntax that software developers have with GitHub to design file management. Now the current “designer stack” stands as Sketch + Abstract.

Prototyping: Another Plugin?

Prototyping is another common workflow of designers. Prototyping involves creating different versions or flows of your end product (let’s say a website) before ultimately settling on the final design. Maybe you want to test a version of the website that has a link to the “Careers” page on the home page header. Or maybe you only want the home page header to show “Product, Pricing, Customer Testimonials, Resources.” In version 1 someone arriving to the home page can quickly click on “Careers.” In version 2 they first have to click on “Resources” and from that page they can click on “Careers.” You want to test two different versions of these “user flows” but you don’t want to code up two separate websites. Prototyping tools, like InVision, make it incredibly easy to create different visual prototypes.

Now the current designer stack is Sketch + Abstract + InVision. As you can tell, the number of tools are adding up…

The Design-Developer Handoff: You Want Me to Make What?

Once the design file is complete, it’s given to the engineer. They know exactly what to build, they have the blueprint in front of them. Easy, right? Wrong. The design file has all the basics, but none of the specifics. Here are a few examples. You might have an image on the website you designed that’s surrounded by a red border. How thick is that border? 1 pixel? 2 pixels? 10 pixels? And what exactly is the RGB (red, green, blue) values for that Red? Is the image centered, or are there specific X and Y coordinates on the page you want the image? If a user expands their browser does the image scale or stay the same size? There are so many details that sit behind the design that the engineer needs context on. To address this, the designer will either markup the design with these details, or they’ll sit down with the engineer to discuss (or there will be hundreds of back and forth slack messages). It’s a pain.

A new breed companies doing “design-to-developer” handoff emerged. Companies like Zeplin offered solutions to automatically markup designs and cut down time on the design-to-developer handoff. The designer stack now stands at Sketch + Abstract + InVision + Zeplin.

The “Sketch +” Model: Death by a Thousand Plugins

If you couldn’t already tell, the ecosystem of plugins to manage, and the different tools to switch between, was becoming unwieldly. And with the vector editors being desktop apps, managing the plugins was incredibly difficult. Every time one of the players in the the design stack would update to a newer version, all the plugins would break and have to be rebuilt. It was a constant battle of updating plugins, workflows breaking, plugins fixing. Rinse / repeat.

Design Systems: The Missing Link

Design systems are the final challenge of the old designer workflow. In order for a company to have a consistent brand across all customer touchpoints (web, mobile, etc), there needs to be a central repository of creative assets. Let’s use the simple example of a logo. Every company has a logo. But what happens when the company goes through a brand refresh, and that logo is updated. Where is the one place the designer can go to grab that logo? A single source of truth for all creative assets didn’t exist. And with the tools available, there was no place to put this single source of truth. There are thousands of other examples (outside of a logo) of design assets that should be stored in a central, source of truth, repository.

In summary, prior to Figma the challenges of designers workflow included: a lack of collaborative features with desktop apps, version control difficulties, design-to-developer context challenges, prototyping that lived in yet another tool, and a plethora of plugins that were impossible to manage.

Enter Figma: The Cloud-Native & Collaborative Design Platform

Figma was founded in 2012, but like some of the best businesses it took them a while to really get traction with customers. Why? The product is INCREDIBLY hard to build and it took time. I’m over simplifying, but the easiest way to think of what Figma did was take a vector editor and move it to the browser. Instead of opening up an app on your desktop, you instead went to a app in the browser. In many ways the simple analogy is Microsoft Word vs Google Docs. With Figma you have the ability to simply send a link of the design file to a colleague. Multiple people can be working in the file at the same time (and we can see each other’s mouse’s and edits in real time). Sound simple? It’s not. Design files are incredibly complex. They’re filled with high-resolution images, many different layers, renderings for different devices, operating systems and browsers. And all of this needs to be updated and rendered in real time, in high quality. In some ways a company like Figma couldn’t have existed before they did - browsers like Chrome simply weren’t powerful enough to support. And even when they did become powerful enough it took Figma years to get the product right. I like to compare designers to investment bankers (bear with me). Designers are creatures of habit - Sketch was a solution that dominated the industry, (and like excel) it had a plethora of keyboard shortcuts and functionalities that designers LIVED by. Very similar to excel - investment bankers LIVE by the shortcuts. Ask any banker and they will tell you they’ll be caught dead before using a Mac because the excel shortcuts are different vs a PC. And they’d never use google sheets as the functionality in excel is 100x greater.

Vector editors / designers are very similar to excel / bankers. Designers become extremely fluent in both the shortcuts and functionalities that exist in a tool like Sketch, and it’s really hard to get them to change. For a new entrant like Figma to have a chance they not only have to get on par with the functionality (this should not be understated, the vector editors are incredibly powerful), but they also have to represent all of this functionality in a browser (VERY difficult). This is why it took Figma years to get customer traction. But when they did, the floodgates opened. I’ll now get into the Figma product more to explain why.

We’ve already touched on the core aspect of the product - a cloud vector editor in the browser. But what else does this enable? In addition to the standard collaboration features (like commenting within the files, working more collaboratively as a team, etc), Figma has also built a number of the plugin features I talked about above (in the “designer stack”) directly into their product. Version control is built in natively. Prototyping is done directly in Figma. Within the editor you can toggle to a “code” view to make the design-to-developer handoff seamless. It really took a previous workflow that was Sketch + many plugins and made it: Figma. The seamless experience of having everything you need in one tool cannot be understated.

To top it all off, Figma introduced an elegant solution for Design Systems. A central, single source of truth repository for all creative assets. I’ve included a few screenshots below from their website that describe their Design Systems:


What Figma has built is truly special. Dylan (Figma’s CEO) had a vision that took years to execute, but he’s now built a cornerstone SaaS businesses. I also want to highlight that Sketch is also an amazing business. While their roots were more in the desktop app, they’ve elegantly transitioned to a cloud product and also have an amazing platform. Just about everything I mentioned above about Figma also applies to Sketch. The only difference is that Figma was born in the cloud, and Sketch transitioned to the cloud. I look forward to these two (and others) duking it out for years to come! The amazing thing about these cloud markets (as everyone has heard me preach about forever!) is that they’re almost always MUCH BIGGER than we originally anticipate. Both Figma AND Sketch can build big standalone public companies, and I have no doubt they will.