Do your projects involve creating “deliverables” that you then hand over to your client? Do you publish these as static documents and regularly send them by email? Have you considered whether this is the best way to capture and deliver the information you want to communicate?
Typical deliverables in an online project include documents such as project brief, user research findings, requirements specification, information architecture, user’s guide and so forth. These are frequently authored as traditional text based documents with supporting tables and diagrams, most often created in word processing applications like Microsoft Word.
Static documents just don’t cut it anymore
I have found a number of problems with document-based deliverables. By definition, word processors suggest the outcome to be a static, printed document. This promotes linear thinking and assumes that there will be an ultimate, “final” version of the document. This is often not the case when a document describes a flexible software based system such as a website.
Can you capture a dynamic, interactive system in a linear document?
It is difficult to define a dynamic, interactive system using a static document. A static document does not easily lend itself to describing how one part of the system affects another part, and how the behaviours of different components are interlinked. You can work around this using traditional devices such as footnotes, however these can be difficult to both author and follow.
There are a number of other problems in working with documents. Usually only a single person can work on a document at any given time, which does not promote efficient teamwork. I also regularly see version control issues with documents: How many times have you had to call up a client just to check that they’ve got the “latest version” of a given document?
Substance vs. style
Traditional documents tend to make you focus on form (look and feel) rather than substance (content and structure). Untold numbers of business documents look refined and believable but have little substance or solid arguments behind them. In part this is due to the tools; word processors help you tidy up the styling of the document rather than refine your thoughts while writing it. The other part is the fact that humans are visual animals and disproportionately judge things based on the first impression.
Microsoft Word 2007 ribbon screenshot by Gareth J M Saunders
An alternative to documents
A wiki is a collection of Web pages designed to enable anyone with access to contribute or modify content
My suggestion is to use wikis for most intermediate work products i.e. deliverables. The easiest way to do this is to set up a project-specific wiki site and to give access to all project team members, both within your and your client’s organisation.
However, the technology is the easy part – the challenge is in changing your own and especially your client’s working culture to accept the raw, uncertain and flexible nature of wiki-based hypertexts.
Focus on the functioning website instead of “deliverables”
The key thing to remember is to always keep your focus on the ultimate outcome: the dynamic, interactive website or online application that your project is delivering. Every intermediate deliverable before this should only be written to build and share understanding of what exactly is being created and what is the best way to build it.
Deliverables other than the ultimate, functioning website have no intrinsic value.
The bottom line: Define the context and detailed design of your website using a project-specific wiki rather than by writing linear, monolithic text documents. Make sure the whole project team has full access to the wiki and make it the key point of reference when working on the project.
Bonus: Wikis in Plain English
Do you regularly use internal wikis in your projects?
How do you educate your clients on the why’s and how’s of wikis?