They’ve never been faster.

They’ve never had more UI design-centric features.

They’ve never enabled more effective collaboration.

But design tools are still holding us back. Our tools are still using methods, workflows, and features from graphic and visual design.

I get it though. A lot of UI designers come from that background. But we still talk about UI design like we’re making art. We use terms like “canvas” and “artboard” like what we’re doing will hang on the wall of a museum some day behind a red velvet rope.

But it won’t.

Heck, we’re lucky if anyone will even want to look at the UIs we’re making in 6 months. We need to stop treating UI design like art. Yes, it can be pretty. Yes, it a visual medium. Yes, there is an art to making digital products. But it’s not artwork. I’m wading into territory that would merit a separate article, but the aesthetics of your UI should not come before their usability. We need our tools to stop using manipulation methods that emphasize looks over structure. We need better ways to make real products, not pretty mockups.

Increased collaboration helps with that. Features that help make new concepts help with that. But as long as tools keep ignoring the digital medium, implementation will continue to conflict with our mockups.

For starters:

We need the box model

The box model is the basic building block for UI. It’s everywhere. Right-click on this sentence (if you’re on a desktop computer), select, “inspect”, and start hovering your mouse around in the ‘elements’ area. You’ll see a bunch of rectangles appear on the page. That’s the box model.

It provides the structural rules for this page, and every other website. In it, every element has a definition for its size, and how it behaves on the page. It’s the air to the proverbial UI balloon that you’re now gazing upon.

Things push each other. Things have a size. Things share space. With it, websites and apps are a big ol’ game of Tetris and the box model is what determines the size and shape of the blocks.

BUT DESIGN TOOLS DON’T HAVE IT.

WHY.

FOR THE LOVE OF GOD WHY.

We drraaaaaaag things around. We nuuuuuuuudge this and that. We align vertical, center, left right up down, in out by tippity tap tap taping our trackpads to our heart’s content.

But, as far as our tools are concerned, we may as well be sliding sheets of paper around a table. Stacking them on top of each other until, from the bird’s eye view, everything looks juuuuuuuuuust right.

But it’s not how things actually are.

In code, almost everything that takes up space pushes something else out of that space. As I write this sentence, the paragraph gets bigger. As this paragraph grows, the section that it contains gets taller. As that section increases in height, the other sections push further down the page. As they push the page, the page itself gets taller. If I were to do this in a design tool, my frame/artboard would have no idea about the text being longer. It would stay the same size until I drag its bounding box. This is asinine.

If this was box model, the black box in this gif ☝️ would push down as the text grows and the parent frame would get bigger. Word documents have been able to do this for DECADES. Why do all elements in our design tools behave independently from each other? This is great for photo editing, print layouts, and illustrations, but not for UI design.

To add insult to injury, this lack of functionality has led to a pervasive ignorance of what the box model is… which is a bit mind-blowing. I hear the same phrase from designers: “I don’t understand why my designs aren’t developed like the mockups”. One of the main reasons for that is the total separation of the tooling from the medium we’re designing for. HTML and other UI constructs are not a freeform canvas. But that’s all we’re used to…

Would an architect be able to design without knowing the limitations of construction materials?

Would a car designer be able to make cars if they stopped with the clay model?

Other design industries take the time to understand their medium and end product. In their work, there is a clear distinction between concepts and comps. It’s time that digital product design tools helped create comps that emulate the digital medium. It’s time for them to stop using manipulation methods that were born in the print industry.

Inheritance and relationships

No element exists in a vacuum. In the web, elements have a relationship to one another. Some act as the containers for elements. These are parents. This page is a parent, this paragraph wrapper is a parent, and it is a sibling to the paragraphs next to it.

Let’s say this Medium article lived in a design tool, and I wanted to change, say, the font size and color. What would I do? Would I update a shared style? Hmmm maybe, that’s a start. Would I select this paragraph and change its attributes? Yeah, that would do it. But neither of those are how it should/could be done if our tools had inheritance principles.

If you inspect this page right now (right click, select inspect), you’ll see that there’s an element called <body> at the very top of the html tree. If you click on it, you’ll see something like this:

That’s a lot of font fallbacks…

The body, which is the parent of the whole page, is functioning like the artboard/frame in a design file. But, it’s very different from those because it has its own attributes. It defines the font, font color, font weight for the whole page.

Now, click on the black box next to “color” and you’ll get a color picker. If you change the color, you’ll see that this entire post changes with it.

This is because none of the text on this page actually has a color, but is rather inheriting it from the page itself. Pretty easy, right?

Design tools don’t do this. They make you to define it at the element level. Why does this matter? Well, imagine that you want to change your site to a dark mode. If design tools worked like this website does, you could select the artboard/frame on the page, and change the background color to something dark, and the text color to white. If the child text didn’t have its own attributes, you could be looking at dark mode in only a few clicks. You could duplicate the page and see what different configurations do to identical content.

Here’s how that might work:

👆Made in webflow

The same trick could work for seeing how your UI looks if the user had a large font size. If the text size was inherited from the artboard/frame, all you’d have to do is make it larger in one place, as I show in the example gif.

The beauty of this method is that you can still define things at the element level. If you try to change the font weight or size in <body> nothing will happen. This is because individual elements always supersede the parent’s styles. If you want to be granular, you can be granular. If you want to be global, you can be global.

I dream of a day where I open my design file and can define attributes at the frame, canvas, project, and even the global team layer.

Inaccurate handoff

Gotta admit, I struggled coming up with an illustration for this one…

I’ll come out and say it. The CSS that design tools generate is useless.

I used to think it was cool. I’d think things like “Hey, my devs will love this. It’s actually making CSS. Woooooow!!”.

But it’s not.

I mean, yes, it is technically making CSS, and it’s not that it’s got syntax errors or things like that, but let’s be real. If you don’t have a box model, don’t have parent <-> sibling relationships, and you don’t have element inheritance… you’ve got ignorant code.

Why is it even there? Sure, maybe it helps someone figure out the weird round corner-ness or copy a hex code quickly, but that’s about it.

It’s lulling designers into a false sense of security and contribution.

Here’s an example design:

Imagine that I handed off this 👆 glorious and totally original mockup to a developer. It’s straightforward to build, but here’s 👇 the CSS I’d have to write on the left, and the CSS from Figma that I actually used on the right: