Making Documentation actually useful
Posted by: eolvera, in Dialog Design, Information Architecture, Tools
I was recently reading an article about the future of wireframes in the context of user interface design documentation. Wireframes have been used mostly for visual elements and became a critical building block in the early days of the web.
But since I like drawing analogies between other UI fields and the VUI field, there were a few quotes that struck a cord because of their universality:
“The object was to create as many wireframes as possible, of every screen in the entire site, in big, monolithic and hugely detailed chunks. Rather than exploring different approaches to the information and structure of the site, the emphasis became entirely focused on using all of the time available to build a collection of wireframes, regardless of whether they were the right wireframes.”
Ouch, how much of that is still taking place nowadays? You create as many “detailed individual states” as possible sometimes loosing track of the real intent of the document. Nevertheless, some of those risks can be lowered by using a layered approach where you start as simple as possible and then start adding details to the design that make sense from a design perspective and that help clarify the overarching intent; for example: starting with a high-level, 1-page interaction flow, then adding details in the form of sample calls, which then evolve into detailed flows and become the source for an initial or “skeleton” specification document (containing mostly initial interactions, without error strategies) which after various reviews (including Usability) become a complete or “full” specification document.
“Why hold the information in a document that’s no one wants to read?”
Thank you, thank you, thank you. How many times designers have to create alternative “views” of their documents because some groups may not be able to use (or care) about certain aspects of the design, which might be buried with other details or is presented in a format that is neither usable nor efficient. But of course, the question that begs to be answered is “What’s the ideal document the developer would like to see to build a system from?.” Suggestions anyone?
“In a previous life at a big ‘old style’ new media agency, there often seemed to be a one tool fits all approach to projects. This applied to information architecture too.”
I’m sorry to say some of might still be living that life. Methodologies/Systems anyone? I totally agree with the notion of finding out what’s the best tool for a particular project. Not every project requires the 12-step program, and not every customer processes information the same way.
“The best sites are those where there’s a seamless divide between the look, the content and the experience.”
This one I would like to borrow and extend as a closing statement: “The best systems are those where there’s a seamless divide between the look, the sound, the content and the experience.”
Time to rethink our current documentation practices…
Entries (RSS)
May 12th, 2009 at 1:47 am
I’d be very interested to know how you feel that current documentation practices fit in with agile rather than waterfall projects? Especially when the focus is on getting working software in the hands of users (and the team) as soon as possible. I certainly think that this is a place where the layered approach definitely helps.
May 18th, 2009 at 11:40 am
I think that’s a great subject. Personally, I think agile methodologies are extremely valuable in the sense that the earlier you can identify issues with a product/service, the faster you can correct and avoid costly changes during later phases. With that in mind, I think documentation will need to evolve in a similar way. Going back to some of the points made on that article of adapting documentation to the user/business needs and the specific requirements at each phase, I think the days of a “single specification/design document” are counted. One indication of that is the fact that more and more projects nowadays require developers/designers to go back and update their documentation to match their application/design. I truly believe that good design documents can help businesses understand/validate requirements, can help teams be on the same page at every step, and can help users understand how things work. Personally, I think visual thinking and visual representations (which by their nature are more universal than any written form) will start playing a bigger role in how things are documented. One example is how Google “documented” their new Chrome browser using comics: http://www.google.com/googlebooks/chrome/
May 22nd, 2009 at 8:23 pm
[...] « Making Documentation actually useful May 22 [...]