Design Tools Are Unresponsive

I made these mock ups for a product I once worked on as a design lead. I was trying to design a responsive interface, so I included both mobile and desktop variants of the same screen.

Thing is, this is not responsive design.

Adding a tablet view to this would also not be responsive. Coming up with 10 supported breakpoints and then mocking up the screen at each of those specific sizes would still not be responsive.

Many designers would call that responsive. Many designers would be wrong. But that's not their fault. Designers are simply working within the constraints imposed on them.

The Inadequacies Of Modern Design Tools Top

Think of your favorite design tool. You're probably thinking of Figma, because it's genuinely amazing. Figma has given us so much, including the auto layout feature. I love that feature.

But while auto layout has been a welcome step toward responsiveness, on its own it's still insufficient for realizing truly responsive designs.

In some cases, auto layout comes super close. Especially when taking full advantage of content wrapping and minmax widths. But, compared to CSS, Figma is still lightyears away from being truly responsive. To understand why this came to be, we have to talk about print.

The Legacy Of Print Top

In the earliest days of the web, experts decided to use print as a skeumorphic analog for the web. This is where terms like page, heading, template, footer, and grid come from; among a litany of others. For the most part, and especially in the web's infancy, those terms were functional in helping people to understand the medium. Over time, they also functionally limited the design community's understanding of the web's unique characteristics.

By nature, print is a static medium. To demonstrate, take a page out of your favorite magazine, rip it in half lengthwise, and throw one half away. Did the page's original content adjust to fit on the remaining half, or did you just throw some of it away, forever rendering what's left useless? Sorry.

No matter how a printed page may change or degrade over time, the content of that page will always remain exactly where it was at the time it was printed. It is proverbially set in stone. Not responsive.

By contrast, even though we describe the web using terminology that was invented for print, it is in fact dynamic. The web is built on code that allows it to respond to myriad and ever-changing viewports, screen sizes, and devices.

If you go to a website and you horizontally resize your browser window, it's highly likely that the content will adjust to fit the size of your window. Go ahead, try it here. You can make the window any width, and the content will always adjust to fit.

That is responsive design; a single view responsive down to the pixel, rather than being limited to a predetermined set of sizes or breakpoints.

True responsiveness is usually impossible to represent using design tools because of a lack of support for concepts like relative units, calculated font sizes, container queries, and a whole lot more. Instead, designers are relegated to producing multiple different static mock ups representing the same view at different sizes, so that we might provide an engineer with enough context for them to redesign that view responsively using code.

There are three obvious issues with that approach. First, we're turning our design problem into an engineering problem by forcing the engineer to fill in the blanks themself between each of the mock ups.

Second, all of those extra mock ups are a cost center. Redesigning the same high fidelity screen two or three times before committing anything to code is, frankly, a waste of time. In the business world, time is money.

And third, we're necessarily neglecting the majority of possible experiences for our users. If an average browser window is 1024 pixels wide, and you mock up your page at 3 different sizes, you're neglecting 1021 possible experiences for average users.

Designing For The Medium Top

Designers desperately want to design responsive experiences for the web, yet our tooling requires us to design static experiences in the style of print. By carrying forward philosophies and taxonomies from the print world, our tools neglect many possibilities of this newer medium.

At the end of the day, nobody uses Figma mock ups. The more time we spend mocking things up in high fidelity using primarily static design tools, the more expensive it becomes for us to create something truly useful. Eventually, in this medium, everything must become code.

As designers, we should always be striving to create designs that are sustainable within our medium. The web is dynamic and built out of code. Where possible, we should design for that.

Use the tools that exist for the medium. Just as a painter paints with a brush, and a sculptor sculpts with a loop, and a potter fires with a kiln; so too should a digital designer prototype with code.

That doesn't mean that your prototype code needs to be production ready, or even very good. Designers and engineers are two different breeds. But designers do need to be able to adequately represent their solutions. On the web, that requires some code.