Why I moved on from Figma
This is not an anti-Figma post. We need many tools and processes for the many designers and design challenges out there. This is a post describing why I no longer user Figma, and what process is more efficient for me.
My work is a particular flavor of UX and Design: I work in web development; I collaborate directly with engineers who work in 2 week sprints; we’re a non-profit; I could go on but this post would get boring.
For my flavor of UX and Design, I’ve found my most important work is communication. My role is to discover, gather, and analyze the many varied contributions and specifications from all of these contributors and generate output in a language that everyone understands. I also need my outputs to forward the conversation, and expand the audience, at each step.
Figma is an ambitious, and frankly cool software that does certain things really well. From my point of view it facilitates collaboration; standardizes language among the design team; produces a known and stable output; designers feel comfortable learning it and using it; and it makes project handoff tidier than previous tools. However, for my own particular role and objectives, the drawbacks of Figma outweighed the benefits.
Drawbacks
First, Figma produces an intermediate product that requires translation to become a website or app, and project handoff is baked into the process. The effort that designers pour into Figma is ultimately throw away work, and unnecessary handoffs are not an efficient use of our time.
Figma outputs also require mental translation to be understood by all parties. While everyone knows how to ‘read’ a website, not everyone can immediately read a mockup or understand the designer’s intent.
Coders who rely on assistive technology are blocked out of the process of translating from Figma to code. That is counter intuitive, even ridiculous, when we consider that our goal is a product that is born accessible.
Figma doesn’t directly contribute to the goal of rapidly iterating, testing, and improving increments of code. Figma is more aligned with waterfall processes that front load design. I am not anti-waterfall either, fyi; waterfall has an important place, just not in web development.
To iterate on the above, one implication is that front loading design fragments the processes of designing vs testing responsive and accessible layouts. Engineers are left holding the accessibility hot potato because… handoff. Designers should be deeply involved in the building and testing of accessible layouts and the project is weaker for that fragmentation.
Last but not least, Figma is a tool for visual design, and while it does not dictate a polished outcome, it certainly encourages it. Design is a powerful tool of persuasion. A good looking artifact too early in the process gains buy-in too quickly and kills discovery. In this sense, it is anti-iteration.
Alternate Process
What I do instead is work directly on functional prototypes. Some designers start to get pretty nervous at this point but bear with me. Code is not scary; as designers we have a long history of over emphasizing the difficulty of coding layouts. This is especially true with the advent of UI component libraries and CSS frameworks which make the process very easy.
I use Bootstrap, and what Bootstrap does for me is allow me to very rapidly create and iterate on functional prototypes. I work with HTML almost as a copy/paste exercise. It is not hard; in fact, it is so easy I often feel like a fraud, perhaps because my design training taught me that coding websites is both hard and someone else’s job. But I ignore that voice because prototyping in bootstrap at the level I need is very doable and accelerates our project goals.
Benefits
The biggest benefit is that a functional prototype speaks everyone’s language: engineers, designers, end users, everyone, we all understand web functions presented in a browser. It taps into mental models we all already share. And if the team is confused by the prototype, well, that is critical user feedback right away!
Working on a functional prototype mitigates handoff because the prototype IS the end product. Sure, at some point my coding ability hits a wall (pretty early on, if I do my job right) and then it is time for developers to dive in. The prototype makes that transition much easier. It acts as a living specification, clarifies intent in myriad ways, and is a single reference point for all parties.
Furthermore, no design can think of everything up front. Edge cases can be worked on by designers and engineers as they arise, and in the same prototype, without the need for more handoffs.
Responsiveness and accessibility can be tested in their native habitat with standard tools from the earliest stages of the project. Accessibility is not enforced as an afterthought due to designing in non-web native tools; instead it becomes a natural part of each stage of the project build. And if you are lucky enough to have an engineer on your team who relies on assistive technology, there is no delay to their involvement.
Because UX and design are contributing directly to a product that can be tested and iterated upon, goals for design output can align with engineering goals and technical requirements. Design and technical goals can be measured at the same cadence, building team cohesion.
Lastly, design can be iterated upon and be informed by the continuous user testing that this way of working empowers. The one constant we can rely on is that projects change and morph, which is what agile strives to embody for engineers. This method of functional prototyping embraces that reality for designers, too.
Conclusion
There are myriad flavors of UX and Design work and every team is different. As one example of what this process can look like, here is a recent case study I wrote. For myself, I can never go back to Figma-based workflows. Rapid functional prototyping makes UX and Design far too enjoyable and efficient for me to ever go back to a front-loaded, handoff-dependent way of working.