Client-Centric Documents

by CHRIS RIVARD :: SEP 19, 2006 :: COMMENTS (0)

Documentation is produced for a number of reasons during the lifetime of a project. We use different documents to communicate the design vision and interaction to designers, developers and to our clients. We find value in documenting a project over simply diving in and programming, designing, writing, etc.

More often than not, clients come to us with a vision of what they want their website or web application to look like and what they want it to do. These requirements establish a baseline for the start of our user research. As the research progresses, the requirements are refined. This is vastly different from a company that focuses on the design and development of products. In product development, the product features can evolve as the product is being developed, iteratively. In the end (hopefully after a lot of usability testing) the product is released into the wild. If the users of the product think it's rubbish, they won't buy/use it.

Our clients pay us to help them define their vision and build something that will be usable when the project is completed. The documents that we deliver reinforce what we have learned during research and convey this knowledge to design and development. We think that collaboration with our clients is a great way to innovate, explore new ideas and generally build great stuff.

So, how can documentation fit into a process while still allowing us creative freedom to make incremental tweaks to our application as the project marches on? Does it slow a project down? Is there inherent value in producing documentation over producing a prototype and iterating? Does it all have to be so black and white? Let's look at some uses for documentation that we have found helpful.

A Common Language
In teams made up of people with diverse roles, documentation provides a shared vision of what the deliverable is and what requirements have to be met. We typically produce a project mandate as a deliverable of our research. This document becomes a reference as we begin to iterate through solutions.

Design Artifact
Not everyone has the benefit of having a Russian Lit Major & Historian on staff and when projects are completed and a web application or system evolves, a historical document that details why decisions were made is an invaluable starting point when we move to the next release of a product or begin a redesign. Not all of us have minds like a vise.

Client Road Map
We have found that clients appreciate being kept informed as we design and build their app. Documentation provides a tangible artifact that clients can study, comment on, and use to communicate with the team. In a typical web application project, we will hold weekly meetings with our client discuss project status - review prototypes, refine requirements, etc. In our process, this is where most of the iteration takes place. We have found that clients have trouble grokking an application that is half-baked and want to clarify design and functionality. There is an enormous leap for a client to make from prototype to something that is complete and polished. Documentation is the bridge.

Remote Communication
In our experience, agile processes do not scale to large teams or projects. For example, it is common practice for geographically remote teams to build one component of much larger project and merge paths some point in the future. An example salient to our region is in defense work, where many times a contract team has no knowledge of how the component they are producing will be used. Documentation is critical for these projects to move forward. In our practice, we may need to communicate an interface to a visual designer working off-site. Details of the design vision are communicated through wireframes and content object annotation.

Research Results
Much of our documentation includes results of our user research that was conducted at the start of the project. This document is key to testing design against our personas. Late in a project when we are in the trenches and working with the development team to finalize interface elements, we refer to the research and validate our decisions against the research. We have found that clients will study our personas and research results. It is often the most concrete example they have seen to date about who their customers are.

Lo-Fi Prototypes
Among the tools in our documentation quiver are classic wireframes illustrating interface elements and noting anything unique to the developer related to page objects. We have also begun to use deconstructed wireframes for more marketing/brochure based websites where creative drives interface. In more application heavy projects, a scaled wireframe is used to detail varying levels of interaction and object specific details. With the advent of RIAs, this is where patterns and object notation come into play. We are hard at work defining what kind of language can communicate rich interactivity over time. Stay tuned.

tags: AGILE, CUSTOMER SERVICE, DOCUMENTATION, INFORMATION ARCHITECTURE, INTERACTION DESIGN, PROCESS, TECHNIQUES, USER EXPERIENCE, WIREFRAMES

Trackbacks

Trackback specific URI for this entry

Comments

Leave a comment?

Name:

URL: (optional)

Email: (optional and public)

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.

Enter the string from the spam-prevention image above:

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.

Remember my personal information
Notify me of follow-up comments