One of the awesome things about being on the web team is that we get the opportunity to work with practically every ministry area in our organization. It seems like nearly every ministry has something they want to do with technology or the web. From the weekly Sunday morning routine tasks to the quarterly, annual, and one-time events, we get to be involved.
Working On It, Not In It
This keeps us busy, to be sure, but it is the best kind of busy imaginable. A continuous flow of technological challenges that, when solved, honor the name of Christ? Sign me up!
Twice a month we step out of the fray as a team and exercise the principal “Work on it, not in it.” We spend a few hours on Friday locked in a room together, sharing new discoveries, hashing through concerns, and grinding on ways to bring order to our collective work so that it doesn’t spiral into chaos.
A Common Set of Challenges
It was during these meetings that we were able to identify a common set of challenges that seemed to present themselves in the average web site project. Certain questions came to the surface over and over again. Things like:
- Is that font size too big or too small?
- Should we use proprietary software or open source?
- What size should the video be on a page?
- How tall or wide should a page be?
- How many pages should be designed, and to what detail?
- What are the preferred technologies to use?
The next step was pretty obvious.
The Solution: A Guide
We needed a guide! A standards document. Something to articulate our default position on the common decision points that our web projects face.

Ugh. A document? Really? Nobody likes large, unwieldy SOP/Process documents heaped upon them, especially not for creative projects. Would it be followed? Would it even be read? We discussed it and came up with these goals for our Web Design Standards document:
1. Must be quick/easy to read and under 2 pages or it will be more of a burden than a help.
2. Must honor the autonomy that empowers our ministries. Basically, avoid dogma if possible and be clear about our motives.
3. Must not read like it was born in 1994. Writing a document for designers that looks like a “TPS Report” is not going to encourage buy-in.
Very quickly we realized that we could not fit everything into 2 pages. So, the decision was made to split the guide into 2 documents. One to cover Design and one to cover Implementation (coding, technologies, deployment). We often sub-contract these parts out separately anyway, so the delineation was natural.
Today the web team would like to share with you the first document born of these efforts.
Download: North Point Ministries Web Design Standards (PDF)
Download: Source ZIP (Pages, DOC, PDF)
Feel free to use it for your ministry, pass it around, carve it up and swap out items as you see fit. If nothing else, use it to start a conversation. And if you do use it for one of your projects, let us know! Most importantly, if you noticed anything we missed, please share in the comments.
08.16.2011
1 Comment