Prototypes are an essential part of the design process as they allow us, designers, to test and validate their ideas before investing time and resources into building the final product. Prototypes allow to identify potential development issues, thus saving time and money.

They also allow us to communicate ideas more directly.

Last week, Figma showed us how to make prototypes within Figma that act and look like the real thing. It didn't take long before some designers started building cool stuff with the new properties.

Like this game of Flappy Bird.

https://www.figma.com/community/file/1255294635761885013

I'll be honest. I am amazed that a game can be built so quickly in Figma.

But here's a question that's been nudging me lately: Are we, as designers, making the most of our time by creating ultra-detailed, hyper-realistic prototypes? Or is this just another way to keep us busy?

The Allure of The Pixel-Perfect Prototype

There's no denying the allure of a pixel-perfect prototype. It looks professional, feels real, and gives stakeholders a tangible sense of the final product. But are we sacrificing more than we gain?

The Cost of The Perfect Prototype

Creating a prototype that works and looks close to the actual product is not a walk in the park. It takes a significant amount of time, energy, and resources. Time and energy could otherwise be spent on other essential aspects of the design process or simply building the goddam product.

Are we Playing in the Sandbox?

When the playground is a software application instead of the natural world, are we truly designing or simply playing in a digital sandbox?

Don't get me wrong, sandboxes are great for experimenting and learning. Yet, there's a difference between building sandcastles and designing skyscrapers.

The Figma Fable

So, back to our Figma game. It's beautiful. It's interactive. But it lives in an isolated dimension, accessible only to those with a Figma account.

While it might make for an impressive portfolio piece or a fun exercise, its practical application is inherently limited. Nobody, but other designers, is ever going to see the prototype.

Redefining Prototyping

Perhaps it's time we reevaluate our approach to prototyping. Maybe the goal shouldn't be to create a quasi-product that dazzles but doesn't deliver. Instead, focusing on the main objectives of a prototype:

• Communicate ideas (to stakeholders and developers)

• Test and Validate ideas

Do we need to be able to add/remove infinite products to a cart to show what the plus/minus button does? Are we so insecure that we must show how an app will work in edge cases?

Granted, building a complex prototype does not take as long as building a real app - but does that make it necessary?

And while I've read many designers say that this brings us closer to the actual product, I feel it does the opposite. It gives us the illusion of building while the older kids go to another room and build the real things with the PMs by their side.

Like playing a video game with an unplugged controller.

Maybe it is just me

I'll confess that I have only worked with smaller teams. Usually, under 10 people building something, and maybe that is why I cannot imagine why we need to have a perfect prototype replica of an app.

Maybe that is a featured thought for enterprise users.