One of the tasks that's been literally annihilating my time recently is our current review of all our legal contracts. Now they are nearing completion I took a look back over the work we've done on them and realised we've applied many web design techniques to them...
Back in January, we started working on a new set of contracts for our Support services which have been rapidly growing in popularity. If I'd known that I'd still be working on them to this very day, I'd HAVE RUN FOR THE HILLS SCREAMING!
What seemed like a fairly straightforward task on the surface quickly became a project of mammoth proportions and resulted in a complete overhaul of the way we approach our support services, sales process and all sorts of other things.
However, what I really want to discuss is the way we approached the SLA contract from a web design perspective...
Agile Development
The contract development and all online discussion related to it has taken place in our wiki, our Legal Extranet to be precise.
By using the wiki we were able to start with a rough draft and then quickly improve it whenever needed.
We've used the open source AutoWatch Plugin so that everyone who contributes is automatically added as a watcher of that page - when subsequent changes are made or comments added, they get an immediate email notification.
You might be wondering how I can call the process agile considering it's taken 8 months already. Well, the editing of the contract itself has been highly agile – it's the countless changes we've made to our support methodologies, sales processes and systems, whilst in active use by over 2000 customers, that's taken 8 months.
Version Control
Confluence's ability to review different versions of a document, in particular the ability to show me everything that changed since my last edit, became extremely important when the need arose to see how a clause had changed over time.
Semantic Markup
The document markup uses semantic HTML such as heading and text styles. This is by design - like all our contracts it will be available on our public website when it's finished.
In particular, the ability to mark insertions and deletions in Confluence is hugely useful – we'd often leave changes marked up in this way for a few versions of the document while people discussed them.
Accessibility
An immediate benefit of using semantic markup is that the contract will be accessible to users browsing with assistive devices such as screen readers.
But, as many a web developer has learnt, accessibility isn't just for individuals with disabilities, there are all sorts of other scenarios where making content accessible is highly desirable such as browser plugins that display the table of contents for a page based on headings.
The only area where Confluence didn't quite meet our accessibility requirements is that it's not possible to define which row/col headers a cell relates to, however with assistive technologies getting better all the time and the ability to export to other formats such as MS Word, we overlooked this minor irritation.
Usability
Contracts inevitably end up containing legalese or other unwanted verbosity and cruft. Our contracts were no exception.
Roughly 50% of our revisions to the contract have been due to us making clauses easier to read and understand and, recently, we've also been making architectural changes so that the majority of the clauses are set out in a logical and natural order where the "flow" of information is humanised.
Aesthetics
When someone mentions a legal contract, you don't instinctively think of aesthetics - however, we did. There are places in the contract where we've used shiny graphics to depict things like Service Availability - we also include the information in text form, but when it comes to making certain information really quick and easy to absorb you just can't beat a shiny graphic IMHO!
Aside: You know a contract is nearly ready for public consumption when the lead Java developer starts commenting on the text formatting for heading level 4.
User Testing
Throughout all key stages of development, we've released beta versions of the contract (and in some cases just excerpts) to key people who it will affect:
- In-house developers and support team
- Customers who use practically every product and service we offer
- Customers who only use our support service
There has also been a constant information flow about the effects the contract will have to all staff, but if you ask almost any member of staff they won't be aware of this...
As the contract has developed and it's interaction with all aspects of the business has become more fully understood, I've been checking over everything form our sales processes, accounts system, online documentation, master price list and support services to make sure everything fits together perfectly.
Aside: One day I'll try and write about our company-wide matrix where every single thing interacts in countless ways with everything else, but I'm afraid my brain will scamper out of my head and run towards the hills.
The feedback (whether directly requested or covertly obtained) has been essential in making the contract make sense to as many people as possible and has resulted in major structural changes to the contract over the past few weeks.
Exporting
As well as providing wiki markup and HTML versions, Confluence also lets us export to MS Word and PDF formats as well. With the recent release of the Office Connector and other export tools such as Scroll on the horizon, we feel confident that we've chosen the right format for our contract creation and deployment.
All in all, we've found that applying various web design techniques to the contract has helped us drastically improve the readability of the contract (considering how much information it is required to convey).
If you've not used a wiki for drafting legal documents yet, I highly recommend it...
2008/09/30
