I think the underlying premise of this excellent article is that design tools have to get closer to the capabilities of web technologies in order to bring much needed realism to the design process.
This is exactly what still gets me going after nearly 10 years working on design tools (I co-founded UXPin back in 2010). I'm so glad that more people in the industry notice it!
Majority of the popular design tools (Sketch, Figma, InVision Studio, XD...) work in a 30 year old paradigm of image based–design tooling (originally created for early vector and raster "creative" tools that were never meant to be used to design software interfaces!). In this paradigm the output of a design tool is an illustration of the final product that has no relation to the reality of code. The rendering is different, the interactions are just slide-based simulations, the ability to describe states is nonexistent. To get more down to earth - those tools can't even render a simple text field or a checkbox!
And yes – they're getting better and better, but ultimately getting around the limitations of their paradigm is impossible. At the end of the day those tools are perfect for drawing icons and illustrations, but really bad at creating, for example, a working prototype of a form field with validation.
That's why a bunch of design tooling rebels (UXPin, Framer X, Modulz, Interplay, Shift...) started to work on code–based design tools. In this paradigm the output of a design tool is rendered from html/css/js code, but designers don't necessarily need to know how to code. Majority of UXPin users don't even know that they're prototyping interfaces with advanced JavaScript :).
Within code–based paradigm the limitations of image–based tools do not exists.
In reference to the article here are some features present in UXPin (and some others just to illustrate my point):
- states of elements (every element can have multiple states and variants, originally we've built it in 2013. The new version was launched last year).
- conditional interactions
- javascript expression (from advanced math, regular expressions to operations on strings - in UXPin designers can build really advanced prototypes)
- context awareness (prototype can be aware of the os/browser that is used for previewing or e.g. the size of the screen and conditionally render the right state of elements)
- accessibility linters
- import and synchronization of production React.js code (in beta, we're calling it UXPin Merge)
- access to external APIs (you can, for example, build prototypes that can interact with smart devices)
None of that is possible in the old paradigm! Of course the giants of the design industry don't want you to know it, so they invest tens of millions of dollars into flashy marketing:)
Some things that Kilian mentioned are still missing, but we (and others!) are working on them.
Hope this is providing some context to the state of the design tooling industry.
Ps. Fun fact - Figma branded themselves as the first design tool with real time collaboration. We have it since 2011 and... it was also called multiplayer design :)
This is exactly what still gets me going after nearly 10 years working on design tools (I co-founded UXPin back in 2010). I'm so glad that more people in the industry notice it!
Majority of the popular design tools (Sketch, Figma, InVision Studio, XD...) work in a 30 year old paradigm of image based–design tooling (originally created for early vector and raster "creative" tools that were never meant to be used to design software interfaces!). In this paradigm the output of a design tool is an illustration of the final product that has no relation to the reality of code. The rendering is different, the interactions are just slide-based simulations, the ability to describe states is nonexistent. To get more down to earth - those tools can't even render a simple text field or a checkbox!
And yes – they're getting better and better, but ultimately getting around the limitations of their paradigm is impossible. At the end of the day those tools are perfect for drawing icons and illustrations, but really bad at creating, for example, a working prototype of a form field with validation.
That's why a bunch of design tooling rebels (UXPin, Framer X, Modulz, Interplay, Shift...) started to work on code–based design tools. In this paradigm the output of a design tool is rendered from html/css/js code, but designers don't necessarily need to know how to code. Majority of UXPin users don't even know that they're prototyping interfaces with advanced JavaScript :).
Within code–based paradigm the limitations of image–based tools do not exists.
In reference to the article here are some features present in UXPin (and some others just to illustrate my point): - states of elements (every element can have multiple states and variants, originally we've built it in 2013. The new version was launched last year). - conditional interactions - javascript expression (from advanced math, regular expressions to operations on strings - in UXPin designers can build really advanced prototypes) - context awareness (prototype can be aware of the os/browser that is used for previewing or e.g. the size of the screen and conditionally render the right state of elements) - accessibility linters - import and synchronization of production React.js code (in beta, we're calling it UXPin Merge) - access to external APIs (you can, for example, build prototypes that can interact with smart devices)
None of that is possible in the old paradigm! Of course the giants of the design industry don't want you to know it, so they invest tens of millions of dollars into flashy marketing:)
Some things that Kilian mentioned are still missing, but we (and others!) are working on them.
Hope this is providing some context to the state of the design tooling industry.
Ps. Fun fact - Figma branded themselves as the first design tool with real time collaboration. We have it since 2011 and... it was also called multiplayer design :)