Tired of front-loading designs? Instead, this is what I do.
First of all, this is not an anti-figma post. We need multiple designers and multiple tools and processes for design challenges. This is a post describing why I no longer use Figma and which process has proven to be more efficient for me.
Figma is an ambitious and very cool software: it improves collaboration and makes project handoff easier than previous tools.
My job, like yours, is a special taste for UX and design: I work in web development; Our programming team works in 2-week agile sprints; We are a non-profit; And so on. For me in my current role, and despite its great features, I found Figma was building in inefficiency and contributing to misunderstandings on our team’s path towards a working product.
Below I share Figma’s drawbacks, an alternative workflow, and its benefits.
- With Figma, handoffs are baked in the process. As explained on their own website, Figma “can create responsive components that map closer to the code, making developer handoff more intuitive.” close to code having code is a long way off, and a more comfortable handoff Still a handoff. Just one example of this is the lack of breakpoints in Figma: any breakpoints you want to demo must be created by hand in Figma, and then recreated in code. Unnecessary handoff is not an efficient use of design time.
- Figma cannot contribute directly to our agile team goals of building, testing and improving by incremental product iterations for one simple reason: it generates a design artifact and does not contribute to the product.
- Everyone can understand a website, not so with mockups. Figma’s output also requires description and documentation with the intention of being understood by all parties, or we risk making an understanding loan.
- The Figma’s design is more aligned with front-loading waterfall procedures. I’m not anti-waterfall, it’s a good pattern when specifications are known up front and not likely to change… but it doesn’t describe any software project I’ve ever worked on.
- Programmers who rely on assistive technology are put out of the process until Figma is translated into code. Figma projects are birth inaccessible, the opposite of the direction we are working in. Figma’s accessible prototypes are in beta, but when AT BEST is complete they will still provide a very limited version of the accessibility already provided by HTML.
- Another consequence of silencing the design process is that programmers are left holding onto the accessibility hot potato. Designers must also be deeply involved in building and testing accessible layouts, and the project is vulnerable to fragmentation and testing from designing the product.
- In the end, Figma is a tool for visual design and, although it doesn’t dictate a polished result, it certainly encourages it. A good looking artifact that appears very early in the process deflects attention away from the requirements and usability and to the layout. Design is a powerful tool of persuasion, but achieving buy-in too quickly ends the search.
My alternative procedure is to work directly on functional prototypes written in HTML. Some designers seem very nervous at this point, but bear with me a little longer: as designers we have a long history of over-emphasizing the difficulty of coding, and we have all the time to make code accessible. There are more options too. There are nocode alternatives like Webflow or Quixi that may meet your needs. Or if you need full control there are many, many UI component libraries and CSS frameworks that make simple front end prototyping very easy.
On my team we use CSS/HTML frameworks and component libraries for rapid prototyping, and it almost becomes a copy/paste exercise. It’s not hard; In fact, it’s so simple that I often feel like a fraud, probably because my design training taught me that coding websites is both. Tough And someone else’s work, But I ignore that voice because it’s possible to prototype at the level I need, produces useful code, and accelerates our project goals.
- The biggest advantage is that a functional prototype speaks everyone’s language out of the box: engineers, designers, end users, everyone, we all understand web functions presented in browsers. It taps into the mental model we’ve already shared. As Teresa Torres urges us, we must constantly “imagine our thinking” “that is easy for others on your team to understand.” I don’t know of anything in HTML as easy to understand in a diverse group of people as a functional prototype.
- Working on a functional prototype minimizes handoffs because the prototype is the product. Sure, at some point my coding hits a wall (and often pretty quickly) and then it’s time for the developers to dive in. Prototype makes that transition a lot easier. It serves as a living specification, clarifies intent in myriad ways, and is a single reference point for all parties.
- Also, no one design can think of everything up front. As Raj Naggpan says, “The need to pivot based on feedback from working demos is not a far-fetched idea.” With a prototype, change requirements can be worked on by designers and engineers, and in a shared environment, without the need for additional handoff.
- Responsiveness and accessibility can be tested from the early stages of the project, in their original habitat, and with standard equipment. Accessibility is not an applicable consideration due to design in non-web native tools; Instead it becomes a natural part of each stage of project creation. And if you’re lucky enough to have an engineer on your team who relies on assistive technology themselves, there’s no delay in their participation. Unlike working at Figma, we can ensure that our product is accessible even at the very early stages.
- One constant we can count on is that projects change and transform, which is what agile programming strives to embody. With this process, the design can also be replicated, and informed by continuous user testing that empowers this way of working.
In my product team, front loading design has a lot of drawbacks. We have abandoned a Figma-based design process in favor of rapid prototyping in HTML/CSS using frameworks and UI libraries. Here’s a recent case study I wrote is just one example of what this process might look like. For me, iterative functional prototyping makes UX and design very pleasant and efficient to return to the front-loaded, handsoff-dependent way of working for me.