Design reviews or critiques are a favorite pastime. While my righteous indignation of having to suffer a bad website can still evoke some pointed criticism, I’m trying to keep things in perspective.
I’ve talked about critiquing designs in the past, but here, I’m talking about those informal critiques of designs created or constructed by other people or organizations. You know, the ones that usually start with “WTF were they thinking!?!”
The objects of such informal critiques are legend. A search for design fails in Google returns 270,000,000 results to me (in 0.3 seconds, so it must be a popular search). I remember talking about some of these design fails in design classes, but I’ve been involved with designing, building, and shipping long enough to know these examples of design fails are team efforts.
Full disclosure, I still shout “WTF?!” from time to time in spite of the following introspection, but my hope is that reflecting on these points will help me view them with a little more perspective. I write this so that you might, as well.
WTF?!
Let’s start with that point when you’re using a website that is sporting the latest version of Gordian-knot navigation or TV remote control and you’re wondering aloud how anyone could design such a mess, let alone ship it for what seems like the sole purpose of causing you grief. Of course, YOU would NEVER commit such a crime against humanity!
Would you?
Have you? (Be honest.)
If you’ve shipped more than one or two documents, products, web-sites, or you name it, then in all likelihood you, too, have published or shipped something that someone, somewhere, at some time will say WTF?! when they use it. It’s almost impossible not to and here’s why.
Why do people ship bad designs?
Well, first, we need to agree on what a bad design is? I would suggest that a bad design is one that does not accomplish its design goal. What could cause such an occurrence? Some reasons I’ve seen include:
- Insufficient understanding of the problem and constraints
- Insufficient resources
- Insufficient skill
To evaluate a design in this context, however, assumes you know what the design goal was in the first place.
It’s possible that the design was intended to achieve goals that you aren’t aware of making an objective evaluation difficult. A subjective evaluation, however, is still easy because you’re evaluating it against your goals. Not always fair, but usually, easy.
Insufficient understanding of the problem and constraints
It’s hard to solve a problem you don’t understand. It might be possible to get lucky every now and then, but planning to be lucky, isn’t much of a plan. To design a solution, you really need to understand a problem and you also must understand the constraints within which the solution must be created.
OK, that’s obvious.
Where this gets tricky, however, is when you can’t really understand the problems or constraints until you start experimenting. It’s possible that some experiments might provide some value to a customer, but until you have iterated and learned what you didn’t know you didn’t know, your experiments might cause some WTF?! moments. In Agile, that’s part of the process and those moments inspire future iterations that improve the design. In other cases where the solution is purported to be a complete solution, that’s considered a failure.
Context is everything.
Insufficient resources
Time is usually the resource in shortest supply. If it’s not in a short supply, it is at least in a limited and finite supply. Perhaps the solution did address all the problems as it was designed, but there was not enough time or money to implement all of them. Some problems were left unsolved. If those problems are the ones that are important to you, that’s a failure (at least, from your perspective).
Why not wait until it’s finished? Sometimes you need to ship something to pay the bills. Sometimes, a partial solution still provides additional or new value. Shipping a partial solution isn’t necessarily bad and maybe a complete solution would be too expensive for anyone. Again, Agile is built around the ability to solve problems in increments, but your partial solution still has to appear finished and it mustn’t incur the anger of those for whom it doesn’t provide a solution (yet).
Managing expectations mitigates this reaction. If people don’t expect a design to do something, they won’t be upset when it doesn’t. “Under promise and over deliver,” as Tom Peters suggests, can help manage expectations (and subsequent disappointment), but tread those waters carefully.
Every product exists in a context of intrinsic expectations. Know them (if nothing else)!
Insufficient skill
Technically, skill is a resource, but I called it out separately, because insufficient skill is often expressed in the form of “What kind of idiot…?” which is where it gets personal. If you are a designer or developer, you could be the idiot to whom that comment is leveled. Of course, we both know that you’re not an idiot, you’re just working within limitations of which the critic isn’t aware, and probably doing a darn good job, all things considered (not that the critic will ever know that).
Criticizing the writer or designer based on a particular artifact can be risky because, someday, the object of your criticism will be your younger self. But, know you know better and now you’re likely better for it.
That I’m starting to cringe at my earlier writing and code samples means I’ve gotten better.
Ship it!
So there I am. I’m trying to have a little more patience and understanding with apparent design failures, at least I’m trying to not jump to blame the designer or developer. Most of the products you see are the result of many influences. The financial influence to ship something so it can be sold. The career influence to do what the boss tells you, in spite of your reservations. The fact that nobody knows everything, but you still need to deliver something. And, its corollary, sometimes you need to ship something in order to learn what you don’t know that you don’t know.
That being said, I’m still going to be impatient with organizations who don’t seem to value my time and energy (one of those intrinsic expectations I have). I just won’t be so quick to blame the developer or designer for my disappointment.