Redefining design

I’ve long felt that the seperation between design and development has existed mainly because creating real things was too hard. Digital things used to be so hard to make that we had to make blueprints, sketches, prototypes, mockups and all these other things to communicate what we wanted to build, before we even started writing code.

Not only did that approach come with a whole set of problems, but our tools has radically improved so building things has become easier. And the things we build have become more complex, making it harder to create designs for them. The cost of design has gone up and the cost of development has gone down.

So, last week I stumbled across another post about the ”Post-PSD era of design”, the term that Brad Frost popularized last year, and something that I wrote about back in 2011 (in Swedish, google translation here).

The post contained Google’s definition of design:

“A plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is made.” — Google

Before. That’s the word that struck me as odd. I’ve been working the last six months creating a new system and trying to find a process that allows us to work in a nice agile way. We build by iterating. Build, improve, refine. Build, improve, refine.

But if all we do is a continuous build cycle and design is what’s done before we build, what in our process is actually design? What is it that we need to do before we make?

Generally speaking, agile works because in the digital world changing things is cheap. But of course some things are more expensive than others. To minimize the risk of having to change expensive things, we need to identify which parts are expensive and then we need to make sure we get them right.

My view is that for anyone who is creating a non-trivial system, domain modeling is the most expensive part of the creation process. For others, information architecture might be the most expensive part. Things that we perhaps usually think of as requirements.

The point is that the expensive part, the part you really should do before you build, is probably not what you think of as design. Layout, interactions, copy, typography, iconography, graphics and motion are all important parts of what the final product will be and we cannot do without them. But for any project that’s bigger than a marketing page, those things are relatively cheap, and more importantly they are easier and more natural to integrate into the normal build cycle of the agile process.

The question we really need to ask before we start building is not What should it look like? but rather What is it and which things does it represent?.

For us, design as defined by Google, is something quite different from what we normally think of as design.

This is not just a question of semantics. It’s a matter of knowing where we should spend our time, what we should make sure to get right on the first pass and which things we can iteratively improve. It’s about defining a workflow and a process that helps us create better things.