There is an ever-increasing number of web prototyping tools out there. From Adobe XD, to Invision, to Figma. And the number of apps within this niche seems to grow daily. Every posting for a potential project seems to list a need for knowing one, or a couple of these, so I, along with thousands of other people are constantly learning new ones to keep up. As the demand for people who know these programs increases, more and more startups try to solve the “problem” of easy prototyping and more products are released to the market, fueling the desire for product managers to demand even more people to know the new and improved software. It’s a massive vacuum that sucks designers further and further away from the nuts and bolts of how the web works, and I think design suffers as a result.
Of course all of the time spent learning a new piece of software could just be spent learning how to code.
Honestly I was a bit of a late-comer to these prototyping tools — I just really didn’t understand the need. Generally when I want to test ideas out and understand how a website is structured, I get coding. Why would I want to use a product to do what I can do within the real medium, especially considering that the prototyping tool doesn’t save actually save time, and it is less robust in its capabilities?
Having worked with both prototyping tools and hand-coded prototypes, the clear winner for me at least is the hand-coded option. They are faster to build with, which many may not believe, since the whole goal of prototyping tools is to speed things up. Having coded for the web for over 15 years has left me with quite a bit of knowledge for building quickly, but more importantly, I now also have a robust library of elements that I have developed and my own framework for setting up sites that makes it incredibly easy to quickly build out a website or web-based tool.
Not only is it faster to build out a prototype with code, but I also gain another speed boost when I can actually use the working prototype to build the final site. After knocking in the site structure and experimenting with organization, I can actually use what I’ve built as a foundation to build on top of. Someone who has designed the site with a prototyping tool requires a coder to start over from scratch to actually begin building it.
Designers could just learn to code — an initial set of skills needed to prototype out a website doesn’t actually take too much to learn. Unfortunately everyone is telling designers that they need to learn and purchase subscriptions to these new programs, so there isn’t much incentive for designers to learn. Learning to code can seem daunting as well. I realize that many don’t have that experience or the toolkit that I’ve developed over the years, but I think instead of going down the road of utilizing and learning separate prototyping tools, a better solution would be to create tools that would assist designers with building real html-based prototypes. This solution would still full control over how the code is written, but it could speed up and assist as needed.
Unfortunately, I don’t really think that will happen. I expect that over time, the divergence between design and coding will continue to widen as designers are separated more and more from code. It’s unfortunate, since the result will be products that take longer to design and develop, require more people to manage, and needlessly increase the costs for clients. The overall design and quality of web-based products will also likely suffer.