Water is good, but what you really need to do is to get out of the desert…

With the announcement a few weeks back of Adobe’s intention to purchase Figma, shockwaves went through the design community. For every post of congratulations to the Figma team for having their years of hard work pay off, there were a dozen more lamenting what Adobe will do to their favorite tool.

The concern is understandable. After all, in addition to their aggressive monetization, Adobe has a history of killing off popular design products such as Director and Fireworks. So when people started preemptively mourning the death of their favorite tool, I was sympathetic.

At the same time, I realized that I was also a bit relieved. Maybe Figma had become too popular - not only for its own good but for the good of design overall.

Success and Excess

Let me start by being crystal clear: Figma has a been a fantastic product for design. It runs across platforms, it is easy to try for free, and it has been extremely powerful for bringing collaborators into the design process. Its components and design system support have made it easier than ever for designers to focus on reusable patterns and consistency. Its low barrier to entry has enabled many new designers to learn about design — especially those with limited financial means. And its collaboration features have raised the visibility of design and designers at many large companies.

As a designer and design manager who has decades of experience managing large and small design teams inside some of the most influential companies in the industry, I spend a significant percentage of my time explaining what designers do to non-designer partners in Engineering, Product, and executive leadership. Helping companies understand design, implement design processes, and realizing the tremendous ROI of design investment is my primary job.

Unfortunately, just by virtue of being popular, people have started to associate “what it means to do product design” with “what Figma does”. And more and more often I am seeing designers themselves fall into that trap.

Putting it in context

Figma is first and foremost a drawing tool. It is for making pictures, commenting on those pictures, and sharing them with people who might need to turn them from pictures into code. When we call it a “design tool”, we are feeding into the perception that product designers are just “people who draw stuff”. This is an incorrect impression that we have been fighting against for decades. We made some progress for a while, but the popularity of Figma both inside and outside of design teams has actually set us back.

In reality, very little of the design process is about producing pictures. That is the very last part of the design process. It is the part that requires the least skill and training on the part of designers and provides the least value for the product. So while Figma has made drawing much easier and higher quality, it has come at the expense of the rest of the process.

The double diamond

When we discuss design process, we often reference the double diamond model:

The Double Diamond for design process, from Wikipedia

In this model, the design process starts with a general problem statement. We then go through a discovery process to understand the problem, and refine that via scoping and prioritization into a focused problem definition — a set of requirements. Once we have that, we start exploring potential solutions, going broad at first, then refining those based on testing, feedback, and other sources of evidence until we have a design solution that meets all of the requirements.

So how does a tool like Figma facilitate this?

It doesn’t.

Work in Figma starts when this double-diamond ends. It is used after the “solution” phase, when we take that design solution and make it into a specification document for Engineering and other stakeholders to consume.

When we use Figma as the main tool for bringing collaborators into the design process, we risk excluding them from everything that happened BEFORE Figma. Or worse, we ourselves as designers start to think that what matters is delivering the Figma. When our partners come to us with a new problem for design to solve, the conversation immediately becomes “When can we see the Figma?”, instead of “when can we start discovery?” And rather than pushing back on this, we see ourselves jumping immediately into Figma.

An example

We have a product which has a complex set of permissions. Right now, we have the ability to assign those permissions to roles, and assign roles to users. So I can say things like “only an administrator can listen to voice mails”, and then I can make Dan an administrator.

Recently we had some large customers with many different locations or sites who wanted another layer of access. They wanted the ability to set permissions on a site level, so that — for example — a store manager could listen to all of the voicemail at their store, but not those at other stores.

The request came from our product team to “change the UI for assigning permissions to a role from an on/off checkbox to a three state radio button cluster for ‘off, site-level, global’”. The product person involved thought this would be a trivial change and was pushing for “the spec” ASAP.

Thanks to our use of Figma, our admin pages are readily available and highly componentized. It was extremely easy for our designer to find the radio button cluster in our design system library and replace the current checkbox in the settings component, which then flowed through to its instances on dozens of admin pages. Within a day or two after the request, the solution was ready for review.

So success, right? Just one problem — no design was actually done.

What was missing

In this case, the focus on “making a Figma” caused the entire design process to be bypassed.

In discovery, the goal is to understand the scope. At a minimum, this includes the complete list of “jobs to be done” (JTBD), as well as identifying potential threats for each of those jobs, possible delights, and technical constraints.

In the case above, the product person had come to us with a prescriptive design solution. We always reject such things, and start discovery by turning those into a JTBD. Something like:

As an admin, I want to be able to define site-level permissions to a role, instead of just org-wide permissions, so that I can control their level of access to sensitive information.

From there, we have a few standard explorations. For instance — what happens before and after this in the customer journey of the admin? What other personas might be affected? What are some of the possible risks or threats involved?

We quickly found out that what customers really wanted was the ability to define a collection of sites — say, for a region — and then be able to assign region-levels permissions to a role, not just an individual site. They also wanted the ability to audit and manage those regions. For instance, they wanted to be able to see everyone who had the ability to listen to emails at a specific location no matter what role might have granted them that ability. They wanted the ability add or remove a specific site from a region, and view existing analytics by region. Many of these capabilities were not previously in the product, and we had to not only design many new flows and even introduce new concepts, but also have the engineering team update data models and APIs to support them.

The role of Figma in short-circuiting design process

While it is true that this type of thing can happen whenever design is given incomplete requirements and a tight deadline, we have found that Figma exacerbates this. The collaborative nature of Figma — one of its best features — actually turns out to carry a lot of the blame. The desire to keep all of the conversations about a design in one place encourages a culture where the Figma document is the first artifact that is created. The whole team — designers included — rush from the initial problem directly to drawing solutions in Figma.

Figma’s easy of use can short-circuit the design process

Tool Monoculture

Even if Figma was not bypassing the process, it causes issues just by being such a popular drawing tool.

Every tool has a particular point of view on how you have to use it. Photoshop encourages you to think in terms of layers and masks and effects. Illustrator encourages thinking in terms of paths and fills. Unity thinks in terms of polygons, cameras, lights, and textures. I am more likely to think about animations and transitions if I am using AfterEffects than if I am using Visio. This is not limited to design tools, but any tool in any domain.

Figma has a very Figma-ish style. There are visual styles and interactions that are easy to do in Figma and others that are very difficult or impossible. When Figma becomes the dominant tool, everything starts to look like Figma. This has been going on for a while now. The current look really started with Sketch, and the Figma style is pretty much just a copy of that.

This has lead to 15 years of this style slowly dominating all UI work. At this point, we have designers coming out of design schools who have never used a different tool, and aren’t even aware of the limitations of that tool choice on their design solutions.

Moving from tool to toolbox

Ideally, designers should come up with a design solution first, and then choose the tool or set of tools that work best for that design solution. Just like an artist would choose between acrylic, water colors, pens, pencil, charcoal, markers, etc. for a project, we want designers to choose the best tool to deliver their result. That could include Figma, but it could also include Unity, Blender, Photoshop, AfterEffects, Houdini, etc.

For example — let’s say I had the requirement to “subtly let the user know when their storage is getting full without distracting them”. Using Figma, designers might focus on a solution like showing an icon by the storage icon— not particularly subtle. If I was using Photoshop, I might think of a gradient behind the storage icon slowly filling it. If I was using Unity, I might think about a spotlight of increasing intensity shining on the storage icon. It isn’t that these solutions are impossible to create in Figma. It is just that it doesn’t encourage the designer to think in that way.

Different tools inspire different solutions

Getting away from a single tool also makes it easier for designers to bring in other tools that are better able to support the discovery and design exploration that happen before we start on a spec. In discovery, sketching tools are used for rough concepts. We use spreadsheets and tools like Coda for managing JTBD and their related threats. Framer or Origami are great for interactive prototypes. The list goes on. Having more tools allows for a more complete exploration, which in turn results in a better design solution.

Design Collaboration post-Figma

Whether Figma thrives or dies under its new owner remains to be seen. But as designers, we should take advantage of this opportunity to refocus on the design process and take back territory that was unconsciously ceded to Figma.

We can start by focusing on richer collaboration tools, outside of the final design spec. Figma is just a document, so it is possible to share sketches, charts, and animations directly in Figma. On one of my teams, we have even been using Figma components to help us capture the stories, JTBD, threats, and delights that we find during the discovery process. These and other templates can help bake the more of the end-to-end design process into Figma.

Discovery templates in Figma

We use other tools as well. For instance, using the relational database capabilities of Coda allows us to quickly brainstorm and categorize JTBD and threats along with their concepts, and then we can automatically generate lists of threats that are in-scope, find all concepts used for a particular persona, and more.

Using Coda to capture JTBD, threats, etc.

We also need to remind designers that merely making some screens in Figma is not sufficient for a spec. The engineering team needs a lot of detail on things like keyboard navigation, responsive design, resizing rules, edge cases, error states, micro-animations, and other specifics. Merely drawing a picture isn’t going to convey this complexity. For example, in our whiteboard product, we were adding a shape for a callout. The designer initially just drew the callout as a shape in Figma and was going to hand it to the developer. But there is a tremendous amount of other detailed required to actually describe the shape and how it resizes. The real spec looked something like this (simplified example):

An example of a more detailed spec for a single simple whiteboard shape

With a variety of design assets, keeping track of them all comes with its own issues. It is easy for comments to end up all over the place — in meeting notes, Figma documents, Google drive files, shared videos, etc. Determining where comments are collected and where the master source of truth lies is something that every team must decide. Lately we have been using chat channels, such as in Slack or in our own Team Chat product, but you will need to find what works best for your team.

To conclude…

I love using Figma. It is really helpful to a design team. But we need to remember that it is just one tool for one phase of a design product. Good design requires a rich ecosystem of tools and techniques.