Improving Usability Practices in a User Hostile Organization
Being a web application developer, I make user interfaces—a lot. Years ago, after I was comfortable in my knowledge of how to build UIs, I began wondering how should I build UIs. Sure, I could easily recognize someone else's bad UI. If I was confused, frustrated, or failed to complete my task, then it was a bad UI. But when it is your own, you know too much about how it should work to recognize what is confusing to a new user. I was determined to find a way to get the raw feedback I needed to build the best human-to-computer interfaces as I could.
About 10 years ago, while on my quest for the secrets of usable computer interfaces, I attended a short presentation by Tom Brinck, author of Usability for the Web: Designing Web Sites that Work. I was thoroughly impressed. He had first hand experience in a process that was proven to create great UI. He used wireframes—simple, unadorned and quickly developed UIs—to test the usability of a design before and throughout the development process. He said something that stuck with me. When the client expressed their amazement with how much their users loved his final product, Tom said, "I already knew they would, because we tested it."
This was what I was searching for. It makes no sense to user test after it is too late to change the core design. Using fast, cheap, and simple UI placeholders to get user feedback as early as possible made so much sense that I felt foolish for not thinking of it first. I attended a full day workshop with Tom, and prepared a presentation to share this amazing technique with the company I worked for. This would revolutionize our development process!
As you might have guessed, it did not revolutionize our development process. Everyone was very impressed with my presentation and agreed with all I said, then went right back to doing exactly what they always had done. I failed to improve our process, and knew no other tactics.
So using wireframes become a technique for my own projects, with rarely an opportunity for my professional work. The typical process I work with today goes like this:
- An artist creates a colorful PhotoShop mockup that struts the latest computer graphic fashions down the catwalk.
- Middle managers argue about what color to paint the bike shed.
- Developers attempt to implement the mockup even though no effort was made to test usability or even check that it meets business requirements.
- Young developers whose spirits are not yet broken may express concern to management that the mockup is inconsistent, unclear, and missing key functionality. No matter how bad it is, the design will not be changed because it has "been signed off on."
- If enough thrust is provided to launch the pig, it is barely functional and everyone hates it.
- The developers are blamed.
I love my job.
As grunts in the trenches, what can we do? Despair not! There is hope. I have discovered three techniques to make improvements to a development process against the forces of habit and groupthink. Though not guaranteed to work 100% of the time, I have been successful with each at least once.
Ask Forgiveness, Not Permission
On smaller, internal-facing projects with little political appeal, the design and development team may have free reign. Take advantage of this. Implement a wireframe version quickly and collect feedback. If access to your end users is being blocked by management, show it to whomever you can find. This is called "hallway usability" and though it may not be quite as valuable as the opinion of your target audience, it is still a powerful usability improver and one of the key requirements of The Joel Test.
End Run to the Graphic Designer
I have rarely met a graphic designer that wasn't a talented, intelligent person who wished the process functioned better. Approach them early.
"Hey, I heard I am going to be implementing the UI for project X. I have started on a rough wireframe. What do you think?"
Chances are the poor graphic designer has been given little to work with and is happy for the help. (Don't be bossy. This is her job and you are only assisting.) Giving her access to your wireframe and getting feedback is a great start. Use her connections to stakeholders to elicit feedback from them. And, as always, do as much hallway (clandestine) user testing as you can get away with.
No matter what is accomplished with this technique, improving communication between the interface designer and the interface developer is always a good thing.
Utilize the Corporate Change Management Process
Larger corporations often use a process improvement strategy (such as Six Sigma.) Find out how management documents and improves processes and work within that. "Swimlane" diagrams may be dismissed as incapable of documenting creative processes, but I don't buy that. Here is an example of a simple UI design process.
If your manager has drunk the Six Sigma Kool-Aid, drawing swimlanes could make you sycophant of the month. The key parts are designating the end users as the approver of the design (not the managers) and moving corporate styling toward the end of the process.
Whether you are a designer, developer, or usability expert, I hope I have provided useful ammunition in the struggle against bad computer UI. Stay strong and keep fighting for the users.