Need for Design Documentation

In the early days of my profession, I always hated the word “Documentation”. For me it was a process (more of a routine), which was time consuming, boring and hardly any tools to automate, as from one project to another the format was different. And today at this point in my career, I regard it as the most important process to make a project delivery successful. And when its all about Design of the application, its usually make or break for project delivery. Documents are also meant to capture idea, and in the process it tends to reform the idea for better.

A lot has changed since Rich Internet Application platforms came into existence (post 2003), design documentation has become more complex and evolved into a more mature form of art. Yes, I said “Art”, because in its current form, UI Designers, Experience Designers or Information Architects, use their own creativity to prepare a set of design documents. Hardly there is any standard format which is widely used by all UI Designers. And this makes obvious, on how can an effective design documentation be prepared. Well there are set of definitions for a Design Documentation, otherwise knows as Deliverables, and each design firm has their own process to create and communicate these deliverables. After all at the end these deliverables are meant to communicate one’s vision to other team members.

Effectively communicating the idea of how the application design looks and feels, makes the documentation a valuable asset in the delivery mechanism. Also at times, it makes new team members integrate well with the team, as it helps them understand the application better, and make decisions in coming time more soundly. Design documentation is meant to be designed by and for the people who are :

1. Planners (make deliverables)
2. Converters (use deliverables)
3. Decision Makers (approve deliverables)

So if you are heading on a new assignment or managing one already, just run up a sanity check on your design documentation, it always pays off.