Kilian Valkhof

What design tools get wrong

Modern design tools, of both the vector and code kind, are amazing pieces of software that in recent years have transformed the design profession, but none of them seem to really understand the context that we currently design for. The remnants of fixed-dimensions are still visible in all and the tools are not helping us with the considerations and trade-offs that designers have to make about their work. Here are some of the features that my ideal design tool would support natively.

Design libraries should work for agency designers

Libraries in applications like Sketch, Figma and Adobe XD work well for product designers but much less so for agency designers.

To understand why, let me explain the difference between product and agency designers? Product designers are people who work on a single, or a couple of products that their company creates. Think of the design team at Airbnb or indeed, companies like Sketch itself. These designers might have a single design system or style guide that they work from, with a single or couple of projects built on top of this design system.

Agency designers on the other hand are the designers that work in web agencies, where at any time they might be working on projects for half a dozen clients, each with a different design system (if at all) or style guide and varying levels of design maturity. These designers switch between projects often and might even have to hand over assets to a new designer depending on their project planning.

For product designers, the current implementation of design libraries works well. They might have just one or two (web and mobile, for example) design libraries that share their overall style. Since all design libraries are available for all design files, this works out well.

Agency designers on the other hand, might have 10 or 20 different libraries. Some will be current project but some will be projects they have recently finished, but might have to work on again in a next revision. Because of this they will need to be constantly diligent to use symbols only from the right design system, or constantly activate and deactivate design libraries when moving between projects. As you can imagine this is not a nice experience.

Many agency designer will either not use design libraries at all, or use generic design libraries like UX Power tools to support system design work, which lead to more generic designs for their clients.

Coupling design libraries to specific designs would be a first step in making design libraries more useful for agency designers.

The other issue is creating these design libraries. Agency designers would benefit greatly from having design libraries available for them, but not every client has them, and agencies often don’t have the time or budget to create one for each project.

As a particularly motivated agency designer you could create a design library in tandem with the design you’re working on, but continuously switching between a web/mobile design file and a design system file cumbersome. Being able to "send component to design library." whilst you’re designing would make creating a design library a much lower friction activity, making it accessible to far more people.

Design libraries should become design token libraries

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).

If design libraries offered a UI to choose from the used design primitives as well as the provided symbols, then creating new components in your design would be faster and less error-prone. Which leads me to the next point:

Limit options to design tokens

The most telling UI problem for this is the color picker. By default, your favorite design tool color picker will let you pick colors from the entire RGB spectrum. The same for fonts, and the same for spacing (a literal infinite number of options there). This puts the onus of maintaining consistency fully on the designer. This is insane, because computers are far, far better at this.

My ideal design tool starts with defining these things as design tokens, and then providing those and only those as potential options. I want to toggle between my two chosen fonts, not scroll through the 2000 I have installed on my machine. I am fine choosing between 9 gradations of the primary color but I don’t want to check, check and double-check if I’m using #042d3d everywhere and not #042d3e.

When dragging components or elements across my artboard, It would snap only to values that I defined in a spacing scale. Or even better, let’s make sure your design tool implements a layout model that does this for you (More modern code-based design tools, like Modulz, already do.)

This goes one step further than design linting, an idea that is in itself severely under-developed. While design linting will tell you after the fact that something is wrong, limiting your design to options defined in design tokens will prevent you from getting to "wrong" in the first place.

Symbols are not powerful enough

Symbols (or frames, or components) have been great for making re-usable bundles of design, with implementations also getting better in assuming layout. They still don’t map well to the realities of web and mobile design.

For example, a header might be pretty different between mobile and desktop: on mobile, there might be a menu button that opens up a menu, while on desktop the entire menu is visible. Supporting both would mean having two symbols for what is, from a semantic perspective, the same thing. To make symbols map well to reality they need three things:

• Variants
• States
• Responsive variants

Variants

Your site might have a couple of different buttons. They might only differ in color, or padding, or some might include an icon and others don’t. All these variants of the same thing would ideally live in a single component. This makes updating their shared properties easier and indeed, less error prone. Some of this can be done by overrides or by making changes to instances, but that only gets you so far.

States

The need for this is again most easily shown with buttons. Buttons have a couple of natural states: they can be idle, they can be hovered and focused, they can be active (pressed or clicked) and they can be disabled. These are all instances of the same symbol and should be treated as such.

Responsive variants

I already mentioned the header situation above. My ideal symbol would allow me to set different designs and styles depending on how much available space it has. Then, when I’m using the symbol, it would just switch to the appropriate responsive variant.

As you can see, we need symbols to be editable in a couple of different dimensions. Apps like Modulz and UXPin are well on their way to support this, and I hope we’ll continue to get closer to the functionality I described above.

Grids are useless in all design tools

Modern UI design for mobile and web can not count on fixed dimensions like print design can. Why then, do the grids in design tools assume that a grid from the top left will always be what people want? Or a fixed width layout of columns centered?

Design for screens uses alignment from the borders in or from the center out. Yet no design tool I know of lets me set grids like this where depending on where an element is positioned, the grid is positioned from a different corner or position on the screen.

For example, your header with logo and menu might be the full width of your viewport, and the logo would be 10px from the top and 10px from the left, the menu would be aligned to the right, again with 10px margins. The space between these two elements is completely arbitrary, as you don’t know the full width of your site at design time. This means that, if your grid works from the top left, the navigation will only ever align by accident.

A smart design tool would let me set my grid step (like 8 pt) and then provide feedback from the nearest of the borders and the vertical and horizontal center.

Accessibility standards should be baked in

It’s the job of a designer to take every user into account. This means that they need to know about accessibility guidelines and apply them. Some of these accessibility guidelines, like color contrast or minimum font sizes, are testable by computers. Design tools should actively warn users when their text color and background colors don’t give enough contrast, or when the font size they choose is simply too small for the given screen.

To be fair, these things are slowly being implemented in design tools. It’s one of the reasons why I’m such a fan of Modulz. Still, for something that’s relatively straightforward it’s mystifying that it took so long for design tools to start adopting.

Versioning as a first-class citizen

There are a bunch of different versioning tools out there, like Avocode, Abstract and Plan. They all need some sort of manual action to version and merge changes. In Figma there are already built-in options for versioning and collaboration, and I’d like to see that become the standard. In my ideal world, versioning, branching and merging would be as easy for design as it currently is for code.

That’s my list, what’s yours?

Let me reiterate that the design tools we have available to us as designers are amazing. Still, there’s always room for improvements and I’m always looking for ways to make things better.

This article got re-posted at Fast Company.

Want to read more? Jason Miller wrote an excellent follow-up article with his ideas: Building From The Ground Up With New Design Tools.

What are things you wish design tools did, or did better? Let me know on Twitter, I’d love to hear them.