Congregational websites are suffering. Some are out-of-date, others are ugly or confusing, and many don’t give visitors the information they need. The good news is that typically it’s just one overarching issue that causes all of these problems — and it’s not that difficult to fix.
The crux is role confusion combined with poor communication. It takes quite a bit more than one talented nerd to build a website. By my count, there are actually nine different skills involved in making a great church site, and over half of them predate the Internet, not to mention the Web.
For a large corporate websites, the roles and skills ideally look something like this:
While that’s not a model that will work for even a large church website, it’s important to congregations for a couple of reasons. First, it highlights the wide variety of skills involved in creating and maintaining a website. Second, it’s the model that many church website volunteers come from. For example, your church webmaster could be a database analyst for state government. While chances are she will do an excellent job of coding your site, there’s an equally good chance she won’t know the first thing about design. You could blame your unattractive site on her, but all that’s likely to do is reduce your membership. She’ll leave the church and with good cause.
Behind every second-rate church website I’ve looked into, not to mention quite a few good ones, the roles look something like this:
The web staff and the site are in a silo. It’s not an ongoing leadership priority, and expectations for the website are both fuzzy and unrealistic. In all the cases I know of, this has been completely unintentional. The root cause is that everyone, including the Web Team, is busy. Thus it’s expedient to keep doing one’s separate tasks — not taking the time, let alone building the infrastructure, to tackle your ailing website.
Another way of framing this is that it’s management, not technology, that’s the issue. Thus the remedy involves good leadership. What you need for not just a good website, but also a healthy and happy Web Team, is a model more like this:
There are still a lot of skills involved, but with shared responsibility and appropriate divisions of labor come greater appreciation and satisfaction for all involved. And inevitably this will show on the website.
So what exactly are the nine roles? Most of them are fairly traditional, but the newer, web-specific ones seem to be shrouded in mystery to many ministers and church leaders. That in itself is a cause for the gap in Diagram 2. To add to the confusion, because the Web is relatively new, the nature and definition of these roles is evolving rapidly. But church websites don’t have to be bleeding edge, so to demystify, here’s a breakdown of the roles I’ve seen needed in recent years.
1. Management. Church leadership, working with their current webbies, defines the scope of the website, sets policy, and recruits as needed for the Web Team.
2. Content Creators. At the heart of every good church website is its content, including photographs. If your website is going to have both an authentic voice and a steady stream of news, this will come directly from the ministers and leaders, including church staff.
3. Project Manager. This is your website work traffic cop. In my church, project management is actually done by our Communication Committee. When new initiatives or technologies are needed for the website, they are run through the committee, prioritized, assigned, and given time-tables.
4. Usability / Information Architect / Analyst. Probably the hardest role for a non-webbie to understand, this is the person who actually transforms the content into a good website. They see to the navigation, use tools like Google Analytics to see where the site needs to improve, interview a variety of people to see what works and what doesn’t, and make sure the site adapts as needed. This is the role I gravitate to in most of my Web work, though I’ve done everything else, with the exception of being a sys admin.
5. Editor. This is just what it sound like. The skills are not that different from print editing. And like their print counterparts, Web editors need good policies, crafted by some combination of the project manager and church leadership, in order to succeed.
6. Developer. Note that way down the list is the role that most non-webbies associate with the web. That’s the programmer — the person who knows how to code. For congregations, this role also usually includes database management. Ironically, while it’s the role we think of, a church can get by without having developer if your project managers can find a technology that works for the team (for example, WordPress).
8. PR / Marketing. This is where Social Media fits in. It’s essentially tangential to the website, but usually perceived as part of it.
9. System Administrator / Site Hosting. Chances are this is outsourced, and that’s as it should be. If you’re lucky, your denomination takes care of this. Otherwise, and more likely, the Web Team chooses and works with a commercial Web host. The cost is nominal — typically $100 to $200 per year.
Putting It All Together
Once leadership is ready, getting to a healthy model of church website creation is simply a step-by-step management process. Given the different personalities and histories behind church websites, however, the specific steps will vary. In particular, care needs to be taken with people who’ve worked hard on the site in the past.
In an upcoming series of Congregational Resource Guide videocasts, Megan DeWald Kline and I will be discuss some specific situations — how various churches improved their websites and resources that can help. If you have specific questions you’d like me to address in the videocasts, please feel free to use the comments below or contact me directly. I’d love to hear from you.