What I wish I’d known when I started web design

My teacher, David Bieloh, asked me to put together some advice and it I ended up writing this behemoth. Below is a bit of useful information I’ve picked up along the way. You’ve probably heard some or much of it before.

But before you start reading through my rambling, stop reading this right now. Go purchase and read Design is a Job. Don’t come back until you finish.

Back? You finished it?

Liar.

I don’t care what industry you’re in, Design is a Job is filled with incredibly useful insights and tips. Also, you’ll get paid more if you read it. If you plan on going into web design, I also highly recommend the entire A Book Apart series.

Which brings me to my next point.

Read. Often. Every day. Spend an hour or so catching up on various industry news sources. Follow lead developers of products you love. Subscribe to design blogs. Two of my favorites around web design are CSS-Tricks and A List Apart.

Practice. All the time. You don’t have to build crazy websites or full-fledged portfolios all the time. Think smaller. How would you code that nifty menu idea you saw on dribbble? Could you code a logo with only HTML and CSS? I highly recommend playing around in CodePen regularly. Fork someone’s work. Play with their code. Make it your own.

Tools change. Don’t rely too heavily on any tool and learn to use new tools quickly. I would avoid using tools that create proprietary files if the tool isn’t super common. Collaboration with your peers can become tricky.

Web design is problem solving and can be super addictive once you start getting into it.

Real world best practices (maybe)

Work doesn’t stop at 5. Or 6. or 2am. You’ll find yourself mulling over various design problems while trying to get some sleep. You’ll often find yourself working at odd times or at bars or wherever. Sometimes, you just have to get an idea down.

Go to sleep. Seriously. We all think we’re brilliant at 1am. Then we wake up with a design/code hangover in the morning and realize we have to redo several hours of work. AND we’re now tired from staying up late.

Go for walks often. Leave your phone.

Say no. Often. It’s an awesome word. Just because someone is willing to pay you to do it, doesn’t mean it’s a good idea.

Google often. Seriously. Almost every question you can think of has an answer on Google. Super handy when trying to figure out how to do that cool thing you saw that one place that one time.

Tell a story. When designing an interface, you’ll need to work out the story of what a user experiences when going from point A to point Z. Pay attention to every tiny detail. In web design, if something can go wrong, it will. For sure.

Users sometimes act drunk. Design for it.

Twitter. Start chiming in on conversations with your design heroes. More often than not, they’ll start talking back.

Take typography very seriously. Or I will find you.

Eat dog food… or whatever that metaphor is. If you’re designing for an iPad, freaking use an iPad all the time and learn its idiosyncrasies. If you’re going to design a healthcare website, use it a bunch of times, first.

One single monitor is usually better for getting things done. You’re forced to ignore your precious Twitter feed or Tumblr or whatever your internet poison is and focus on one task.

Users sometimes are drunk. Design for it.

Don’t redesign someone else’s work and expect praise. You weren’t there for the client meetings or design process. Imagine if I redesigned your site and told you how much better I thought it was. Make your own cool thing instead.

Be super flexible. Different clients have varied code standards. If you think yours are better, approach them about updating their standards extra politely and with solid reasoning. If they say no, deal with it.

Use the same avatar everywhere.

Don’t use Sharepoint.

Your process will always feel like chaos. Don’t panic. Relax and keep moving. You’ll get it done.

Go with your gut. Design something quickly. See if it works.

Web design do’s and don’ts

Here’s my fairly opinionated list.

• Be aware of accessibility.
• Code semantically
• Use responsive web design
• Design in a way that is future friendly
• Use Paul Irish’s box-sizing
• Use version control
• Use SVGs when you can
• Use icon fonts
• Use web fonts!
• Minimize the number of file requests (one stylesheet, sprites, etc)
• Use sprites
• If you’re going to try a preprocessor, use SCSS instead of LESS (although they both rock)
• If you’re using SCSS or LESS, use CodeKit (my favorite) or Grunt
• Minify everything
• Compress and optimize your images
• Use the heck out of your browser’s inspector
• Document everything
• Comment your code
• Break your website
• Design from a mobile-first perspective
• Get familiar with Open Source projects
• Use retina image techniques
• Gradients can be cool
• But I like flat stuff, too
• Make lists to keep track of all the little things you need to do
• Use em units

• Don’t use dark patterns
• Don’t use CSS3 for layout
• Don’t use Flash
• Don’t use parallax
• Don’t use too many web fonts
• Don’t overcomplicate your CSS selectors
• Don’t use IDs in CSS (they become tricky to override and are really unnecessary)
• Don’t forget to cite your sources
• Don’t sin
• Don’t break your system fonts (seriously. It’s a pain to fix)
• Don’t listen to all my advice. I’m totally a hypocrite.

Stuff teachers never tell their classes

Don’t work for free. For anyone else. Ever.

Be an asshole. Seriously. Be the person who tells the client they are wrong before thousands (millions?) of dollars are thrown away.

Design for good, not evil. Avoid dark patterns. Don’t let your client convince you tricking someone is a good thing.

Don’t put crap in your portfolio. No matter how long it took you, don’t do it. Just leave it in your secret hard drive of embarrassing work that you hide in your cabinet.

If you only have one awesome comp, only show the client one. Otherwise they will be drawn to your worst work like a magnet. It’s no fun to work with your second favorite logo.

Be damned confident. You were hired to be an expert designer. You don’t second guess your accountant or lawyer. Don’t let your client second guess you.

Don’t ask for opinions. Be smart with your questions. Ask if something works or doesn’t. It really doesn’t matter whether your client likes pink. Most of the time they aren’t the user.

Clients are good people. Really.

Sometimes you have to go with what you have. It may not be perfect, but it’s better than nothing. Your next project will for sure be cooler.

People that use IE8 and lower often have no choice in the matter. Don’t tell them to fuck off by ignoring them.

Stick to your process. Whatever it is. If it works, don’t let a client convince you there’s no time for it.

If something doesn’t work, delete it. I love deleting things from interfaces. One less confusing menu is one less confusing menu.

People thank customer support for helping them renew a domain. They do not thank you for designing a perfect website.

Have a freaking contract.

Code always feels messy when you’re done.

Teachers Google most of your questions. (Except Bieloh (He Bings your questions))

My Process

Research is the single most important part of your entire process. You’re going to be solving a problem. It helps to know what the problem is inside and out before you can fix it. Just Enough Research (another A Book Apart book) goes fairly in depth about how freaking awesome research can be. Research is your secret weapon and you should never EVER skip it. For any reason. Cut other parts of the project before you cut research. It’s extra handy to have evidence to show the client why their website doesn’t need a spinning logo. (I totally built a website with a spinning logo and it’s awesome.) Research can include anything from building personas to data gathering to usage information to design inspiration. It’s pretty open.

From here, you can lightly skim. There’s not much you haven’t already been told here.

I do a gagillion thumbnails and wireframes. I prefer to do them by hand on pretty much any paper nearby (often envelopes or the back of mail). Others I work with prefer wireframe apps like Omnigraffle. I then do a bit higher fidelity wireframes on my laptop and walk through interface use.

It’s at this point I like to go back and forth with my partners in crime to get feedback from those close to the project. I don’t let the client see this stuff just yet.

Here’s where a ton more iteration can happen. Make sure you think of as many things as possible along the way. Remember, you’re telling a story. Make sure it’s a logical story to follow.

Once you get a cohesive and handsome set of wireframes designed, it’s time to present them to the client. In person if possible. Skype works, too. Do NOT email the client and wait for feedback. Walk them through a user story. Explain your thinking and your decisions. You may even show them some style tiles if you’ve gone that far.

From here, there’s no set path. If you rock at coding, mock it up in code. If you’re not so hot (yet), go ahead and make the world’s most comprehensive, pixel-perfect, and well-labeled PSD (or Sketch if you’re into that kind of thing). You’ll then want to hand it off to your front-end designer or coder and work with them to flesh it out into a sweet mockup. Iterate a bunch more. Get it right.

Once that’s done, again, meet with the client and walk them through it. Again, ask specific questions to produce useful feedback. Avoid, “How do you like…” questions or “What do you think of…” Have your research handy if they ask why you made design choices.

Then it’s time to build out the whole shebang. Sometimes this involves quite a few people. Your job is to make sure no corners are cut and everything goes as planned. Don’t step on toes, but do keep an eye on things. You will also be iterating here and making sure the menus are nice and smooth on phones and the buttons look right in IE8.

If there’s something I missed or I should add, let me know!