The browser is my canvas

I read this article the other day by James Stone (he has some other great articles, by the way) which talked about the importance of solving designer problems in the browser.

I loved his article, and the past week or so it’s been walking around my brain kicking things loose. If you don’t follow him (or Zurb) on Twitter, I highly recommend it. There’s some really smart people over there. I’m going to expand on some of the thoughts that it kicked up for me, and hopefully not bastardize his original idea.

Let’s Talk About Me

I started as a print designer. This was before ‘web design’ was really a thing. Design was about selling shit (still is), but it was also about taking complex or esoteric information and presenting it in a way that was easy to understand and enjoy. Web design is no different.

The people that taught me print design came from the era before computer aided design. They were used to pasteups and typesetting. Computers, to them, were not a friendly medium. If you are a print designer in 2016 and can’t use Adobe InDesign or something like it, you’d have to put air quotes around your job title. And yet, we have so many ‘web designers’ out there unable to use HTML or CSS.

If you can’t write HTML and CSS (and enough JS to squeeze by), then you’re that print designer who can’t use computers to design. This is your medium. Learn it.

I know it’s intimidating. Not only is it something you’re unfamiliar with, but it changes at a rapid pace. But you absolutely can learn it. Find a mentor. Ask advice. There are lots of people out there willing to help you learn if you are willing to take the first steps. If you’re currently employed by a company as a designer, ask them to invest in training. Find a good cause and build them a website. It doesn’t have to be fancy or profitable, my son (12) has a website he hand-coded. Buy your front-end developer beers after work and have her audit your code. Take an online course.

This is the cool thing about learning code: No one is perfect. None of the good ones pretend to be. We’re all learning, we’re mostly humble, and we’re all at different places in our learning curve. The good designers I’ve met are the first ones to put something in Slack about something new they’ve learned. They aren’t scared to look like a fool, they’re just excited to share.

I’ve worked with lots of web designers unwilling to learn, and they inevitably say that they pretty much understand HTML and CSS. If you aren’t writing your own code, you really, really don’t.

Web design is different. It requires you to have patterns and grid so that you’re not reinventing the wheel on every page. You need to be consistent and organized. You need to understand that your viewer isn’t on a 27” display and a super-fast connection. Like the good copyeditor, you have to be able to take a red pen to things you love — sacrificed in the name of bandwidth or usability. You have to understand why accessibility and user experience are important. And the strange thing is, it’s all an eco-system. The things that you’re doing for your website that make it accessible to the blind or faster to load for people on slow connections are also helping your search ratings and conversion. You won’t learn this until you’re the one doing it. And you also have to be able to make decisions based on the way code meets idea; it may have been a great idea in your head, but 200 lines of CSS and another 100 in JS later, maybe it’s not worth the bloat in your site and the drama?

Wireframing and Stuff

There’s a new wireframing tool every week. Most of them try to look like pencil and paper. You know what works better than software that tries to emulate pencil and paper? Pencil and paper. I have a notebook by my computer. That’s my wireframing tool. I generally design in my notebook, then the browser. I’m not very good at drawing, so if I can’t get a good mental idea of something in my notebook, I’ll use something like InDesign or Affinity Designer to flesh something out, but it’s always quick and dirty, never anywhere close to the look of a working comp.

This is where Mr. Stone’s article comes into play. I do this because I believe I’m a relatively smart guy (assuming I’ve had my coffee that morning), and I know the web pretty well, but I’m not smart enough to know how everything is going to play out until I see it actually play out, for real.

Wireframing tools try to emulate this, and some get pretty close, but designing in the browser isn’t exactly a long-term commitment. It’s quick, dirty, and usually the code behind the first comp is functional but embarrassing. But it works, I can see it, my client can see it, it’s fine for the short term. Nearly 100% of the time I’ll re-factor most of the code before it ships. This allows me to experiment, to see my design in its natural, presentable element, to actually go through the workflow myself, on my 27” display, my laptop, my phone, my phone on a bad connection, my daughter’s aging (dying) iPad mini, etc. It gives me fairly real-world examples of how this site will breathe.

I firmly believe that websites are organic. When I show the client their site on a development server, they can beat it up as it was meant to exist. But I also stress that nothing is final.

It’s all a work in progress until the day my client pulls my fingers off their site. I do the best I can to deliver beauty in a set amount of time, it’s never perfect, but it’s as good as I can get it. It’s common for me to completely rework a home page right before we finish the site because I like the interior pages better and suddenly the home page feels out of place. The fun thing about working on a site for a few weeks straight is that if something sucks and you see it every day, sooner or later it’ll bug you enough to fix it.

If I wireframe something, then completely deviate from the wireframe, red flags get thrown. People expect wireframes to be a blueprint. They aren’t, and they shouldn’t be. My wireframes are sketches (with actual pencil lead), because until the day they go live, that’s all they are. And to be blunt, even after they’re live, a lot of the time — most of the time — they need adjustment.

Takeaway

• HTML and CSS are quite accessible. There are lots of tools that work well for different audiences. This is one of my favorites.
• A Book Apart should be on everyone’s list Zeldman is the Shakespeare of our industry.
• There are so many bright people out there, keep looking — it may be the lady at the desk next to you who always wears those really ugly bowling shirts. Many of them are disturbingly friendly.
• Don’t get intimidated. The absolute best part about our industry is that you’ll never run out of things to learn.