
What design tools get wrong - deanalevitt
https://kilianvalkhof.com/2019/design/what-design-tools-get-wrong/
======
doitLP
Sounds like the author wants his tools to be as fully featured as the code
that will embody the resultant design. In that case I would recommend learning
more code instead of relying on a proxy that will never be as flexible.

The best designers I’ve worked with not only understand their own domain but
the possibilities and limitations of how it will be executed, because they are
also developers.

~~~
jasim
When someone says HTML & CSS is terrible I ask them to design something better
that lets you represent user interfaces that can adapt across multiple screen
sizes, and allow complex layouts that Flexbox and CSS Grid makes possible. It
is easy to criticize something if you don't have to worry how you would do it
better.

That said, HTML & CSS is just how the world currently is. It doesn't mean that
it is the best possible way to do it. CSS could've been very different if not
for many fortuitous events in history: [https://eager.io/blog/the-languages-
which-almost-were-css/](https://eager.io/blog/the-languages-which-almost-were-
css/)

The best possible way to represent user interfaces is to represent them
visually. Having to learn code to build UI is just today's limitation. While
many have tried and failed to do better, this is still an open question.

Today maybe a designer must understand HTML & CSS to fully embrace the medium.
But that means they have to get out of their visual thinking mode, and look at
letters on a screen and interpret them in their mind's eye. As programmers
we're used to it, but it doesn't mean it is the best nor the only way to do
it.

So I'm all for articles like this that questions the status quo instead of
accepting defeat and asking people to just get on with the program.

~~~
ebg13
> _When someone says HTML & CSS is terrible I ask them to design something
> better that lets you represent user interfaces that can adapt across
> multiple screen sizes, and allow complex layouts that Flexbox and CSS Grid
> makes possible._

Uh huh. And how many years did it take to actually get Flexbox and CSS Grid? I
mean...They're both still "Candidate Recommendations" in 2019. That's not even
the penultimate level of recommendation. You definitely can't use Grid if you
want broad compatibility; it was only first implemented in 2017. "People
should update their software to the latest versions! And they should switch
browsers to use one that supports my nonstandard features!" Oh, yes? Well they
don't. And let's not even talk about Grid Level 2 which is implemented
nowhere. We've gone through generations of faking markup with javascript
because the dogma behind CSS has always been a terrible mess. "No tables for
layout!" Ok, what else are you supposed to use to arrange things in grids?
"Uhhh....give us a couple decades to get back to you on that."

When people say that CSS is terrible, they mean the actual standard parts, and
they mean for the past 22 years.

~~~
baddox
> "People should update their software to the latest versions! And they should
> switch browsers to use one that supports my nonstandard features!" Oh, yes?
> Well they don't.

I mean, I agree that developers shouldn't feel entitled to have all potential
visitors using the most up-to-date software, but it is also definitely true
that there is almost never an excuse to be using a web browser that doesn't
automatically update. Forget CSS features, it's a pretty big security concern.

~~~
ebg13
I kinda sorta almost agree and yet that's definitely not how the world works
for all kinds of reasons that aren't the user's fault. Also, I find it supes
weird that you responded to that part and not the part where it took two
entire decades of "tables are evil" before we got the first CSS grid
implementation that isn't even a standard yet.

------
golergka
It seems that author advocates for design tools to become more and more like
developer tools - a notion that I, as a developer, can totally get behind.

However, in my 12 years of experience in game development, many people who are
world-class designers and artists don't have the same mental model as
developers. There are a lot of "technical art" issues that in the end, you'd
rather handle on a developer's side. I just don't think that a person who
spends his time thinking about character's emotion, colour balance, human
anatomy and other art-related issues is in the same mind space to think about
technical issues like which UI containers should be scaled on what rules
(full-screen or safe area? hugging the screen outside or inside?) for
different screen sizes, how things should be composed from layers and
animated, how assets can be converted from a static image to a resizable one,
how a giant image can be cut into a 9-slice (or in a more complicated way) to
save texture budget, how can we reuse already existing assets without
importing another image that is very, very similar, how different kind of
gradients behave with not-pixel-perfect scaling and crunch compression (and I
didn't even go into 3d!). I tried empowering designers and artists so they
would make these decisions, but they hated it and were miserable - so in the
end I'd rather get a static, single-sized PSD and do all that work myself.

All of this, of course, are just my 2 cents from a specific industry and with
a very specific kind of people in mind - I'm not trying to impose these views
on any designers and artists who want to get into the technical art side and
would be thrilled to see more and more individuals who can be productive and
happy in this kind of hybrid role. But as a matter of fact, these people are
very, very rare and we shouldn't expect most artists to be like that.

~~~
parksy
Kind of agree (as a developer who appreciates art) - right now we're
constraining ourselves to grid-based layouts. Having been in web
professionally for 15 years and recreationally for 25 years, I've seen UI
conventions change a lot as technology, form factors and global design trends
change.

So modern tools like sketch work for grids, mobile responsive, yada yada which
is much better than using photoshop as the design sits closer to the canvas it
will be rendered on. As a developer, yay that works great for me! And also
it's a huge middle finger to those designers who just built stupid impossible
pointless UIs in the 90s and 2000s.

But it's also very constraining for the designer, especially given how far
standards have come, and it's almost a given that someone is going to come
along and Bauhaus the shit out of UI.

I really enjoyed the challenge of implementing a truly creative design on the
web, but there has been a general convergence towards a convenient middle
point where the designs are constrained by development requirements, at least
in the way the tools are geared.

That's not to say a great artist can't create something amazing but if we have
to teach all our creatives that they must conform to this particular way of
thinking, then we're cutting the industry short in a bad way I think.

I guess the next thing will be a sass or js library called bauhaus.js. Or is
that just DOM + CSS?

~~~
HeWhoLurksLate
> _it 's almost a given that someone is going to come along and Bauhaus the
> shit out of UI._

I nearly fell out of my chair of laughter when I read that.

Out of curiosity, do you mean this in a positive or a negative way?

------
matthewhager
We created exactly what you are looking for at
[https://shift.studio](https://shift.studio). You design “systems” which are
web components built in React (though as a designer, this is abstracted away
from you). The components have variants, state, data, and we have a fully
featured media query system to help you handle responsive design. Finally,
we’re fully integrated with NPM so you can pull code in if you want and add
functionality to your design system.

We will soon add the feature to expose your design system as an NPM package so
that developers can install the system into their project and the component
creation can be the domain of the designer with the application
structure/creation being the domain of the developer.

This is a problem that can be solved but it can’t be half-baked solutions. It
has to allow designers to fully create all states of a component and even work
on components with live data flowing through.

We are in closed beta but you can view videos of how Shift works here:
[https://www.youtube.com/playlist?list=PLl4_DbGKML_Jb2Wq5pEGW...](https://www.youtube.com/playlist?list=PLl4_DbGKML_Jb2Wq5pEGWgPznK6mUj0tC)

------
phaedryx
I worked at an agency with designers. We (web developers) convinced the
designers to use Sketch for the stuff that they did for us. It saved us a ton
of time over receiving Photoshop and Illustrator files to work with (the
traditional "design tools").

Sure, things could be improved, but I love that we have Sketch and Figma now.

~~~
jdhn
I've found that agencies are behind the times when it comes to design tools. I
once exported a screen of a mobile UI from Sketch as a PDF, only to be told
"When I opened it in Photoshop, it was one flat layer. Can you send over your
original Photoshop file?" I told them that the original was made in Sketch,
and that was the last I heard from them.

~~~
ypeterholmes
To be fair, Sketch is a Mac only program, so the team may have just been
unable to use it, and preferred to just move on rather than purchasing an
entire new computer (and Sketch). It would perhaps been more helpful to have
responded by offering to provide your Sketch assets/layers via Zeplin, which
is free and web based.

~~~
poof_he_is_gone
Sketch files also open in Figma which is free, browser based, and OS agnostic.

------
comis
I could nitpick the authors points, but honestly this article just boils down
to "Design tools need more features!" which I generally agree with. We're
living in nice times for design tools though - Figma/Sketch are leading the
pack and moving extremely fast.

We're no longer in the dark ages of waiting 5+ years for Adobe to implement
some basic feature (like being able to round corners on a rectangle). Well, I
guess if you're for some reason using xD you're still waiting a comically long
amount of time between significant releases, but that's your own fault.

~~~
shams93
Well a lot of people don't know how to use Figma properly and still are
exporting css with absolute positioned items so there's certainly a need for
courses on Figma its a very deep tool but its not going to give usable results
by default.

~~~
chrisweekly
Got any good links to share that would help designers level up w/ Figma and
leverage it properly?

------
anoffsinger
I recommend you try Figma, as it addresses and solves most of the gripes in
your post.

------
poof_he_is_gone
I think that design tools are slowly but surely zeroing in on this. The
updated versions of Sketch, Figma, and InVision can support responsive
layouts, and all of them are moving from being able to create static designs,
to interactive prototypes. There are several plugins and workflows out there
that will convert your designs to useable code, and it is only a matter of
time before this software is doing that natively and representing the full
stack.

------
erikpukinskis
Somewhat off topic, but this gets at an issue with “components” of all types
that I’ve been wanting to get off my chest:

> _Design libraries are also limited in the type of things they share: just
> components or symbols. This works great if all your design work is just
> clicking together new screens with the same components, but anything new
> will see designers clicking into components and copying over things like
> colors, font variants and checking spacing just to copy that over into new
> components. When you copy over things, you’ll invariably make mistakes
> (we’re just human after all)._

Ideally, a component system means you’re black boxing some function.

Unfortunately every component system I’ve ever seen has a hard boundary at
some “material” transition:

A UI drawing that can be used inside a design program

A React component is bounded at the DOM and can’t handle server side concerns

A CSS component is bounded at styles and can’t handle HTML concerns

A middleware component that handles authentication, but can't reach outside
the routing phase.

etc

Inevitably then, you end up having two or more tightly coupled components:

A front end component + the server API that it knows how to talk to

A little HTML widget + a microservice that it feeds with it’s own persistence

A container for wrapped content + a little middleware meant to be added to the
app that serves the content

A button + a delayed job + an email template to get sent when it's done

etc

In order to do this, instead of just having one module with a tight set of
concerns inside it, you have to implement some of your concerns in two places,
and you also have to map data into the component interface, and then back out
again. In some cases this can be 4x the complexity ("code" vs. "code + write
to component interface + decode component interface + variant of code on other
side of interface").

If the component could span both domains, it could just move the data exactly
where it needed to go, as efficiently as possible, since the data is all
internal to the component.

The conclusion I’ve come to is something like "components want to be free."

I.e. components want to have concerns that can span the entire stack, and
implement procedures in arbitrarily disparate kinds of source locations.

This of course precludes ALL of the component systems which are confined to a
specific material domain. It means the boundary of a component has to look
something like arbitrary source code. Component interfaces can’t conform to a
single template.

That raises the question “what is a component at all?” If the boundary of my
component is just a set of function calls, it’s just a module. How is it a
component?

And maybe it’s not. Maybe components are a local maximum in code cleanup, and
I’m advocating people move past them and just write really excellent single-
concern modules instead.

I don’t know. This is as far as I’ve thought it through.

(I do maintain an NPM module called browser-bridge that lets me build
arbitrary client/server components, along an event sourcing library called
a-wild-universe-appeared for doing persistence in an isomorohic way, and then
something called bridge-module for getting dependencies in the browser... All
of which let me experiment with what I'm describing, but those are all in a
pre-1.0 mostly beta state. The basic interfaces are all stable though.)

~~~
HeWhoLurksLate
This is why I've been holding off on trying to develop cross-platform software
that talks to microcontrollers and then executes code- because I want the UI /
GUI experience to be fluid, and for things like selecting something you want
to change to highlight that element on the board itself- there's no well-
defined method for doing this, nor even a once-trod path, and definitely not
anything for those who don't know where to look.

Does anyone have suggestions for cross-platform UI's? (Not Electron)

~~~
chadcmulligan
Delphi? It has cross platform for iOS, Android, Windows, OSX, also server side
on Linux. If you're after microcontrollers, it has a good sized group of IoT
users.[https://www.embarcadero.com/products/delphi](https://www.embarcadero.com/products/delphi)

------
marcintreder
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 :)

------
tomger
I don’t think the author has spent a relevant amount of time with Figma

