What design tools get wrong

Easy, something like Winforms or one of its successors like whatever they make Win10 apps in. Even the new Unity3D UI stuff is better.

I know the triangle of forces would have something to say about my statement, but I find too many developers purposefully build a wall around themselves and product design, perhaps using the aforementioned triangle as justification for why they should keep that wall erected.

Yet, even a passing attempt to understand the basics of design, whether of user interfaces or even of something as mundane as a chair, opens one's mind up to possibilities hitherto unseen due to failing to understand that there can be a strong link between aesthetics and function.

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 part of your post I find to be in contradiction with the HN guidelines. It's not a helpful, it's merely snide and dismissive.

Anyway, I don't think my behaviour is crappy. It is undoubtedly better to run your design past someone, test things, take feedback, fix issues, and improve the interface to correspond with the things that people find difficult. If people want help with interface design, the world is not short of willing volunteers with the relevant expertise.

Especially considering I made it clear I was talking about utilities used by, and I quote myself, "regular, non-technical people" — they don't care whether you're making an "expression of vulnerability", they want their software to work. Additionally, the world of IT helpdesk does not applaud having to troubleshoot problems that should've been solved years ago because so-and-so decided to do everything by themselves rather than do some basic user testing or simply have someone else look at their design.

If something is in a testing state, call it a beta. I respect a product that knows it isn't ready for the big time and so is explicitly marked for improvement, either by collaboration with a designer at a later stage or community involvement — this is what happens a lot in open source.

However, don't put it into production, particularly if its design also leads to more problems overall for the users by virtue of its premature release.

I take the user-centric view of product design. We are making these things for other people. They are not going to give us trophies for participation.