A checklist for design
Creating something for other people is hard. It is hard because we imprint ourselves on the things we create. Michael Beirut - in his wonderful book 79 short essays on design - refers to this as the “fallback strategy.” This is the preferences and insight earned over time which can be summoned at will. This is why when presented with a blank slate we often start creating things for ourselves. There is nothing wrong with this. It’s easy.
But often it is not for us. The majority of work we will undertake will be intended for someone else, in another place, under different circumstances. The design profession is about solving problems that are wholly foreign. We must approach our work as skeptics: exploring, questioning, and researching.
But you know this. I’m tired of talking about it. Anyone who has even toyed with the concept “how do design?” knows this. But it’s true. And it’s still difficult. It is hard to be objective. I catch myself constantly slipping into comfortable motifs, overused patterns. This has been happening quite often to me lately. It manifests itself as half finished prototypes that have nothing to do with the intended goal. Not in a good way, but in a meandering way - ignoring the whole point of the work.
Let’s find a tool.
This figure is from the wonderful textbook “Universal Principles of Design.” This figure, in turn, is an adaptation of Maslow’s Hierarchy of Needs. The triangle diagram represents two things: the five criteria of good design and the magnitude of their importance. Let's break them down one by one.
The raison d’être. Can the thing do what it is supposed to do? Seriously, check. Did you just build something that can’t do anything? Be warned: being functional does not equate to sparse nor does it mean minimal.
Can it do it multiple times without exploding? Will it work in the environment it was intended for? Did you create a screen door for a submarine?
Can the intended audience pick it up and start using it? Does it make sense? Does it fit into it’s environment?
This is a popular stopping point. There’s more.
This is where things start to get interesting: can your users become experts with it? Can users improve and grow with this object; progressing into mastery?
How can this thing be more? Is it beautiful? Does this thing allow for flexibility; for emergent behaviour? Are you limiting people or setting them free?
Keeping us honest
These criteria come together as a hierarchy because they build off one another. Reliability can’t be explored unless we know how a design functions. Creativity can’t be explored unless we know what is being created works. How can we discuss mastering a tool if it breaks every time we use it?
The hierarchy is usually used as a yard stick, measuring up a completed object. Personally, I like to use it as a checklist. It prevents me from getting ahead of myself. For example, I am a huge fan of making things reusable. Every time I start on a new web project, seeds of frameworks start to emerge. “Oh,” I think to myself, “I think I just invented a new grid framework.” Nine times out of ten, I haven’t, but potential of a new project is heroin: an amazing pick-me-up, but a distraction from the work at hand. The hierarchy is a reminder of what’s important now.
This isn’t about stifling creativity. It’s about building something people can both use & love.