What are we losing by abstracting our design processes? Could it be as fundamental as losing a sense of humanity in our work?

A few years ago, Michael Bierut, wrote about a natural progression in a designer’s career.

“The client asks you to design a business card. You respond that the problem is really the client’s logo. The client asks you to design a logo. You say the problem is the entire identity system. The client asks you to design the identity. You say that the problem is the client’s business plan. And so forth.”

He calls this Problem Definition Escalation. Where a designer takes one problem and escalates it to a ‘higher’ plane of benefit and worth – one where it will have greater impact, and ultimately, make the designer feel like they’re doing their real job.

Constituent parts

Designing in a browser, in your head, on paper, on a wall, on post-it notes. It doesn’t really matter. What matters is the work. Is it appropriate? Does it do the job well? Will you get paid for it? Does the client understand the benefits?

Really. Who cares how you get there? We’re all coming around to the idea that designing responsive web sites in Photoshop is inefficient and inaccurate (if things like web font rendering matter to you).

Let’s look at the arguments:

  1. For those familiar with the tools, designing in Photoshop is just as efficient as designing in code.

  2. I design using the tools of least resistance. Preferably a pencil, sometimes Photoshop, and a lot of HTML. Photoshop is my tool of choice for creating website designs.

  3. Presenting static visuals to clients is different than using them as a tool yourself as a means to an end.

All of that is good news. Good for clients. Good for the work. Good for us.

A natural result of this is abstraction.

Design patterns are everywhere. The often-repeated chunks of content that we find ourselves designing and building time and time again. User’s get used to seeing them in certain ways, and over time, perhaps their performance is hindered by deviating from the norm. We see this all the time on e-commerce websites, or in new user registrations. Over time, we all collect these little bits of content, design and code. They build up, and eventually they need organising.

Why not group them all together, categorise them, and iterate on them over time? Throw in your boilerplate templates, too. Maybe group them together as a ‘starter kit’ with included navigation, indicative content – for different types of sites like ecommerce, blogs or magazine sites?

And… wait a second, you’ve got all you need to churn out site after site, product after product for clients now. Excellent. All we need to do is change the CSS, right? Maximise our profits.

No. It’s not right.

Conformity and efficiency have a price. And that price is design. That price is a feeling of humanity. Of something that’s been created from scratch. What I described is not a design process. It’s manufacturing. It’s a cupcake machine churning out identical cakes with different icing. But they all taste the same.

Documenting things that repeat is an important thing to do. I have my own pattern library that I’ve been adding to for years now – it’s an electronic scrapbook where I take snapshots of little content bits and bobs that I find interesting, and that keep on cropping up. It’ll never see the light of day. I’ll never use it on a project, because what I’m doing is building up a head full of this stuff so that when a problem presents itself, I will have a fuzzy recollection of something – maybe – that is similar. Instead of going straight to my big 'ol database of coded examples, I’ll try to recreate this little pattern from memory – and that’s when something interesting happens.

Recreating something just slightly differently – from memory – means you end up with something new.

That’s why I wanted to be a designer, after all. To create new, beautiful things.