Leisa Reichelt’s post On documentation (or lack thereof) rang a lot of bells for me. Until my most recent engagement, it had been many years since I’d produced a specification collating together a range of information architecture deliverables into a single formal project deliverable that was then handed over to developers for implementation.
Like Leisa, I would categorise the documentation I have produced over the last 5 or so years as “just enough” followed up with lots of collaboration. By this I mean the antithesis of thorough documentation of every aspect of an interface. Instead I would produce a series of interim materials that are enough to get other members of a project team all working towards a shared goal, and support that through face-to-face communication. (By this I mean exemplar wireframes, templates, interface rules, etc).
I think this non-formal specification approach is more in the spirit of user-centred design as it demands collaboration and facilitates iteration without the requirement to continually go back and update the documentation (surely a bugbear of more than just this IA).
To summarise, I prefer a documentation light approach because:
- It encourages and enables you to keep on iterating far later in the project.
- It makes more parties (i.e. developers) creatively engaged in the project.
- It ensures that the designers (i.e. IAs) maintain involvement in the project while it is being coded.
- It removes the temptation of focussing on your deliverable rather than the user experience of the final product. You will not be able to point at the spec and say “they didn’t implement it right”.
- It requires communication and collaboration.
- It is the antithesis of the waterfall development approach!
I am not saying no documentation, but all too often documentation is something we hide behind. Try existing with less documentation and you will have a far more collaborative project.