As noted by Derek Briggs, “Users don’t see your Figma files, so they’re only as good as their implementations.”

If you can’t translate all the hours and talent being sunk into a Figma file to working code in the browser, you’re throwing away time and money.

It feels analogous to those “Pinterest fail” memes which comically (and painfully) illustrate the attempt to translate a beautiful abstraction of an idea into the manifestation of the idea itself.

You only capture the full value of a talented designer if you have an equally talented engineer capable of discerning and implementing their Figma skills into code.

Or, if you’re lucky, you’ve got a design engineer who can do both.

Just as my lovely professors has said, knowing how to wireframe or mockup in a particular tool 100% did not matter. In fact, all the projects I had done in those tools I didn’t particularly like. Despite all my effort, they ended up looking templated with little new or interesting thinking. I didn’t even use them in my interviews. I had spent a lot of time wrangling the tools to bend to my will and while doing that, sucking up my time for letting my imagination run wild, to play, explore, and make new and in the end, I didn’t find the “me” in any of them. That’s when I decided that if I couldn’t do my job with pen and paper (or whiteboard and marker), then I wasn’t a very good designer. To this day, I find the sentiment to be at my advantage.

I believe the way most organizations produce digital products is fundamentally broken. The elephant in the room is a dated understanding of the role of both design and engineering, which in turn shapes how organizations hire, manage, and produce digital things. These companies invest billions of dollars building teams, processes, and tools on top of an immature discipline and an outdated waterfall model that ends up being detrimental to productivity, team happiness, and ultimately, the resulting experiences we bring to life.

The currently popular Figma has a tendency to push development teams into the waterfall direction and for that reason I avoid Figma in web development projects. I prefer to work with the materials at hand, HTML, CSS, and JavaScript (TypeScript). It avoids design handoff and allows to adhere to what lays in the materials.

When designing responsive websites by starting with a small screen and introducing a breakpoint when the page layout requires it, you will resize your browser window all the time to see how the page layout works at different sizes.

This design process is impossible to follow by creating static mockups of page layouts in a design tool and then implementing those mockups for the browser.

...When the entire process is relying on the two subsequent steps of designing a polished static mockup with a design tool and then implementing it, you have introduced a nice waterfall process in your workflow and waterfall processes make learning slow and expensive, while you want quick learning in any software project!

I prefer coding and adjusting continuously within a browser, the medium of delivery.

...There are two ways to design with code:

It can be done by a single person able work with both forms of expression, design and code. Jim Nielsen calls this person a design engineer and Jim has an excellent example of the problems being solved by design with code in his text The Case For Design Engineers, Pt. II.

The alternative is two closely collaborating people, a designer and a coder, continuously working together to identify the relevant details, taking decisions and implementing so that it doesn´t feel like designed first and implemented second.

The problem with HTML is that most designers don’t know how to code. And HTML prototypes are usually more expensive to create compared to Figma.

But HTML prototypes are realistic and almost identical to the real thing...This makes research insights far more reliable.

Also developers have less to translate. Sometimes developers can use the code that has already been used for the prototype.

“But what if the designer can’t code?”

You either:

• Make do and increase the risk to UX
• Hire a designer that can
• Train your designer to use code
• Give your designer a developer to work with

“Do you really need to create an HTML prototype if you’re just testing the general flow?”

No, probably not. But at some point, you’re still going to want to test a high fidelity version to give you confidence and reduce risk.

The only difference between web design in 2004 and 2024 is that websites are now painted in Figma instead of Photoshop.