
The future of design tools - knowingathing
https://www.getmotion.io/blog/the-future-of-design-tools/
======
zackbrown
The author's assessment of the "no-code" and "hybrid tools" landscape is
either lazy or a joke. Here are a few more:

No-code tools for apps & websites:

    
    
      - Webflow
      - Glide
      - SquareSpace
      - Dreamweaver [1]
      - Visly
    

Hybrid "designer/developer connectors"

    
    
      - Hadron
      - Modulz [2]
      - Interplay [3]
      - Haiku [4]
      - Zeplin
      - Zeroheight [5]
      - InVision DSM [5]
    

Sad to see this blog post on the front page of HN since it's such a poor
representation of this landscape. Hopefully this comment helps in a small way
:)

    
    
      --
    

[1] yeah it still exists, and yeah it's pretty much still Webflow as a
90's-vintage desktop app.

[2] Modulz' product doesn't exist yet, but they've built hype. Caveat emptor.

[3] Just like Modulz, but from what I've seen there's more execution and less
hype.

[4] My company: we pivoted our original "designer/developer connector" into an
animation tool — we're launching our new collaboration tool soon.

[5] Sort-of; designer-focus

~~~
brudgers
The remarks about the author detract from Hacker News more than the
information in the comment adds to it. Removing those remarks would improve
the comment. Adding links to the resources might improve it further but won't
make it good Hacker News comment if the remarks remain.

~~~
zackbrown
Thanks for the feedback!

"Lazy work" does not mean "lazy person." And "joke" would be better stated as
"this article reads suspiciously as astroturfing."

But I see how the blunt call-out of lazy work and tip-toeing around the
astroturfing vibes—i.e. the way I worded my comment—could read as a personal
attack, and I agree that's not a productive way to approach discourse.

I missed the edit window, but I would amend the first line: s/author/article
and s/a joke/intentionally misleading.

~~~
brudgers
The proposed edits don’t assume good faith and don’t contribute to
understanding the topic. Instead here we are in the weeds.

~~~
zackbrown
The article is misleading. That's either unintentional or intentional.

Per Hanlon's razor, my first hypothesis is the former but we shouldn't rule
out the latter. Proactively question good faith but don't proactively doubt
it.

Calling out the article as misleading mitigates the damage it causes and thus
exactly "contributes to understanding the topic."

------
davidy123
There is nothing "crazy" abut "Browsers gobble it up." Along with annotation,
this was supposed to be a standard feature of the web, in fact it was built
into early versions of Netscape[1]. It just takes the world a long, long, long
time to catch up with the bigger background ideas, because there are so many
details and so many ways to make money with the immediate.

1\.
[https://en.wikipedia.org/wiki/Netscape_Composer](https://en.wikipedia.org/wiki/Netscape_Composer)

~~~
calciphus
I had one of my team members recently introduce me to document.designMode="on"

For the better part of...15 years? I've been using various inspectors and dev
tools. Like a chump.

------
turbinerneiter
Is there a reason (or am I wrong about it) that the most common and most liked
tools for developers are mostly Open Source, while there are almost no Open
Source tools aimed for designers making it big?

~~~
robenkleene
Open source projects are run by developers, why would you expect developers to
make great tools for any field except development?

~~~
welly
Yet they do...

GIMP? Inkscape? Blender? Libre Office? Firefox?? Chrome??

I'm actually not sure what you're suggesting. There are no great open source
projects outside those written for development? That's clearly false.

~~~
robenkleene
As others have pointed out, web browsers are developer tools. Just because
other people also use them for other things doesn’t mean they’re not core to
developer's workflows.

GIMP, Inkscape, and LibreOffice aren’t competitive with their commercial
alternatives.

Which leaves Blender, which is _the_ exception of a high quality open source
tool that’s not for developers. I’ve spent a lot of time thinking about this,
and I think they’re two reasons it exists: 1. The comparable commercial tools
are very expensive, e.g., thousands of dollars per year, versus a bit over a
hundred a year for something like Photoshop. 2. Developers have a particular
affinity to 3D modeling, e.g., it’s the biggest gatekeeper to various types of
development like games programming and AR/VR.

But I agree 100% that Blender is a fascinating exception, and I’d love to hear
more theories about what’s made it so successful.

~~~
FemmeAndroid
A notable thing for me as a very light amateur user, was that Blender (up
until the recent 2.80) felt very foreign when compared to professional tools.
It is an incredible accomplishment, but it had a notable learning curve, even
if you had experience with other commercial 3d graphics software.

------
nicoburns
I find it amusing that Sketch and Figma are considered "traditional tools"
now. It wasn't so long ago that neither of these existed, and everything was
Photoshop.

~~~
robenkleene
I think he’s talking about the paradigms as raster and vector editors, which I
would still categorize Sketch and Figma as. They’re vector editors with some
specialized features for UI/UX. They’re still largely in the mold of what
Photoshop and Illustrator have done for over 30 years.

What I always find interesting about these pieces, is they always seem to be
saying “they’re old now and need to be replaced” rather than marveling at the
durability of original approach, which has been astounding. Same can be said
for plain text, Unix shell tools, spreadsheets, NLE editors, the DAW. These
should be celebrated for how successful their designs have been, instead of
lamenting how many “old tools” we're using.

~~~
smilespray
You make many good points, especially NLEs and DAWs.

For me, the last "killer" Photoshop feature was layers. That was in 1994. I
still use it every day, but only because I have almost 30 years of muscle
memory. It's getting slower and slower for every release.

Granted, it inherited a bunch of nifty web-savvy features from Adobe
ImageReady in the first half of the 2000s, but the whole sh*tshow that went
down when ImageReady was killed was internal politics and a sign of crappy
things to come.

It's interesting that the same navel-gazing, customer-ignoring attitude that
killed QuarkXPress in favour of Adobe InDesign struck Adobe.

(By "killer", I mean a feature that completely changed the way I could work
with graphics. Sure, I've saved a bunch of time with Actions, but the feature
was not transformative.)

------
PaulDavisThe1st
Another article on design for software that is written as if there will never
be another non-browser/non-CSS app ever again.

------
nlte
I've never understood why web design doesn't take place in a text editor and
browser (with other tools, like Photoshop or Illustrator, for secondary
tasks).

The output of web design is, ultimately, HTML and CSS, so what reason could a
professional have to work with tools that can only yield an approximation of
what they are paid to do? In my view, a designer without full mastery of at
least HTML and CSS doesn't really deserve his title.

Going a little farther: with some knowledge of JavaScript, JSON and how to
transform it (map, reduce, filter, sort), a designer can ask for some sample
data and come up with a functioning prototype that offers truly important
insights into the problems his design is supposed to solve. Client-side
frameworks like Svelte.js are making all this very easy.

Nothing is more maddening, and a waste of time and money, than a Photoshop
mockup using rudimentary, and generally too self-complacent, content.

~~~
chadlavi
You're right, everyone should have the same job as us! /s

Design is a different skill set than writing code. For some highly
visual/spacial people, design is easy and intuitive, and managing lines of
text is very unwieldy. Be like, 1% empathetic dude.

Anyway, if designers wrote the code you'd be out of a job. Design should be a
continual conversation between someone with the vision and someone with the
skills to implement it.

~~~
nlte
My comment didn't exactly imply that designers and programmers are the same,
simply that web designers should be able to use the tools (and fully
understand the constraints) of what constitutes the final output of their job,
that is HTML and CSS. Writing CSS and server-side code are obviously two very
different things. A designer could be a guy who types CSS in a text editor,
among other things.

~~~
aklemm
Might be a tough pill for some, but ultimately I agree it's the way the
industry needs to end up. Consider the architect; he doesn't get to blue-sky
wild ass concepts for a building. He has to draw within boundaries of local
codes and feasibility, often using technical tools such as CAD.

~~~
chadlavi
An architect doesn't need to know how to tie rebar, though. That's more what
the other commenter is suggesting.

------
necovek
One of the things I rarely see discussed or even mentioned is the ability for
designers to easily provide incremental design improvements to engineers.

Software development now has long established practices to develop and deliver
incrementally. Where it is understood that you are delivering value
piecemally.

With the disconnect present between design and development, I think design is
still lacking in working out how to approach problems incrementally. All too
often, you are handed down a design to deliver in one go, when you can't
reasonably do that.

Perhaps it's my lack of familiarity with the field, but that's my perception.
(To be clear, majority of software devs still struggle with it too, but core
principles have been known and applied for 20 years).

Do any of the tools mentioned (or not) specifically focus on that aspect of
coordination?

~~~
jgust
I see teams who are investing in "design systems" approaching this operation
model. They're codifying the design language, teaching their applications to
consume this language, and then making changes to subsections of the design
system iteratively.

The design function (designers, product) can make changes widely, or isolate
them to specific components, and test these changes at each step rather than
the "all in one go" we're used to.

~~~
necovek
That is great to hear: do you have any links to less abstract write-ups of how
it looks and works in practice, and what (software or otherwise) tools are
employed?

~~~
jgust
Let me do some digging and see if there is anything internal I can share. If
not, the airbnb engineering blog has some good articles on this approach:
[https://airbnb.design/building-a-visual-
language/](https://airbnb.design/building-a-visual-language/)

~~~
necovek
Lovely: thanks! It'd be great to see if you can do a write up too, I'd love to
read it!

However, the article about DSL at AirBnB does not address my concern fully —
how does one go from an existing component to a new component, design-wise, is
my question? They seem to be mostly concerned with the consistency of the end
result, especially in a large and diverse team. I wonder about the consistency
of the interim results (which frequently end up being the end result).

For now, those interim steps are usually left to the software developer to
decide on, meaning that until the full "migration" is considered complete, the
component will be somewhere in between. And as projects are descoped and
priorities change, it is a very real risk that components will be in that
half-baked state forever.

I know that I have gone through the exercise a number of times, always leaving
designers unhappy, because I implemented only parts of what they designed
before I was pulled onto another project. And while I try to be cognizant of
the design issues, I neither have the time, knowledge nor experience to do a
good job of it.

If design instead provided incremental steps that are not necessarily half-
baked, but just steps in the right direction, I think it would improve results
developers put out, and at the time of "descoping", the component would still
be consistent and usable.

It sounds like an entirely different axis to what the tools are providing
today — we've gone from bitmap mockups, over vector mockups and state
transitions, to interactive and explorable mockups and component libraries,
but we are missing that "road" from "now" to "there" (a timeline of mockups
with all the phases). I know designers can choose to do this "timeline"
together with developers "manually", but it seems like a great thing for a
tool to help with.

As a developer, I like being given a "feature" to work on, and I prefer not to
break it up before hand — I start on something small that should bring some
value and that will give me an idea of what step should come next. Basically,
I know how I can develop an interim result that is of as high quality as the
end result would have been: it just achieves different or fewer things.

I would expect a tool that has "current state" as the start, and maybe "end
state" as the end (though in software engineering, we found out that the
expected end state is never the end state), and it would allow a developer and
designer to effectively work together to design the first step in a coherent
manner that will take them both to the end state. "Coherent" is important here
so it's not just a step towards the end state (which is what developers
usually resort to, which are commonly artificial improvements which might not
be improvements at all).

------
catchmeifyoucan
I have a #5 proposal. I believe as the future gets simpler. We’ll be on the
lookout for a “Morphing UI”. One that adjusts based on the environment. We’re
kind of seeing this paradigm with conversational bots - though not perfect.
Perhaps entire spaces built with something like: adaptivecards.io

It can’t replace all of our traditional UI. However, with more A.I. requiring
less inputs, there may be a future where data, not UI sets apart services.

------
Izkata
> This is a crazy idea but hear me out. Inspect Element is amazing. It’s what
> Hadron is basically utilising in its app. The experience that Chrome and
> Firefox have created around things like animations and grids is impressive.
> So why can't Chrome and Firefox add a few extra features, let developers
> enter “Edit” mode and allows those edits to change the files you are
> manipulating?

Wasn't it possible to set up Firebug to do this, before it died and was
replaced with the built-in tools? (Or am I thinking of a pre-quantum add-on to
the current tools?)

~~~
ollerac
I believe this is currently possible with Chrome's Workspaces [0].

[0][https://developers.google.com/web/tools/chrome-
devtools/work...](https://developers.google.com/web/tools/chrome-
devtools/workspaces)

------
ken
> Humans love standards and standardising things so I think whatever the
> future is, it'll always gravitate towards 1 or 2 main tools.

I need 5 different chat apps on my phone in order to talk to all my friends
and colleagues. And that doesn’t even include many of the ones I’ve read about
online which are apparently popular elsewhere, like WhatsApp, WeChat, and
Telegram. Standardization is great, but the set of tools we end up using is an
accidental emergent property.

------
dsego
Whatever happened to Macaw, the revolutionary web design tool?
[http://macaw.co](http://macaw.co)

~~~
uxcolumbo
Acquihired by Invision - unfortunately (hopefully fortunate for the Macaw
team)

[https://www.invisionapp.com/inside-design/macaw-team-
joins-i...](https://www.invisionapp.com/inside-design/macaw-team-joins-
invision/)

------
JDiculous
I've always wanted the ability to just save my HTML/CSS changes in Chrome Dev
Tools to the source files ("Future #3"). Why has that not been done yet? Would
save a ton of time.

~~~
robenkleene
My understanding is Chrome Workspaces[0] already do this. But the problem here
is how do you make this work with asset pipelines for SASS, HTML template to
languages, etc...?

[0]: [https://developers.google.com/web/tools/chrome-
devtools/work...](https://developers.google.com/web/tools/chrome-
devtools/workspaces/)

------
z3t4
I've been working on an IDE and one challenge is to reverse all the
compilation of modern frameworks in order to get WYSIWYG editing on the
compiled app.

------
sktrdie
Surprised Facebook Origami isn’t mentioned to bridge the gap between devs and
designers.

------
monkin
And, I'm still waiting for Sketch killer from Bjango... it's 5 or 6 years now.
;)

------
shripadk
Why is Framer X not on this list?

~~~
psweber
Probably because it's from a visual designer's perspective. There is nothing
in the article about prototyping. It was focused on layout and developer hand-
off. Framer is behind on those fronts, but they have a pretty different
paradigm.

~~~
shripadk
Why is Framer X behind on layout? It has a really good layout system based on
Flexbox and there is a plugin for handling grids too.

Do you mean to say Framer and not Framer X? Because both are totally
different. Framer was mostly geared towards prototyping while Framer X is for
creating shared design systems (apart from prototyping ofcourse).

------
lincpa
We can systematically simulate integrated circuit systems and implement
"software design/development automation" like Electronic Design Automation
(EDA). It is an innovative and revolutionary approach to develop large-scale
software.

[https://github.com/linpengcheng/PurefunctionPipelineDataflow](https://github.com/linpengcheng/PurefunctionPipelineDataflow)

