Some of the best advice I was given when I first showed interest in the web design industry was “Learn to design. Learn to develop.” Some in our industry would say that when I was given that advice, I was being directed to be a generalist. I disagree.
Why you might ask?
The reason I disagree is because I believe that in order for one to be a good web designer, they must know how to develop. In other words the advice I was given was essentially: “Learn to design for the web.”
Don’t get me wrong, I’m not saying that one has to be the best front end developer out there to be a good web designer. In fact, I work with designers that are far more gifted at design then I am, that know less about development then I do.
With that said I do believe that one needs to have at least some rudimentary knowledge of development to be a good web designer. I would even go as far as to say one must have at least some rudimentary knowledge to even be considered a web designer. This is because the very thing that separates a print designer attempting to design for the web, versus a web designer, is a knowledge of development.
Understanding Your Canvas
The reason I classify such knowledge as the defining mark of a web designer is because it is only when one has a knowledge of development, that they also have an understanding of the canvas that they are working on. It is vital for one to understand the canvas that they are working on. Why you might ask?
Take a painter for example. If they were going to paint on a canvas they would need to know what that canvas is made of, what paints work well with it, what techniques to use in relation to it, and more. If they didn’t have that knowledge, then they would have a difficult time in creating something on top of it. Their paint might not dry correctly. There might be inconsistencies in their brush strokes. There could be an endless amount of issues.
Just as a painter must understand their canvas, so must a web designer understand theirs. A web designer must understand what type of designs work better on the web then others. They must understand how the different components on the web are built. They must understand the dynamics and what causes designs to break on the web. Most importantly, they must understand their canvas as it is the key factor in deciding what workflows they use and how they approach designs. This is a massive decision and one that often either causes a project to be a success or a failure. Unfortunately we as web designers can have a tendency to miss the mark on this.
One Step Removed
In Ethan Marcotte’s book “Responsive Web Design” he talks about how we as web designers often approach our work by emulating a print workflow (3). The way we do this is we create a blank slate in our image editor of choice, define widths and heights, establish grids, and then begin to design. Once we have finished laying out all of our designs in our image editor, we send them to a front end developer. The front end developer then brings our designs into the browser.
After they are complete we begin to make lists of things that they did wrong and need to be corrected. Later when those are fixed, we open up our web browsers in our mobile devices and begin to see even more issues. We then send those back to the developer. Ultimately we end up in this endless ping pong battle of design versus development until we finally come to a satisfactory result.
As you can see this approach to web design is highly problematic and waists tons of time. We could easily try and blame the front end developers for not getting the designs pixel-perfect and for not cross browser testing, but in my opinion that is a cop out. The reason that it is a cop out is because the entire scenario could be different if we did not approach our work like a print job.
The reason we can’t approach our work like it is a print job is because while print design is rigid in nature, web design is fluid in nature. In fact web design is one of the few creative processes that allows a user to manipulate the canvas. As soon as one opens up a website in their browser window, they are able to change the size of the window, zoom in and zoom out, turn features on and off, and more. If that is the case, why are we creating our designs in an image editor and then calling our job done? I mean think about it. When we design inside our image editors, we are actually one step removed from our actual canvas: the browser window (Marcotte 3).
Own Your Canvas
When dealing with such a complex canvas, we must engage with it instead of insisting others do that for us. This brings me back to my point that when I was told “Learn to design. Learn to develop.” I was really just being told “Learn to design for the web.” This is because in order for us to not be one step removed from our actual canvas, we must engage with our actual canvas. In order to engage with our actual canvas, we must know how to develop.
I’m not saying that an image editor must be fully removed from our workflow. In fact I believe an image editor is an essential tool to a web designer. The problem occurs when we begin to treat that tool as our actual canvas. The browser window is our canvas.