What follows is a transcription of Has Design Become Too Hard?, which I wrote for Communication Arts in June 2016. I transcribe it here against the day CA takes down its content.
WE DESIGNERS love to complain. It’s our nature. After all, if we were satisfied with the way things work, feel, and look, we wouldn’t have become designers in the first place. But lately, particularly among web and interaction designers, our griping has taken on a grim and despairing flavor. Digital design is not what it used to be, we say. The fun has gone out of it. An endless deluge of frameworks and technologies has leached the creativity out of what we make and do, and replaced the joy of craft with a hellish treadmill of overly complicated tools to master.
Many of us feel this way, but is it true?
Consider responsive web design, proposed six years ago (video) by Ethan Marcotte at An Event Apart, and subsequently turned into an article and then a book. In twenty-plus years, I’ve never seen a design idea spread faster, not only among designers but even clients and entire corporations. Companies brag about having responsive designs for advertising, for crying out loud. Yet, after a euphoric honeymoon, designers soon began complaining that responsive design was too hard, that we’d never faced such challenges as visual people before. But haven’t we?
In the early days of web design, beginning in 1995, pixels were not standardized between PC and Macintosh; monitor aspect ratios were not standardized, period; and when we got a standardized layout language for the web, every browser supported it differently for years.
We tried “liquid layout” to work around the fact that every monitor was different. Our clients demanded we put everything above the fold, and we acted as if there was one—a consensual hallucination, when there were as many folds as there were screens, browsers, and user-adjustable settings.
Later, when standards were better supported in browsers, some of us pretended that “everybody” had a 600 x 400 monitor (and then an 800 x 600, and then 1024 x 768), but these too were consensual hallucinations. And even in those rose-colored fixed-width days, there was always a client or a QA tester whose user preference settings, outdated browser, or wonky operating system blew our carefully constructed fixed-width layouts to hell.
THAT’S WHY THEY CALL IT WORK
Good design was never easy. The difference between now and then is that today, instead of pretending or wishing that everyone used the same platform with the same settings to view print-perfect digital masterpieces, we acknowledge that people will access our content however they choose, and with whatever device they have close at hand—and we design accordingly. For the first time since people first argued over how to pronounced “GIF,” we’re designing with the medium instead of against it.
Designers say, “okay, I’m down with responsive design—in a world of phones and watches, I have to be—but today’s code is too hard.” Yet is it? And was it ever easy?
At the web’s beginning, we wrote gibberish markup, using table cells, spacer pixel GIFs, and chicken wire to rig our digital design experiences together. Then came what many think of as a golden age, when browsers supported web standards well enough that we could use them—and nothing much changed in the browser universe for years, meaning that once we had mastered our CSS, HTML, and maybe a little JavaScript, our education in the front-end design department was complete, and we would not have to learn much of anything new.
DESIGNING INVISIBLE STRUCTURES
That has changed, to be sure, but not the way you may think, and not for the worse. Certainly there are a few new elements in HTML5 to learn—elements that add structural semantics to our content precisely when we need them. New elements like aside and article are perfect for a world in which we aren’t designing “pages” so much as systems, and where we’re taking an increasingly modular approach to design as well as content. New standard tools like Flexbox enable designers to separate content from presentation at the atomic level, which can be extremely beneficial to our clients and (more importantly) to the people who want to read and interact with their content. For an example of how this works, turn, again, to our friend Ethan Marcotte, who wrote about this very thing in November of last year.
You should read Ethan’s article, but here’s a quick summary of what he did. In redesigning a large content site, he first focused on creating a host of tiny, reusable patterns—such as headline, deck, and thumbnail. Several of these headline, deck, and thumbnail units were combined into a “teaser” module that promoted internal content elsewhere in the site, a common design pattern on media sites. Ethan then wrote markup based on the pattern he had visually designed—just like we all do.
But then came the fresh insight: what if a user doesn’t access the site’s content the same way Ethan does? For instance, what about blind or low-vision users who navigate web content as non-visual hypertext? Would the HTML structure Ethan had designed work perfectly for them? Or could it be improved?
It turned out the design of the HTML structure could be modified to better serve folks who browse content that way. As a plus—and this almost always happens when we design with the “stress case” user in mind—the site also worked better for other kinds of users, such as folks who access content via watches (on the high end) or not-so-smartphones (on the low end). In the same way you design visual elements to guide people through an experience, you can (and should) design your markup to create a compatible experience, even when this means the HTML does not follow the same order as the visual stream. HTML5 and Flexbox helped Ethan make better design decisions.
THAT FEELING OF INADEQUACY
Okay. So HTML is a bit richer than it used to be. And CSS is more powerful. But does a designer need to learn a lot more than that? Must you master Sass? Must you use Bootstrap or other frameworks? (For this is the source of many designers’ anxiety.) The answer is maybe … and maybe not.
Maybe if you’re specializing more and more in front-end code, it makes sense for you to learn Sass, as it gives your CSS superpowers and makes updating your code easier. For instance, when a client changes their brand colors, it may be easier to change one instance in Sass (and have Sass update all your code), rather than hunt-and-peck your way through hundreds of lines of CSS. Obviously, many designers have adopted Sass because of these benefits. Less obviously, some equally brilliant designers have not. We judge designers by their work, not by the tools they use to do that work, right? If learning something new excites you, go for it. If it’s causing undue anxiety, don’t force yourself to learn it now. You are still a good person.
As to frameworks like Bootstrap, they’re great if prototyping is part of your team’s design process—and in the world of apps, it surely should be. Such frameworks make it very easy to quickly launch a working design and test it on real human beings. But after a few iterations have improved your design, it’s time to dump Boostrap and code from scratch.
That’s because launching sites and applications based on Bootstrap or any other heavy framework is like using Microsoft Word to send a text message. Lean, performant sites—the kind smartphone users love (and desktop users love, too)—rely on tight, semantic markup and progressive enhancement: a fancy phrase that means everything works even in crummy browsers or when there is no JavaScript. And progressive enhancement is just not baked into any popular framework. The frameworks are huge, and heavy, and come with an expectation that the user has access to “the right” browser or device, and that everything works. Whereas in the real world, something is always breaking. So whether you use a framework as part of your design process or not, when it’s time to go public, nothing will ever beat lean, hand-coded HTML and CSS.
That’s a truth that hasn’t changed in 20 years, and probably won’t change in our lifetimes.
So relax. Quit tearing yourself down for not knowing every framework that’s out there. Stop worrying about where the fun went. And go design something useful and beautiful. Same as you always have.
