Month: June 2004

Stating the obvious, usability guru Jakob Nielsen reports today that:

Redesigning an intranet for usability often more than doubled the use of these award-winning designs from ten public-sector organizations.

Shortly after I filed this webly wisdom under “duh,” I read through the article and found buried deep in the middle what you can do on your own to make your church and/or charity’s website or intranet more usable.

Here is the phrase that pays:

Quite appropriately, user testing was the most common usability method, and was used in 70% of the winning projects.

Allow me to enumerate this into plain English:

1. Those who test their intranets often wind-up with more usable intranets.
2. Those with more usable intranets enjoy greater use and more successful use by their user base.
3. What goes for government intranets goes for your church website.

Yeah, okay, so that last point was mine, still, how do you go about testing your church’s website without incurring Nielsen’s $10,000 consulting fee?

My first suggesting is purchasing, and then reading, Steve Krug’s “Don’t Make Me Think: A Common Sense Approach to Web Usability.” In the book, he not only discusses important issues such as navigation and layout, but he also dedicates two chapters on how to perform what he calls “Usability testing on 10 cents a day.”

Once you’ve read this, then I suggest you not create your own usability test from scratch, but instead customize one from the following online resources:

• U.S. Dept. of Health & Human Services – Usability: Methods for Designing Usable Web Sites
• The Usability Tookit from the Usability Special Interest Group
• University of Washingotn – Guide to Planning and Conducting Usability Tests

For as it is written in Hacks 8:36, “See, here are specifications! What prevents you testing your site?“

Before ‘Home Improvement’ became a sit-com, and more recently a reality TV theme (sigh), Norm Abram was reminding us of the carpenter’s aphorism to “Measure Twice, Cut Once.” This is because once you cut a piece of wood, that’s it. The only way to compensate for a mistake is either through a messy glue and nails process and/or to suffer the expense of purchasing more lumber.

The same is true with email, listservs and the publishing of web content. Once you’ve hit the post or send button, it is about as difficult to retract as putting an envelope inside of a U.S. Mail box. A reality that can lead to very costly mistakes if not caught before you transmit and/or publish – such as the case of the Republican gubernatorial candidate for Montana whom after winning the primary election this past Tuesday, transmitted his concession press release to various news services which read:

“It did not go as we had hoped tonight, but tomorrow is a new day, and we endorse our party’s choice for governor at this time,… You ran a hard race, and we encourage our supporters to back your candidacy in a united effort to defeat Brian Schweitzer. Congratulations and good luck!” – Billings Gazette

Well at least Brown lands on his feet for being gracious, instead of a career killer … like let’s say for giggles: “you scum sucking idiot, you stole the election from me and I’m going to make you pay if it is the last thing I do …” Still, the email mistake could have been avoided had Brown’s staff put some controls on their email machine.

Now I realize that I’m always complaining about user interfaces that frustrate users with an array of nested forms, menus and/or confirmation pop-ups, but here is one situation where I think making a process a bit annoying would have avoided what could have been a painful and costly mistake.

How? Well, I’m sure each of us can think of a something (and if you do, please don’t be shy, leave a comment) for example, why not set up post-election distributions on two different listservs, one if they won, the other if they lost? Or at least configure the listserv or email system so administration confirmation is required before a message is transmitted.

Not all controls require massive amounts of computing power. Why not create a step-by-step script and/or check-list on paper for what to do in which scenario; then rehearse it, including sending email to test accounts? Why not have test destination accounts that receive an important email for proof-reading before the trigger is pulled for real?

The point is to look at your church’s ‘standard operating procedures’ regarding computerized publishing and/or transmissions and see if they have any form of controls, automated or manual, to insure that ONLY the right information gets to the right people at the right time each and every time. If not, then put some in place or suffer the consequences of something with the potential to embarass and/or even divide your church’s congregation.