— 12 December 2003 —
Maxim du jour: In an authority vacuum, the person who speaks first/loudest is the authority.
Life can be interesting when you live in a consensus-driven decision-making environment. When you have to get more than two “OKs” in order to change the background color of the header from blue to gray, you’ve got your work cut out for you.
I am an employee. I was hired because I have special skills. I assume my employers wish me to use my skills. When I say, “Changing the background to gray will increase the readability of the text,” I often get, “Let’s see what Bob thinks.” Problem one is that Bob is out of the office for the next three days. Problem two (which comes up four days later) is that Bob wants Mary’s opinion. Mary’s in a JAD session all day. No email, no phone. Problem three (6 days and counting now) is that Mary doesn’t like gray. “Too depressing.”
This scenario has been embellished somewhat (his real name is Robert), but I use it to illustrate an all-too-common occurrence: design-by-committee. There are certainly tools (for lack of a better word) out there that are used for design that purposefully create a design-by-committee environment. JAD (and RAD), cognitive walkthrough, card sorts, to a lesser extent parallel design (of which I am a big fan).
The true downside of working in an authority-fee zone is that the people who do stand up and make decisions cannot always be relied on to make good decisions. Perhaps they lack the training necessary to make them a valuable resource. Perhaps they are making political decisions that will move them along the corporate sidewalk (I don’t think there are any ladders anymore). Or maybe they really know what they are talking about. Problem is, who the hell knows?!
This is why I end up going to a lot of meetings. I have to keep tabs on all of the “authorities” that I have to deal with on every project. Because if I am not there they will make a decision, and usually that will impact my work, which impacts the user.
Overall, it might be easier if everyone practiced user-centered design (UCD). This includes the system analyst, the business analyst, the developers, testers, and most importantly project managers. I don’t expect that these roles live with UCD like I do, but it would be nice if they thought, “How would this decision impact our users?” It would be nice even if they were making an assumption! Okay, not nice, but less annoying.
The true upside only comes when you are the authority. Consultants, I’m looking at you. You get brought in by a company because they cannot figure out a solution. You are in charge. Is that nice? I try to work like this, but I have to start from scratch every project. Each time I have to get to the point where I am seen like a consultant; it never happens right from the outset.
While there are many “levels of customer” (post on that topic to follow), the most important one should be the end user; those impacted most by the decisions made during the project.
If there are only two questions all of us should ask each day on a project, they should be: “How will this decision impact each level of customer?” and “Can you prove that?” These questions should be asked especially of others, but especially of ourselves.
Bonus maxim: A picture may be worth a thousand words, but you can never be sure if your audience will choose the same thousand words that you did.