The Case Against Code

by Stuart Thursby

By trade, we are graphic designers. For the most part, that means that we do a bit everything; we work in print, we work on the web, we work with outdoor; we work with interactive. In short, we work with whatever needs working on to get the message across. Because the point isn’t the methods you use to convey a concept, the point is the concept itself.

Good. Now that we have that blatant truth out of the way, we can move on to the topic of the day: screw code.

I’ve heard graphic designers of all levels complain about how their Photoshop mockups were completely eviscerated in the development stage. Not only have I heard it, but I’ve been there and done it: coding a website introduces inherent realities which a Photoshop document cannot account for. As a result, I’ve found myself (and I’m sure many of you can say the same) dialing down my designs somewhat to allow for a more realistic and attainable end result.

And that is entirely the wrong way to go about it.

On any given project, limits are something which can simultaneously allow for boundless creativity or stifling rigidity. From the outset of any given project, certain limits should be established: a hierarchy, a general colour palette & tone for the site, rough visual concept, etc. However, under almost no circumstances should the limited nature of the web be one of them. I’ve caught myself saying “oh no, that can’t be done like that” because I knew, from previous experiences, that it was difficult to get it right. However, if  that piece of difficult code is what differentiates your site from the competitors, then you damn well better get it to work. Because in the effectiveness of a website (or any communications piece) it’s the concept that matters; not the practicalities.

I found that, by introducing these little qualifications or semi-excuses to avoid particularly troublesome bits of a web design project, I would gaze back with tinted glasses on the days of working primarily with print (which, in full disclosure, was no more than two years ago) where it seemed like anything could go. However, this was simply not the case, as there was an entirely different batch of restrictions related to print: budgets, printers, paper stock, etc.

In short, we got on with it not by cutting back on our concept because of any inherent technical limitations, but instead we would embrace these restrictions and find a whole other way of approaching the project at hand which ended up working better in the long run. Small budget but with a need for strong visual impact? Print black or white text on coloured paper.

The point is graphic designers back in the day didn’t go around saying “this can’t be done, that’s impossible, and the other thing’s all wrong.” Designers ignored the technical limitations until the concept was pretty much sorted out, and then entered the production phase without any preconceived notions of what could and couldn’t be done. It’s amazing what can be achieved without a preformed bias; we’ve all worked on projects where the best results came from the most unexpected places, and that’s because of the benefits of an open mind.

Same principle for the web.

With a fresh web project, it’s important to not get caught up in the minutiae of the technicalities of code when the calling is for the most powerful execution of an idea. Banish “no”, “cannot” and “won’t” from the dictionary; they have no purpose when all that matters is the concept. Are there limitations to working on the web? Sure there are, and they’ll be addressed in due course.

But there were always limitations, and the best results embrace them as part of the entire process, not by compromising for them at the beginning.

§

The opinions expressed in this blog are entirely my own and in no way whatsoever reflect the positions of Applied Arts or anyone else I’m affiliated with.

Share/Bookmark