The Rationale within Documentation

by November 13, 2006

Though it could be an artifact of the industry I’m in (Web-based services and applications), I’ve encountered some interesting commonalities between the design organizations working within this space. Within the groups I’ve been a part of or worked with, the pace of creation borders on the fast and furious and the longevity of documentation is measured in months if not weeks.

In my experience, the average project spans about two weeks. This includes tasks with 1-3 day turnaround times and extended 2-6 month engagements. Each of these may generate multiple wireframes, mock-ups, use cases, storyboards, and more. These in addition to Product Requirement Documents, wikis, and style guides often constitute the full set of artifacts responsible for documenting the design decisions, supporting research, and final outcomes of a project.

In most cases, as soon as they are completed, these documents become out-of-date as soon as the next set of changes is pushed. Given the pace of production, there’s simply no time to update any artifacts with updates to the design or rationale. As a result, the product itself becomes the living embodiment of the most up-to-date documentation.

Certainly this is a manageable situation as many companies work in exactly this way. However, one thing that gets lost in this fast paced, quickly dated documentation environment is the rationale behind decision-making. What limitations required us to make certain trade-offs? Where did we opt for business goals over user needs or vice versa? When did we cut corners to meet specific timelines? These data points often need to be referenced as a product progresses forward but due to a lack of documentation longevity, they unfortunately tend to get lost.