A while ago a friend of mine, the crazy smart Karl Fast, tweeted:
When I talked to him about it further, the distinction was this:
“Right” is based on expertise (if I’m an expert, I should know the “right” answer to a design problem), but it’s really fragile. If I make a recommendation about how an elearning course should be designed, and I’m wrong, that calls into question my level of expertise and knowledge, and a client could blame me for not being right. If you have a vested stake in being “right,” you will get defensive if somebody tries to suggest you are wrong.
“Better” is less fragile. Basically, you would try out an idea, and then see what works and what doesn’t. Then you keep what’s better, and change or remove what’s not. When you design this way, nobody has be defensive, and nobody’s reputation is at stake. You try some things, see how they work, and adjust.
I love this. I think this is really important.
The trick is to have a work process and a culture that supports this kind of thing. This is quick and dirty prototypes rather than massive design documents. This is rapid user testing rather than waiting for big rollouts to see how users react. This is making sure people feel safe to try things, and ensuring that feedback is swift and non-judgmental. It can be a big change, but the results could be amazing.