Design Tools Are Unresponsive

Here are some mock ups for a product I once worked on as a design lead. I was trying to design a responsive interface, so I mocked up a mobile and desktop variant 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 with the tools available to them.

The Inadequacies Of Modern Design Tools Top

Think of your favorite design tool. You're probably thinking of Figma, because it's been genuinely life changing for most product designers. Figma gave us the auto layout feature, and I love the auto layout 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, designers used print as a skeumorphic analog for the web. This is where terms like page, heading, template, footer, and grid come from. 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 content of that page magically adjust itself to fit on the half that's left, or did it just become utterly useless as anything other than kindling? 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 magically adjust itself 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. No matter the size of the viewport, the content just fits.

True responsiveness is usually impossible to represent using design tools because of a lack of support for fundamental web concepts like relative units, calculated font sizes, container queries, and 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 between each of our 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. More on that later.

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, that makes 1021 neglected experiences for average users.

Sometimes, a user might even decide to situationally view your design in split screen, or on a mobile device. Screen real estate can unpredicatly be chopped in half in an instant, and expanded back the next.

Designing For The Medium Top

Designers want to design responsive experiences for the web, but our tooling requires us to either spend an unsustainable amount of effort on delivering partial responsiveness, or 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, if we're designing something meant to be usable on the medium of the web, it must become code.

At risk of echoing the oft mocked "learn to code" sentiment, I do think we should 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. As emergent technologies like AI mature, that becomes increasingly easier for designers to achieve.

That doesn't mean that your prototype code needs to be production ready, or even very good. I'm not advocating that designers should become engineers instead. But designers do need to be able to adequately represent and express their solutions. On the web, that often requires some code.