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.
I have been writing this blog for around a year now. Periodically I look at the stats provided by the WordPress Dashboard (call me vain but it is nice to know you’re being read!).
When I look at the unique visitors by day there are two things that stand out clearly:
- Saturday is always the day with the lowest number of visitors.
- Monday is always the day with the most or second most traffic.
What does this mean? As with any data I could read endless things into the pure statistics. What I need is a bit of insight provided by user research to augment the raw data.
I wonder if other bloggers have similar experiences?
I don’t recall being taught about prototyping or iterating while I was at school. Shouldn’t these two fundamental aspects of designing/developing anything get taught in school? (maybe they do now – it is 17 years since I left secondary education!).
So many facets of our lives would benefit from a change of focus from the ‘first past the post’ approach to finding a solution.
Iteration teaches us that it is okay to fail, that everything you do doesn’t have to be successful providing you learn lessons from the experience. The playful, fail-free, creative core of prototyping and iterating surely should be taught to all.
Modal dialog boxes, i.e. windows/dialogs that once opened must be closed before the user can continue, have always been a bit of an usability no-no.
The biggest problems being that the user either doesn’t notice the modal dialog has appeared, or doesn’t realise that it requires their attention before they can continue.
As you can see from the above example on the BBC’s site, the Lightbox technique leaves the user in no doubt what they need to do before they can return to the main window.
I haven’t yet conducted any usability testing on this kind of Lightbox dialog, but my guess is that it will test far better than traditional modal dialogs.
I see that Jakob Nielsen named the Lightbox his “interaction design technique of the year” in his Year’s 10 Best Application UIs 2008. Nice to get there before the Dane.