Heal Your Church WebSite

Teaching, rebuking, correcting & training in righteous web design.

Don’t write vague use cases, write concrete, specific use cases

There’s more to testing your rockin’ church website than making sure your slick-new AJAX supported features deprecate for older browsers and mobile devices. Your testing should also insure that your cool church web site succeeds in encouraging and facilitating visitors and members to execute real-world actions along conversion goals you’ve established for your inspiring church web site.

Simply put, your church website should have real-world, action-oriented goals that in general:

  1. speak to a demographic of seekers, members, missionaries and/or ministers
  2. gets and/or helps said demographic to do things, like visit and/or volunteer

Doing this means testing your church’s Internet offering at least at two levels:

  • functional – do the neat and nifty ‘things’ work? Like hyperlinks, images, CSS, calculations, Flash detection and/or Javascript?
  • business – do the things that work, help visitors work towards a desired goal? Like find the sermon feed, and then add it to their aggregator?

To test the ‘business’ we need to go back to the ‘goals’ and build scenarios of likely user interactions, or in geek-speak: use cases.

Unfortunately those fluent in ancient geek may not be the best equipped to design such scenarios – as exemplified in the broad and conflicted definition of ‘use cases’ currently offered by the WikiPedia which reads:

“… a technique for capturing functional requirements of business systems and, potentially, of an IT system to support the business system.”

Uh … no … it’s about business rules and work flow, not functional requirements and certainly not about IT systems support!

Rather than collude the waters more, I’d like to point out an excellent set of articles by Matt Stephens over on the Register’s developer blog entitled:

  1. Use case style means handbags at 30 paces
  2. Vague and ambiguous use cases

Read as order as the later-written article nicely enumerates the elements that comprise a successful and effective use cases in pragmatic real-world terms that include:

  • Writing cases in the active versus passive voice
  • Descriptions of functional requirements versus behavioral objectives
  • Knowing how many ‘rainy day’ scenarios are enough to get the job done
  • the pros and cons of comprehensive versus minimal testing templates
  • Whether to reference domain classes by name
  • Whether to reference UI elements (screen/page names, buttons etc.)

I would suggest that anyone who hasn’t thought through the user interactions in terms of real-world scenarios do so – and with specificity. As anyone in my line of work, vague test cases have no other path than to vague results … or as Mr.Stephens correctly asserts:

“… Don’t write vague use cases, write concrete, specific use cases that leave nothing to the imagination instead.”

Put another way, you don’t receive good results because you’re not asking the right real-world, objective-centric questions.


  1. Use cases? How quaint. Agile/Extreme stories are the way to go.

  2. C’mon Jeff … business logic is business logic no matter which way you organize it …

    … and as someone who goes Agile/Extreme for a living, I can tell you that how one stacks and package the ‘story’ aren’t nearly as important as getting the story correct from an operational point of view.

    After all, we’re talking church web sites here – I’d be glad just to have a stack of notecards that describe the desired process … let alone call quaint those whom aren’t staffed-up with geek teams working 8 hours a day to fix something.

  3. Pingback: » Heal Your Church WebSite

  4. Pingback: 10 things we can learn from the Royal Institute for Interfaith Studies website » Heal Your Church WebSite

  5. Pingback: 5 things we can learn from the Winston-Salem Hampton-Inn Toaster Czar » Heal Your Church WebSite