Figma for Enterprise Designers

Web-based design tool is "like a glimpse into the future," writes projekt202's Peter Vogt

By    Peter Vogt    Experience Designer projekt202

By Peter Vogt
Experience Designer

In the current landscape of design, we have a wide and ever-growing swath of tools to choose from. As Sketch has cemented itself as the primary UI/UX daily driver, competitors have emerged which push the envelope in their own respects. Figma is one such competitor. Founded in 2013 and launched in 2015, Figma has captured a non-trivial amount of product design marketshare – especially in the last year or so. Companies like Uber, AirBNB, and GitHub use Figma to power internal systems and collaborate across teams [1].

The marquee feature sets of Figma are its collaboration and extendibility features. This is due in large part to it being a primarily browser-based tool, but Figma does have a desktop app built mostly with Electron and some native code.

They declare themselves “the collaborative interface design tool,” and no wonder. Group design, developer hand-off, and prototyping are all core features that make Figma attractive to designers with many stakeholders. Figma is the only design tool to allow view-level operations on the entire platform, which can be built around by a well-documented API. As many designers move to Figma, I have spent some time examining it myself, and wondering how it could or would apply to my work with enterprise companies.

Web-based: The Good Parts  

Setup, Maintenance, Storage  

If you’re designing with Figma, the need for saving your document or running updates and restarting the software is all but eliminated. It is simply a web app that just works. Upon loading Figma, you’re presented with all of your work at the project level. These documents are saved in Figma’s cloud storage and are exportable as .fig files.

It’s no question that the efficiency is there, but it might be an adjustment moving to the browser for most designers. Fortunately, the desktop app for Mac and Windows, powered by mostly Electron, offers all of the same conveniences the browser version does.

The beauty of the browser app, however, is that it supports any operating system that has a web browser, so it doesn’t matter what kind of machine you as the designer have or your collaborators have. Contributors on MacOS, Windows and Linux all can design, view prototypes, receive redlines, or comment on Figma projects when using the browser app. With that in mind, that leads nicely into the next section.

Real-time Collaboration

One of the central tenets of Figma has always been the idea of bringing Google Docs-inspired collaborative features to the design process, and so much of this is due in large part to their web-based infrastructure. Below is a screenshot of a Microsoft acrylic materials file I found by Josh Goodwin. The author was able to design this, post a link to, and I am able to view the design’s layers, hand-off specs, and export assets right there from the browser tab. You can see my avatar denoted as “P,” with another designer viewing the file named “A.” 

This file is view-only since it’s intended to be a resource for the public to consume and export as they see fit, but if this were an internal document, we could configure the share link to be editable. And that’s where the magic for your team lies.

Imagine a world in which the very same document you’re doing all your design work can be shared with a link like Google Docs with configurable privacy. When shared, the link can be used to present prototypes for meetings, sent to developers for hand-off, and passed around for marketing/copywriters/creative directors to comment on. And if these stakeholders have some Figma chops themselves, they can edit the design in real-time for you - if you trust them.

I want to make sure this point is clear: the collaborative design features are really a “game-changer,” and I avoid using that expression because I think the meaning has been diluted. The ability for your fellow designers to make suggestions to your design work by opening the file on their computers and drawing the changes themselves – all without worrying about saving or file conflicts – is revolutionary, and all in the same shared link where PMs are annotating and developers are consuming redlines as you go, no less.


Figma’s API is vastly different than Sketch’s API. Extending the Sketch functionality keeps you largely still in the Sketch ecosystem. Practically speaking, this refers to plug-ins. Any sort of building you do on the Sketch API is tied directly to Sketch only – so you can build an automated asset exporter for Sketch, but everything you build is completely tied to that specific Sketch plug-in you’ve made.

Figma turns this notion on its head, by opening up access to its platform to almost anything that can interact with a web API – which is to say, most things that exist on the web. So, for instance, this TypeScript wrapper built by Jon Gold, a Design Technologist at AirBNB, allows you to build your own JavaScript integrations with Figma. If you can dream it and execute it with JavaScript, you can do it with Figma.

This sort of thing would be for what I’d consider advanced users, but it’s a glimpse into the very future of design tooling. More examples of API creations from the Figma community can be found here.

The subject matter in our industry that I am most interested in is the intersection of design and engineering. Does a world exist in which we are reliably designing in production-level code without being engineers ourselves? If it does, Figma will probably be the first to take us there, at least on the web, but the sky is the limit.

Covering Bases

With enterprise work, there is value in one tool or suite being able to host all or most of the relevant services for a team. Microsoft and Salesforce have built empires around this thinking. Currently, many of us use a workflow that looks something like:

  • Sketch (Low, medium, high-fidelity design work)

  • InVision (User and internal stakeholder prototyping)

  • Zeplin (Developer hand-off)

Figma offers all three of these things under one roof. The question then becomes, does it do these things just as well or better than each of its individual competitors?

There are currently no tools in Figma dedicated to animation, if that matters to you. I personally prefer Framer for any sort of Animation work, while others prefer Principle and Flinto. Using a plug-in like Anima’s Timeline brings these capabilities into Sketch.

For the other three parts of the workflow, first, let’s cover prototyping.


If you lean in to InVision for serious user testing, I would argue that Figma does not yet displace the robustness of features in InVision. Namely, the ability to do things like hover and add images as overlays. These sound small out of context, but without them, it’s more work to do things like display dropdowns or tooltips in a way that approximates a final software product. I think this is important because user testing with any sort of prototyping tool – InVision, Marvel, etc. – is hard enough to simulate the true essence of a very interactive piece of software as it is. I think there is something to be said for Figma’s prototyping having less features geared toward interactivity.

Another important thing: downloading local prototypes, as one can in InVision, is not possible in Figma. As a designer at projekt202, I can attest to the need of local prototypes when network connectivity is low or non-existent at an external site. You can, however, embed Figma in an iFrame.

If you’re simply looking to link up screens to show user flows internally, Figma will do the job handily. The transitions from screen to screen are editable (transition type and duration), swapping device sizes is as easy as selecting from a dropdown and letting your elements resize, and you are able to set overflow behaviors with scrolling.


If you currently use Zeplin, I would argue that Figma serves the hand-off portion of the design process more capably. It does everything that Zeplin does and does it in real-time as you update your design, thanks to the collaboration features that we’ve already touched on.

You don’t need to worry about exporting artboards and spending time organizing them in a separate application. Slicing exports and copying text from the design source is one-click easy. Your developers will see your design file as you see it. What’s more, Figma generates style values and layout code for CSS, Swift, and Android, as seen here: 

I can’t speak to how reliable the iOS- or Android-generated code is, as I’m not a mobile engineer. The CSS accurately portrays the design work but makes no assumptions about your production asset pipeline or file configuration (much like Zeplin). The measurement tools on layout appear to be as reliable and accurate as Zeplin’s.

This is a good opportunity to highlight one of the problems with modern design hand-off. Tools like Zeplin and Figma can’t know what technologies your development team are using yet. In practical terms, if your development team is using Flexbox or CSS grid primarily to define layouts, or if they have many CSS variables that are custom rolled in-house to define styles in production today, there is simply no way for tools which serve entire markets to account for that. There are simply too many different ways to build an app. Regardless of the tool, design hand-off will only ever get you 50-75% of the way there toward actual implementation on the view layer. I am curious to see if Figma’s platform API can fix this at some point, and I am aware of upcoming software like Phase that attempts to fix this sub-optimal part of the industry’s workflow.

In general, the only red-flag potential I see with Figma’s hand-off features are for teams with low agile maturity. If you are accustomed to having full, total control over what developers are consuming as redlines in one environment, Zeplin may serve that purpose better. Of course, you could simply maintain a “redlines” duplicate of your design file in Figma, and only share that to the development team as necessary.

Version Control – For Hand-off and Everything Else, Too

The version control capabilities that Zeplin has are baked into Figma by default and viewable to everyone. Clicking the file name will enable you to show version history on the right panel of the interface. You can add to the version history and annotate it, look back in time, and restore old versions, so there’s never a question of when things were changed or by whom. In the case of Figma, you’re versioning all your design work and not simply versioning the redlines contextually at the end of your design process.

And if a developer or PM needs to reference an old version in a meeting – or you, the designer, need to reference an old version in a meeting – it’s all right there in your source file or share link.

But what about the actual design tools? 

Overall Interface  

In my opinion, the interface of Figma is intuitive if you’re coming from Sketch or XD. Everything is largely in its expected place. Vector drawing, handling images, adding style attributes to layers, aligning and grids, working with type – it’s all pretty standard.

But there are some nuances to how Figma interprets your design intent. For one, Artboards, as we know them, are called “frames.” This is important because frames are able to be nested inside of what would traditionally be your highest parent layer, the Artboard. Think of it like an HTML page layout, if that’s helpful:

  • Body Container (Highest level Figma frame - in this case, set to iPhone X dimensions, for example)

  • Navigation bar div (Figma frame, a child of the body container frame)

  • Navigation link list (Layer group, a child of Navigation bar frame)

And so on. The reason for this, and why it matters, is because using frames in Figma is part and parcel to resizing constraints on the layers inside them. This is similar to AutoLayout features in Xcode and Resizing features in Sketch, but it’s baked into how Figma wants you to think of your design as you’re building. If you are expecting parts of your layout to be able to resize responsively in their own ways, you have to keep them in frames inside your top-level parent frame, which we normally would call an artboard, and adjust the resize settings accordingly for each. Figma moves your design thinking toward responsiveness from the outset. Layer groups which are not “framed” are simply for bundles of layers that do not need to respect any configured re-sizing.

Another type of nuance lives at the component level of your designs.

Components vs. Symbols

Symbols are called components in Figma, and that’s just where the differences begin. The left panel, which contains your layers, has a tab at the bottom you can switch to for easy perusal of all of your components, whether it’s local to your file or in a shared library connected to the file. Mercifully, you can search components by name, because the scrolling can become tedious quickly.

But the most differentiating factor of components in Figma is that they are editable directly on the layer itself, which means you don’t have to select overrides from a dropdown or edit the master symbol to change a component.

Instead, the master component is duplicated as an Instance in your working file. With this, you are able to edit the component instance directly, while the master component remains at the behest of the original settings you first configured, while the master version stays in the background. You are always able to revert an edited component instance with the “Revert Instance” button, which will blow away your overrides and conform your component instance to the master component’s configuration:

All the while, your changes to the master component will propagate through document-level component Instances in real time. If you make changes to a master component, your instances will update accordingly, save for the overrides that you’ve made on those specific instances.

On one side of the token, this seems like an infinitely powerful and efficient way to work with components in your design files. On the other side, I would not blame someone for being concerned that this defeats the purpose of having a very prescriptive design system/component library in the first place. This, of course, begets a conversation around how prescriptive your design system should truly be in the first place, but in the end, it’s about what level of balance works for your team.

Team Libraries - Shared, Focused Control of Your Design System

In handling these components, Figma has a solution that separates itself from your design system source file. Like housing them in an external repository, Figma holds your design system in a cloud-based “Team Library.” Managing it is as simple as creating a design system source file, finalizing a component, and clicking “Add to Library.” These components sync to the Team Library you’ve chosen and are available to anyone with access to use. Updating components is as simple as editing the source component file and publishing to the Team Library again.

The permissions for your team library, like almost everything in Figma, are granular, meaning that you can specify explicitly who is able to edit what parts of the file. This way, you can ensure that the designer in charge of illustrations and icons is the only one who is able to edit that part of the design system, for example.

Stylin’, Profilin’ Text

You can also share defined styles through your team library in Figma. Setting a text or layer style is as easy as it is in Sketch, but Figma handles text styles more impressively than the competition. Figma keeps your text styles organized by form (typeface/size/etc.), color, and alignment. Because of this, you have more specific control over your type. Creating and updating styles across your Team Library is as easy as publishing a component to a Team Library: click and confirm.

Web-based: The Not-so-good Parts

Document Load Time

Anecdotally, on communities like Spectrum and DesignerNews, most users I tend to see report a very high level of performance from Figma when working in a document, even going so far as to say it’s faster on average than Sketch. This may be true in most cases, but opening a large document and sometimes working in one still takes a considerable amount of time in my experience.

For one point of contact, I opened the source file for one of our projekt202 design systems in Figma. I used a stopwatch and clocked it at 1m 28s of time to open. This doesn’t sound long, but I promise you it is. I almost thought of posting a video of the file opening to further illustrate this point, but I’ll spare you. To be charitable to Figma, this file is a large file - 150MB - and it’s a Sketch file, which, by the way, ported with extreme precision. I don’t know what sort of engineering magic has to be spun up behind the scenes for Figma to be able to properly interpret all of those symbols exported from Sketch and produce a 1:1 version of the design system, and I don’t want to know. I tip my cap to their engineering team members, who are obviously brilliant. To ignore that slow of a load-time would be disingenuous to the spirit of this article. If you are dealing with files at scale, particularly legacy files designed in another format, Figma may cause problems for you.

Even after loading that large design system file, the performance was sluggish compared to Sketch. Dragging, nudging, typing – it all lagged. Would this be different if the file originated in Figma? Quite possibly. Based on the progress Figma has made since they first launched, I am willing to give them the benefit of the doubt that even if this weren’t the case, it eventually will be.

Network Dependency

Figma requires an active, stable internet connection. Fortunately, it does have active sync at all times, so if you lose connection, your work won’t disappear into the void. But even the desktop app is not a truly offline-capable app, and, in fact, it won’t start at all if it wasn’t open before your internet was disconnected.

This shouldn’t be a problem in 2018, but it is for many. I think there are a lot of enterprise designers who have unstable or firewalled connections that might make the jump to Figma very difficult. This also creates a barrier to entry for designers in countries with poor network infrastructure.

By default, your files are hosted in Figma’s cloud system. Are your enterprise clients or your enterprise higher-ups OK with this, contractually? I would hope so, but I have seen instances in my career where this would be a non-starter. Vendor and third-party tool auditing is a very real thing in the enterprise, and machiavellian restrictions on these sorts of things is not terribly rare. Many enterprise companies don’t take on any sort of liability risk they can avoid, no matter how small, especially with the increase in volume of high-profile data breaches over the last five years.


All in all, Figma is a brilliant design tool built by a forward-thinking team. When I’ve used it, it really does feel like a glimpse into the future. Your design team could reasonably cut costs by foregoing some external SaaS dependencies and rolling most or all of your workflow into Figma.

The connectivity of the open web platform opens up worlds that could not have been predicted a mere two or three years ago. By that same notion, the connectivity of Figma may make it a non-starter to some in the Enterprise. If you have doubts about corporate policy surrounding your in-house network, the reliability of your internet connection at work, or hesitate at the idea of working online only, Figma may not be for you.

For everyone else, I recommend signing up on the free plan to try it as soon as you can. We seem to be approaching the precipice of an existing way of thinking about design tools, and Figma is at the forefront.

Most importantly, even if Figma might not be right for the enterprise currently, progress would indicate that it will be soon. I suggest not letting them fly under your radar.

[1] As Design And Engineering Blur, Figma Wants To Be Their Platform – Fast Company, March 22, 2018

logo vertical.png

projekt202 is the leader in experience-driven software strategy, design and development. We have a unique and established methodology for understanding people in context — we reveal unmet needs — which drives everything we do. This leads to a crisp, clear understanding of the customer, which shapes the design and development of new solutions and experiences. We have the expertise, teams, skills and scale to deliver sophisticated software solutions that improve any and all touchpoints across the user journey.

projekt202 has spent over 15 years bringing to life and to market compelling experiences through our Experience Strategy & InsightUser ExperienceSoftware DevelopmentMarketing & Analytics, and Program Management practices. Our talented team has delivered emotionally-rich and intuitive solutions for global brands and clients such as 7-Eleven, Allstate, Canon, Capital One, Dell, McKesson, Mercedes-Benz Financial Services, Neiman Marcus, Samsung Electronics, Subway and The Container Store, among many others.

projekt202 has offices in AustinChicagoDallas and Seattle.