Category Archives: Design

Why Designers Should Learn to Program

A common question I get from fellow designers is, Should I learn to code? My usual response is, Go away, I’m on Twitter. When they just stand there, stone-faced in complete defiance, I answer Yes, I think you should learn to code, but, maybe even more importantly, you should learn to program.

Not all coding is programming

You may be thinking coding and programming are the same thing. You may also be thinking I’m a complete idiot. That’s fair (albeit somewhat hurtful). To clarify what I mean by learn to program, let’s first examine what most designers’ definition of coding is.

Usually, Should I learn to code? means, Should I learn how to build web pages? There’s actually not much programming that goes into building typical web pages; content is wrapped in HTML tags, styled with CSS, uploaded, and then the client makes it rain. You should’ve laughed at that last step.

The idea of coding a web page is concerned with markup, or a predetermined language that’s wrapped around content. The predetermined language for the wide wide world of webs is HTML, or HyperText Markup Language. A content reader, in this case your web browser, reads this markup to understand the content’s purpose and displays it accordingly.

Even if your job title doesn’t have Web in it, being able to read and write HTML today is a viable asset, especially with more and more things connecting to the web. So go learn you some web speak. Programming, on the other hand, tends to be a bit more involved.

Excuse me stewardess, I speak computer

Programming is a specific form of coding wherein a programmer actually talks to the tiny microchips living inside your computer box and bosses them around to do stuff. That’s a gross over-simplification, but I’m all about gross over-simplifications. The main difference between markup and programming is that markup (i.e web markup) mainly deals with defining content, whereas programming deals with writing instructions and memory allocation and cool hackery stuff.

But Ryan, you ask, why would I want to learn computer speak? That sounds difficult…

Simply put, programming, like design, is all about problem-solving. The skills necessary to build a viable grid system are the same skills necessary to build a function that searches for a name inside a list. There is an agreed-upon purpose. There are multiple variables. There are algorithms involving multiple condition sets. Everything has to gel. The only main difference is the vocabulary.

If you want to grow as a designer, you need to constantly sharpen your problem-solving skills. Learning to program can provide a great opportunity to grow those skills, free from the pressure of having to deliver something “great.” You’re not a programmer, so no one’s expecting you to turn out Halo 8 or whatever the kids are playing these days. You’re free to grow through success and failure on your own terms.

Programming can also be empowering. I remember sitting in front of my TV when I was a kid, playing Super Mario World on my SNES and thinking, I really would love to make stuff like this, but it’s probably too difficult. That all started to fade away the day I built a simple side-scrolling game with JavaScript and HTML. It helped me realize that nothing, given enough time and discipline, is too difficult to achieve (okay, within reason; I’m not going to go out and become the Queen of England or anything like that anytime soon).

Learning to program is tough

I’m not going to lie. Programming can be intimidating. There are files to install, manuals to read, and then there’s the dreaded command line(!). There are a whole bunch of un-designer-y things you have to deal with. When most designers are confronted with these barriers, they immediately throw up their arms and quit. That was my story. But stick with it, and you may be surprised what you can achieve.

We choose to…do…things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills

-John F. Kennedy

If it’s worth accomplishing, it’s rarely easy. The idea is to push through your discomfort. The more you learn, the easier it will be to learn even more.

Learning to program isn’t as tough as you might think…

Programming is hard, but I’m willing to wager it’s not as difficult as you might think. Don’t believe me? Go to JSBin, and in the window labeled JavaScript, type the following:

console.log('Hello, world!');

then, click Run in the Console window. It should (hopefully) cheerfully greet you with a “Hello, world!” Congratulations, you’re now a programmer! High fives all around!

Okay, there’s a lot more to programming than printing a statement to the window console, but you get the idea. Don’t let your perceptions and assumptions hold you back from growing in a skill that will benefit you in many ways.

Start out small. Build up slowly.

Learn to program for free

While there are fantastic for-pay resources, you can learn to program for the low low cost of absolutely free. I’m currently taking a Computer Science course from Harvard University, which, when I say it, sounds completely awesome (there is are verified options, ranging from $99 to $2200, in case you want a certificate or actual college credit). It’s challenging, fun, and insightful, all in one (it actually makes me wish I had applied for Harvard back in the day, but that’s another post altogether).

The venerable Codecademy and Khan Academy are two other juggernauts in the realm of free education that offer great resources for programming. Might I suggest giving their JavaScript tracks a try. JavaScript is a fairly easy language to jump into. There’s no compiling to be done, and there are tons of online sandboxes that can help you realize your programmed creations instantly.


Programming is a skill every designer should learn. It develops problem-solving skills, refuels one’s creativity, and can be incredibly empowering. Programming is tough, but the more you excel in it, the more you become comfortable with pushing your comfort zone, and the more you will learn. Programming’s tough to master, but it’s not as tough as you may think it is.

Designers often pride themselves in thinking (and acting) outside of the box. Take a chance by doing something outside of the norm. A life lived in comfort is a life not lived.

Just Make It Work

Since beginning a new web app project, I’ve learned a thing or two about product design. I wanted to take a few minutes to share one of the most important lessons I’ve learned: Just Make It Work.

You’ve been there. You have the best intentions to start a new project. Maybe it’s something that is a personal passion. Maybe it’s something that will make your life easier. Maybe it’s something that will get you recognition. Whatever it is, no matter your intentions, there’s always the danger of dropping the ball. I’m sad to admit this has more often than not been the case for myself.

This makes what just happened yesterday that much more exciting to me. I’ve finally finished the first working prototype of my app’s main email module. It’s great to say that. And yet, it’s certainly not what I envision for this product.

While exploring the product architecture of the app, I began to realize the full scope of what I wanted to build. I began to realize this was a much larger product than I initially predicted, and I froze. I couldn’t figure out what to work on first. Meanwhile, it was taking me fifteen minutes to put together a list I could’ve easily typed into the body of an email.

It was during my daily list-making that I got a revelation: build a prototype of the email module that just works. It would need to be something that could grab a JSON file, display it in the browser, allow me to perform CRUD operations on the data, and then save the new JSON file over the old one.

I didn’t worry about aesthetics. It’s not grotesque looking, but it certainly isn’t winning any beauty pageants. I didn’t worry about experience design. There are more rough than smooth edges in this prototype. What I focused on was the exact minimal requirements I needed. The result is a finished product that I can now use to inform the design of my final app.

If you feel like you’re stuck on a project, what’s the absolute bare minimum you need to meet your goal. Build that and use it as a starting place.

Art Equals Work Redesign

I’m constantly looking for inspiration for the redesign of FDGB. Nathan Ford’s recent redesign of his blog, Art Equals Work, and his consequent breakdown of the process, are proving invaluable to me.

Nathan emphasizes the Mark Boulton school of Content-Out Design. Basically, you start with and design around—gasp—the content. I know, I know. Novel approach, right? As rudimentary as that might seem on the surface, it’s an important concept to grasp in the pursuit of truly responsive design.

In the world of print, the page dimensions determine layout. On the web, there are no natural fixed-dimensions. The page is whatever size the user wants it to be. That’s why the content becomes so important, and Nathan clearly articulates this as a guideline for the redesign:

“I write about web design, CSS, and other not-so-wild topics. To match [the content], this site should employ a grid system that’s quietly varied; balanced, but with the ability to give the content of posts uniquely expressive typography.”

This knowledge of content purpose helps clearly define objectives and maintain design focus. You must know all the variables in order to account for them.

Another interesting feature of this redesign is the use of ratio-based columns rather than the more common fixed column approach. I feel like it lends the design a sense of the organic.

Go check out his blog right now. And while you’re at it, add it to your bookmarks. He publishes some fantastic content.

Atomic Design and Pattern Lab Part II: Design

I wanted to write a quick update on my latest website design project. I’ve been working on a redesign of my wife’s website on and off for a bit now and have found that I keep bouncing back and forth between designer and developer, designing static element collages in Photoshop and coding out components in Pattern Lab. This seems to be the optimal workflow.

The thing I’m having the most difficulty with right now is that I’m using a lot of the Sass files that come with Pattern Lab, rewriting as needed. This may or may not be the best approach. The pros include getting to see a well-designed and maintained example of BEM notation as well as a look at a wonderfully organized Sass include structure. Lots to learn from there.

What I get hung up on is that it’s somebody else’s code, and no matter how beautifully well-done it is, it’s hard to wrap my head around what’s going on when I’m not producing at the same level of code. I know this will get easier in the long run, but for now, it’s a bit slow-going. I may just download another instance of Pattern Lab, start from scratch in my current build, and just refer to Brad’s files for Sass organizational inspiration. The beauty in having no deadline and an understanding client make it easy to experiment with these sorts of things.

Coming from a print world, I’m certainly much more comfortable in Photoshop. I’m using PS as a way to demo looks and feels rather than comping an entire website. I’m more interested in animations and transitions from different browser and device widths. Photoshop allows me to just build the look I need quickly, and speed is what I’m more interested in at this point. But only after tons and tons of hand drawn sketches.

So that’s it for now. I may or may not start to post some images of my sketches. I’ll have to check with the client.


Designing with Atomic Design and Pattern Lab

For the past few weeks, I’ve been redesigning my wife’s website using a process called Atomic Design.

Atomic Design is the web design philosophy that sees individual elements of a website, e.g. an input (<input>) or paragraph (<p>) element, as atoms that can combine to form molecules (e.g. a search or contact form), which then combine to form more complicated organisms (e.g. a site header or footer), which then combine to form a page. Brad Frost, a super-smart front-end developer whose blog I frequent and work I frequent, coined the term.

Pattern Lab is a tool created by Brad and the (also) super-smart developer Dave Olsen to help streamline the process of showing the design to clients. You can learn more about it from several sources across the world wide web.

I mention all of this because I’m curious to see how different people are using Pattern Lab in their workflow. And with that in mind, I want to publish some posts about my experience with Pattern Lab. I hope they can be informative, and with a little luck, maybe I can learn more about it as well.

Do you use Pattern Lab? Leave a comment and let me know how you use it or any thoughts you have about it. I’m all ears, figuratively speaking, of course.

Do you want to use Pattern Lab? You can start by downloading the files on Pattern Lab’s site and reading the docs. Enjoy.