The design tool race: who wins the product design market?
Short answer: Whoever gets us closer to code and expressiveness at the same time. Come along.
Apart from being a designer, I also love to watch the markets of the industry I’m in. Currently, there are tons of tools that’d fall under “Product design” as a description. This will be a sharp rise from about 10 years ago.
A while back, Adobe Photoshop was still the preferred choice for product design for many. Web hosted software had not been popular. Most, if not, all design software still relied on a local devices to run, host files and store cache data. Sketch in 2010, InVision in 2011 and Adobe XD in 2017. Enter, Figma (2016)
Apart from being the lightweight software that can be used for almost anything today, Figma changed the way designers perceived software. It showed us what’s possible. Think of how foreign you were to the concept of having your work automatically saved for you. You were a designer who had lost a ton of files to software crashes or system interruptions. It was life-changing. They mightn’t have been the first to do it, who knows? But Figma became the first to do it in a way that it felt like magic. The story of Figma’s success in the product design space deserves a dozen paragraphs on its own.
Eventually, tools that had existed or be built would later adopt similar features: lightweight, web hosted and with cloud storage. Spline, Rive, Webflow, Framer, etc. While Figma may maintain a large market share, it wouldn’t boast of a 100% because there is another major part of the puzzle that needs to be solved: empowering designers and their creations. Basically, design to code.
We’ve seen in recent times different attempts to empower designers more by building code-ready design tools. These tools attempt to take artefacts crated by designers and convert them into code that a machine can interpret, keeping the semblance of its origin. You see, the problem with building this way is that codes are structured languages. They require things to fit into structures, containers and constraints. Code is, in itself, structure. This is in sharp contrast to how designers work. A designer’s iteration requires expressiveness and the ability to think and act outside the box. Design work, in itself, requires the lack of structure to work as it should. What we’ve seen are tools that were built on one methodology and ignores the other. The structured ones aren’t designer friendly. The designer-friendly ones find it difficult to parse aretfacts into clean code.
Let’s take Webflow, for example, despite the amount of work it put into educating potential users on the tool use, it still struggled to attract the amount of designers it could have attracted. Why? The tool itself was built with developers first in mind. How? Structured workflow. Then again, you’d ask, only designers are more likely to use a tool like Webflow but how would they use this if it’s at variance with how they’re wired to work?
The clash and contrast of the two methods of work is what the next generation of design tools will need to figure out. The prize for figuring this out? Complete control and domination of the product design market. This mythical tool will present the next product design revolution, empowering designers to turn their artefacts into market-ready products.
It is important to learn that while designers seek to think and operate without structures and constraints, the laws that govern the communication of humans and machines require structures to function properly. What we know is that anyone who might be reading this might have the answer to the question of turning everyone of us into builders.
The race to the top welcomes more adventurers.
