Modern design tools–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, and the tools are not helping us with the considerations and trade-offs that designers have to make in 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 a half-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 about using symbols only from the right design system, or they must consistently activate and deactivate design libraries when moving between projects. As you can imagine this is not a nice experience.
Many agency designers will either not use design libraries at all, or use generic design libraries like UX Power tools to support system design work, which leads 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 is cumbersome. Being able to “send component to design library” while 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 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 2,000 I have installed on my machine. I am fine choosing between nine 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 art board, 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, a process for flagging potential problems and an idea that is itself severely underdeveloped. 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 reusable bundles of design. 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:
- Responsive 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.
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.
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 supporting 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 a logo and menu might be the full width of your viewport, and the logo would be 10 pixels from the top and 10 pixels from the left, with the menu aligned to the right, again with 10-pixel margins. The space between these two elements is completely arbitrary, as you don’t know the full width of your site when you’re designing. 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 at 8 points) 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. Still, for something that’s relatively straightforward, it’s mystifying that it took so long for design tools to start adopting it.
Versioning as a first-class citizen
There are a bunch of different tools for versioning, which allows you to create multiple models of the same product, 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.
Kilian Valkhof has over 15 years of experience running a web agency and working with everyone from startups to multinationals. He is currently working on a browser for web creators called Polypane, and he runs the company Firstversionist. He blogs about design and technology on his personal website, kilianvalkhof.com and is on twitter as @kilianvalkhof. This essay was adapted with the author’s permission. Read the original here.