Published in Podcasts
Image credit by Uran Duo
Jorn van Dijk
CPO & Founder at Framer
July 1, 2022
Why I moved on from Figma?
Fed up with front-loading design? This is what I do instead.
First, 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 use Figma and what process has proved more efficient for me.
Figma is an ambitious—and pretty cool—piece of software: it improves collaboration and makes project handoff tidier than previous tools.
My work, like yours, is a particular flavor of UX and Design: I work in web development; Our programming team works in 2-week agile sprints; we’re a non-profit; and so on. For me in my current role, and despite its cool features, I found that Figma was building in inefficiencies and contributing to misunderstandings on our team’s path towards a working product.
Below I share the drawbacks of Figma we ran into, an alternative workflow, and it’s benefits.
Drawbacks
With Figma, handoff is baked into the process. As described on their own website, Figma can “create responsive components that map closer to code, making developer handoff more seamless.” Closer to code is a long ways from being code, and a more seamless handoff is still a handoff. Just one example of this is Figma’s lack of breakpoints: any breakpoints you want to demo must be build by hand in Figma, and then redone in code. Unnecessary handoffs are not an efficient use of design time.
Figma can’t directly contribute to our agile team goals of building, testing, and improving by incremental product iterations for a simple reason: it generates a design artifact and doesn’t contribute to the product itself.
Everyone can understand a website, not so with a mockup. Figma’s outputs also require accompanying descriptions and documentation of intent to be understood by all parties, or we risk creating comprehension debt.
Figma’s front-loading of design is more aligned with waterfall processes. I am not anti-waterfall, it is a great pattern when specifications are known up front and change is unlikely… but that does not describe any software project I have ever worked on.
Programmers who rely on assistive technology are blocked out of the process until Figma has been translated to code. Figma projects are born inaccessible, the opposite of what we are working towards. Figma’s accessible prototypes are in beta, but even when completed AT BEST they will deliver a very limited version of the accessibility that HTML already offers.
Another consequence of siloing the design process is that programmers are left holding the accessibility hot potato. Designers should be deeply involved in the building and testing of accessible layouts, too, and the project is weaker for fragmenting building and testing a product from designing it.
Lastly, Figma is a tool for visual design and, while it does not dictate a polished outcome, it certainly encourages it. A good-looking artifact too early in the process shifts attention away from requirements and usability and towards layout. Design is a powerful tool of persuasion, but achieving buy-in too quickly kills discovery.
An alternative
My alternative process is to work directly on functional prototypes written in HTML. Some designers start to get pretty 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 also have more options all the time to make code accessible. There are nocode options 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 much easier.
On my team we use CSS/HTML frameworks and component libraries for rapid prototyping, and it almost becomes 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 at the level I need is doable, produces useful code, and accelerates our project goals.
Benefits
The biggest benefit 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 a browser. It taps into mental models we already share. As Teresa Torres urges us, we should continually “visualize our thinking” in ways “that are easy for other people on your team to understand.” I know of nothing as easy to understand across a diverse group of people as a functional prototype in HTML.
Working on a functional prototype mitigates handoff because the prototype IS the product. Sure, at some point my coding hits a wall (and often pretty quickly) 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. As Raj Naggapan puts it, “The necessity to pivot based on feedback from a working demo is not a far fetched idea.” With a prototype, change requirements can be worked on by designers and engineers as they arise, and in a shared environment, without the need for additional handoffs.
Responsiveness and accessibility can be tested in their native habitat, and with standard tools, from the earliest stages of the project. Accessibility is not an enforced 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 themselves, there is no delay to their involvement. Unlike when working in Figma, we can ensure our product is born accessible, even in very early stages.
The one constant we can rely on is that projects change and morph, which is what agile strives to embody for programming. With this process, design can be iterated upon too, and be informed by the continuous user testing that this way of working empowers.
Conclusion
On my product team, front loading design has too many drawbacks. We have dropped a Figma-based design process in favor of rapid prototyping in HTML/CSS using frameworks and UI libraries. Here is a recent case study I wrote, just one example of what this process can look like. For myself, iterative functional prototyping makes UX and design far too enjoyable and efficient for me to return to a front-loaded, handoff-dependent way of working.
This article originally written by Shamsi Brinn and published on Medium
First, 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 use Figma and what process has proved more efficient for me.
Figma is an ambitious—and pretty cool—piece of software: it improves collaboration and makes project handoff tidier than previous tools.
My work, like yours, is a particular flavor of UX and Design: I work in web development; Our programming team works in 2-week agile sprints; we’re a non-profit; and so on. For me in my current role, and despite its cool features, I found that Figma was building in inefficiencies and contributing to misunderstandings on our team’s path towards a working product.
Below I share the drawbacks of Figma we ran into, an alternative workflow, and it’s benefits.
Drawbacks
With Figma, handoff is baked into the process. As described on their own website, Figma can “create responsive components that map closer to code, making developer handoff more seamless.” Closer to code is a long ways from being code, and a more seamless handoff is still a handoff. Just one example of this is Figma’s lack of breakpoints: any breakpoints you want to demo must be build by hand in Figma, and then redone in code. Unnecessary handoffs are not an efficient use of design time.
Figma can’t directly contribute to our agile team goals of building, testing, and improving by incremental product iterations for a simple reason: it generates a design artifact and doesn’t contribute to the product itself.
Everyone can understand a website, not so with a mockup. Figma’s outputs also require accompanying descriptions and documentation of intent to be understood by all parties, or we risk creating comprehension debt.
Figma’s front-loading of design is more aligned with waterfall processes. I am not anti-waterfall, it is a great pattern when specifications are known up front and change is unlikely… but that does not describe any software project I have ever worked on.
Programmers who rely on assistive technology are blocked out of the process until Figma has been translated to code. Figma projects are born inaccessible, the opposite of what we are working towards. Figma’s accessible prototypes are in beta, but even when completed AT BEST they will deliver a very limited version of the accessibility that HTML already offers.
Another consequence of siloing the design process is that programmers are left holding the accessibility hot potato. Designers should be deeply involved in the building and testing of accessible layouts, too, and the project is weaker for fragmenting building and testing a product from designing it.
Lastly, Figma is a tool for visual design and, while it does not dictate a polished outcome, it certainly encourages it. A good-looking artifact too early in the process shifts attention away from requirements and usability and towards layout. Design is a powerful tool of persuasion, but achieving buy-in too quickly kills discovery.
An alternative
My alternative process is to work directly on functional prototypes written in HTML. Some designers start to get pretty 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 also have more options all the time to make code accessible. There are nocode options 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 much easier.
On my team we use CSS/HTML frameworks and component libraries for rapid prototyping, and it almost becomes 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 at the level I need is doable, produces useful code, and accelerates our project goals.
Benefits
The biggest benefit 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 a browser. It taps into mental models we already share. As Teresa Torres urges us, we should continually “visualize our thinking” in ways “that are easy for other people on your team to understand.” I know of nothing as easy to understand across a diverse group of people as a functional prototype in HTML.
Working on a functional prototype mitigates handoff because the prototype IS the product. Sure, at some point my coding hits a wall (and often pretty quickly) 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. As Raj Naggapan puts it, “The necessity to pivot based on feedback from a working demo is not a far fetched idea.” With a prototype, change requirements can be worked on by designers and engineers as they arise, and in a shared environment, without the need for additional handoffs.
Responsiveness and accessibility can be tested in their native habitat, and with standard tools, from the earliest stages of the project. Accessibility is not an enforced 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 themselves, there is no delay to their involvement. Unlike when working in Figma, we can ensure our product is born accessible, even in very early stages.
The one constant we can rely on is that projects change and morph, which is what agile strives to embody for programming. With this process, design can be iterated upon too, and be informed by the continuous user testing that this way of working empowers.
Conclusion
On my product team, front loading design has too many drawbacks. We have dropped a Figma-based design process in favor of rapid prototyping in HTML/CSS using frameworks and UI libraries. Here is a recent case study I wrote, just one example of what this process can look like. For myself, iterative functional prototyping makes UX and design far too enjoyable and efficient for me to return to a front-loaded, handoff-dependent way of working.
This article originally written by Shamsi Brinn and published on Medium
First, 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 use Figma and what process has proved more efficient for me.
Figma is an ambitious—and pretty cool—piece of software: it improves collaboration and makes project handoff tidier than previous tools.
My work, like yours, is a particular flavor of UX and Design: I work in web development; Our programming team works in 2-week agile sprints; we’re a non-profit; and so on. For me in my current role, and despite its cool features, I found that Figma was building in inefficiencies and contributing to misunderstandings on our team’s path towards a working product.
Below I share the drawbacks of Figma we ran into, an alternative workflow, and it’s benefits.
Drawbacks
With Figma, handoff is baked into the process. As described on their own website, Figma can “create responsive components that map closer to code, making developer handoff more seamless.” Closer to code is a long ways from being code, and a more seamless handoff is still a handoff. Just one example of this is Figma’s lack of breakpoints: any breakpoints you want to demo must be build by hand in Figma, and then redone in code. Unnecessary handoffs are not an efficient use of design time.
Figma can’t directly contribute to our agile team goals of building, testing, and improving by incremental product iterations for a simple reason: it generates a design artifact and doesn’t contribute to the product itself.
Everyone can understand a website, not so with a mockup. Figma’s outputs also require accompanying descriptions and documentation of intent to be understood by all parties, or we risk creating comprehension debt.
Figma’s front-loading of design is more aligned with waterfall processes. I am not anti-waterfall, it is a great pattern when specifications are known up front and change is unlikely… but that does not describe any software project I have ever worked on.
Programmers who rely on assistive technology are blocked out of the process until Figma has been translated to code. Figma projects are born inaccessible, the opposite of what we are working towards. Figma’s accessible prototypes are in beta, but even when completed AT BEST they will deliver a very limited version of the accessibility that HTML already offers.
Another consequence of siloing the design process is that programmers are left holding the accessibility hot potato. Designers should be deeply involved in the building and testing of accessible layouts, too, and the project is weaker for fragmenting building and testing a product from designing it.
Lastly, Figma is a tool for visual design and, while it does not dictate a polished outcome, it certainly encourages it. A good-looking artifact too early in the process shifts attention away from requirements and usability and towards layout. Design is a powerful tool of persuasion, but achieving buy-in too quickly kills discovery.
An alternative
My alternative process is to work directly on functional prototypes written in HTML. Some designers start to get pretty 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 also have more options all the time to make code accessible. There are nocode options 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 much easier.
On my team we use CSS/HTML frameworks and component libraries for rapid prototyping, and it almost becomes 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 at the level I need is doable, produces useful code, and accelerates our project goals.
Benefits
The biggest benefit 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 a browser. It taps into mental models we already share. As Teresa Torres urges us, we should continually “visualize our thinking” in ways “that are easy for other people on your team to understand.” I know of nothing as easy to understand across a diverse group of people as a functional prototype in HTML.
Working on a functional prototype mitigates handoff because the prototype IS the product. Sure, at some point my coding hits a wall (and often pretty quickly) 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. As Raj Naggapan puts it, “The necessity to pivot based on feedback from a working demo is not a far fetched idea.” With a prototype, change requirements can be worked on by designers and engineers as they arise, and in a shared environment, without the need for additional handoffs.
Responsiveness and accessibility can be tested in their native habitat, and with standard tools, from the earliest stages of the project. Accessibility is not an enforced 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 themselves, there is no delay to their involvement. Unlike when working in Figma, we can ensure our product is born accessible, even in very early stages.
The one constant we can rely on is that projects change and morph, which is what agile strives to embody for programming. With this process, design can be iterated upon too, and be informed by the continuous user testing that this way of working empowers.
Conclusion
On my product team, front loading design has too many drawbacks. We have dropped a Figma-based design process in favor of rapid prototyping in HTML/CSS using frameworks and UI libraries. Here is a recent case study I wrote, just one example of what this process can look like. For myself, iterative functional prototyping makes UX and design far too enjoyable and efficient for me to return to a front-loaded, handoff-dependent way of working.
This article originally written by Shamsi Brinn and published on Medium
Continue Reading
