The Evolving Newsroom

I spent much of today describing a website from the ground up. I say describing because I haven't drawn any pictures of it yet, haven't written a formal requirements document, and it's far from being built. At this stage it's just words on a page describing what needs to be included, and the preliminary decisions that need to be made about navigation, search, display, archiving, content entry and so on.

I'm taking this description to a meeting, in which most people will know a lot about the content and nothing about the back end of a website. The rest will know a lot about the back end but nothing about content.

I'm somewhere in the middle.

I've been to these kinds of meetings before and seen how badly awry they can go. I've seen people talking at each other, past each other, over each other's heads, but seldom to each other.

The first problem, naturally enough, is that each side knows nothing of how the other's domain works. The second problem is terminology. Words mean different things in different environments. And when you're in a meeting talking about things you don't readily understand, when you hear a familiar word you tend to assume it means what you've always known it to mean. Which can lead you and everyone else up the garden path.

Take the word template as an example. When I first got involved with websites I took one look at the form you used for entering content and called it a template. It reminded me of the templates you create in Word to prevent having to recreate standard documents from scratch each time. Made perfect sense to me.

But every time I used the word template in meetings with IT people, they thought I meant page templates - the fixed elements of the homepage, section pages and story pages across the website.

That's just one example but there are many more. I've noticed too that terminology varies from company to company, and from country to country.

It strikes me, though, that neither problem is hard to fix. It just requires someone from each side to draw some simple diagrams to show the main steps, hazards and outcomes of their domain, and to label the diagrams clearly so the terminology is understood by all. A brief explanatory/definition session in the first meeting would surely slash the confusion quota and improve productivity across the project's life-cycle.

I've never known that actually to happen, mind you. I've had people get cross with me, patronise me, ignore me and tolerate me. Happily, I've also had a few people demonstrate enormous patience and goodwill in taking the time to teach me, although generally these have been people I've approached personally.

But I can't see why every user-developer collaboration shouldn't start with an explanation/definition session. Sure, most people might know most of it, but at least the one or two who don't won't be left sitting in the corner unable to contribute because they can't find the terminology to do so. After all, their knowledge and ideas could prove hugely valuable.

It can also be hugely advantageous to have one or two people on a project who know a bit about every side of it, who can act as interpreters and make sure the various participants are communicating effectively. Business analysts can sometimes, but not always, fill that role in the corporate world but it seems to me there's room for plenty more to step in and specialise.

Meantime, in my website description document I'm trying to spell out terminology and write simple explanations as I go, and I'll try to draw some diagrams before my meeting. All going well, we'll have a productive meeting and a good project. Fingers crossed.