Designing for the web ought to mean making HTML and CSS

During the dotcom boom back in the late 90s, I did a bunch of Photoshop-cut jobs. You know, where a designer throws a PSD file over the wall to an HTML monkey to slice and dice. It was miserable.

These mock designs almost always focused on pixel perfectness, which meant trying to bend and twist the web to make it so. Spacer pixels, remember those? We were trying to make the raw materials of the web, particularly HTML, then latter CSS, do things they didn’t want to do. Things they weren’t meant to do.

Then I got the pleasure of working with designers who actually knew HTML and CSS. It was a revelation. Not only would the designs feel like they were of the web , not merely put on the web , but they’d always be better. Less about what it looked like, more about what it worked like.

I attribute this in no small part to the fact that it was real. The feedback loop of working with the actual HTML/CSS, as it was destined to be deployed, gave designers the feedback from the real world to make it better. And the fact that designers had the power to do the work themselves meant that the feedback loop was shorter. It wasn’t make a change, ask someone else to implement the change, ponder its effectiveness, and then repeat. It was change, check, change, repeat.

For a while that felt like it was almost the norm. That web designers confined to the illusions of Photoshop mocks were becoming more rare. And that web designers were getting better at working with their materials.

But as The Great Divide points out, regression is lurking, because the industry is making it too hard to work directly with the web. The towering demands inherent in certain ways of working with JavaScript are rightfully scaring some designers off from implementing their ideas at all. That’s a travesty.

At Basecamp, web designers all do HTML, CSS, and frequently the first-pass implementations of the necessary JavaScript and Rails code as well! It means they get to iterate on their design ideas with full independence. In the real app! Quite often, the JavaScript and Rails code is even plenty good enough to ship, and we do, after a brief consultation with a programmer.

Other times the programming work is more involved, and a dedicated programmer will pair up to ship a feature. But I cannot tell you how much nicer it is to work with designers who know the constraints of the web, and can do the work of the web, than the alternative. When you overlap on the fundamentals, you’re on the same page more frequently than not. (Though we still trade concessions!)

Did we just happen to find impossible unicorn designers? Maybe, I guess? Likely? No. Scott, JZ, Conor, Jonas, Ryan, and Jason all grew into the designers they are today by putting in the work to get there. By not facing the damnation of low expectations or this-is-too-hard-for-them bullshit.

Now some of that is also tied to how we work with the web. Basecamp is famously – or infamously, depending on who you ask – not following the industry path down the complexity rabbit hole of heavy SPAs. We build using server-side rendering , Turbolinks , and Stimulus . All tools that are approachable and realistic for designers to adopt, since the major focus is just on HTML and CSS, with a few sprinkles of JavaScript for interactivity.

And it’s not like it’s some well kept secret! In fact, every single framework we’ve created at Basecamp that allows designers to work this way has been open sourced. The calamity of complexity that the current industry direction on JavaScript is unleashing upon designers is of human choice and design. It’s possible to make different choices and arrive at different designs.

One thing is for sure: I’m not going back! Not going back to the dark ages of designers incapable of making their designs work on their own, incapable of making direct changes, and shipping them too!

Also not interested in retreating into the idea that you need a whole team of narrow specialists to make anything work. That “full-stack” is somehow a point of derision rather than self-sufficiency. That designers are so overburdened with conceptual demands on their creativity that they shouldn’t be bordered or encouraged to learn how to express those in the native materials of the web. Nope. No thanks!

Designing for the modern web in a way that pleases users with great, fast designs needn’t be this maze of impenetrable complexity. We’re making it that! It’s possible not to.