Heal Your Church WebSite

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

Call for some ‘Purpose-driven’ case studies

It’s that time of month again when I have to put together another article for Christian Computing Magazine. As with my last two articles, I like to cite real-world case studies. In my upcoming article, I’m looking for church websites that were designed using some form of a formalized needs requirements and/or a deployment plan.

For example, one of my cases is going to be First Baptist Church of Frederick, MD (FBCF) – a site originally I critiqued last December because of a variety of usability issues. A few months later I was pleased to see they had a very different and very usable website.

When I spoke to the pastor and the web designer on the phone, I discovered that the website was a by-product of a desire to establish an intranet. Communications of their internal information online being an essential tool to meet their overall goal of becoming a more lay-driven church. Based on that goal, they opted to address their primary need (the intranet) by using Community Builder, a web-based church membership management database software that also has web-publishing capabilities.

So what I’m looking for is one or two more case studies where a church website is the product of a well-defined purpose. The website can be the end-goal, or it can be a secondary byproduct of another goal as was the case with FBCF. Point is, I want encourage and teach other church webservants to:

  • Think about their needs before they select a web publishing tool;
  • Precisely define the purpose of their online presence;
  • Make their design decisions, and subsequently their mistakes, on paper first;
  • Create a project plan for their development and deployment.

You can help if you’ve gone through two or more of the above steps; even if you’re just a one man show. Leave a comment … if you don’t feel like giving details, just say “contact me” in your comment and I’ll get to you. I’d like to get this all done in the next day or three, so don’t be shy! I’m not going to be critical, I just want some “for instances.”

Oh yeah, I’ve got IM working now. Let the reader understand.


  1. Missing the biggest step. Without a clearly defined vision for the Church/organisation, no website will ever be useful. It’s like the old maxim in software development: with no spec, there’s no bugs, just unexpected behaviour.

  2. or to rephrase the above post… with no spec, there are no bugs, just interesting and undocumented features… ;-)

  3. I am an elder at Barcroft Bible Church in Fairfax, VA. My Worship/Music pastor and I are in the process of revamping our church website. By day my job is as a Tech Advisor/Sr. Software Engineer for a defense contractor and I am very familiar with the need for a requirements statement prior to going into battle with system development. My Worship/Music pastor just recently completed his Masters in which his thesis revolved around what you can do with church websites. So at least we were on some common footing.

    Looking at our website, we put forth three propositions of what we wanted our website to do: (1) to be a means of advertising the church to the community (who we are, how to get to us, what to expect, what we believe, etc.); (2) to be a place for the congregation to communicate with each other (prayer, discussion, calendar, contact elders, conduct church business, etc.); and (3) once the communication has been achieved, to encourage the members of the congregation to participate in evangelistic outreach by posting stories, material, movie reviews, etc. on the website. These three things became our statement of vision for the website.

    From the statement of vision, I constructed a strawman requirements statement broken down into ministry and technical requirements. This requirements statement was passed around to several individuals in the congregation for comment and along with the statement of vision, amounts to about 6 pages of type.

    One of the technical requirements forced us into an early tactical decision. We wanted to be able to give different individuals in the congregation the ability to change a specific portion of the website, without huge expense in buying development software – and be able to control what individuals see depending on their “rights” within the website. This let to the decision to use a Content Managment System which would allow login and close control of implementation. We wanted to give individuals involved with our Adult Bible Fellowship classes, for instance to grow their portion of the website as they saw fit to meet their specific needs. We settled on WebGUI.

    All this is a precursor to let you know that we go online the end of September 2004 with the visitor portion of the website and the initial “layout” of ministry elements. I am just about done with a template of the site and will be moving it to a temporary server this week or next.

    Contact me if you would like more information.