All aspects of a project’s process and design should be documented. This documentation can be in whatever format makes the most sense for the project as long as it is comprehensive.

The two most common forms of documentation are a single document (report, process book, etc.) or using a wiki. For each it is important that the team have established best practices early in the process. These best practices should be continually checked throughout the process to make sure they are still optimal. A team member (or multiple members) should be assigned the task of formatting and maintaining the documentation in accordance with the best practices.

Document

Commonly teams use digital documents that can be modified by a team.

Why the team would use a document:

• Easy to print and turn into other formats (articles, papers, etc.)
• Easy to trim and modify for a specific purpose
• Formatting is easy to maintain
• No software/system to learn
• Easy to backup and maintain multiple version

Example Best Practices

• Establish simple and consistent text formatting
• Determine reference formatting
• Create either topical sections or milestone sections
• Use consistent levels of detail

Wiki

Using a wiki for documentation has several advantages.

Why the team would use a wiki:

• Easy to search for information
• Easy to extend
• Can learn a software/system
• Need a large base of information
• Don’t need a specific single document format

Example Best Practices

• Choose a platform
• Establish naming convention and tags
• Establish references
• Focus on breadth

Images

All projects should be fully photographed because images provide dated information of the current progress of the artifact. If the artifact has a software component then screencaptures should substitute photos. The focus of the photos should be to capture any assemblies, uses, or context that cannot be easily conferred with the internal documentation and files at a date or by reflective documentation.

Code

All code should be maintained using some form of version control to maintain the dated progress in conjunction with all other advantages of using version control. In documentation the comments in the code should be augmented to add any other context that is needed for a potential uninitiated team member to understand.

In Process Files

While it is getting easier to use version control for other types of files it is not as standard as it is with code. Other files (CAD designs, graphics, etc.) should have a standard naming convention with

Communications

Teams should look to keep and archive all communications between members that are pertinent to the design process.

Meetings

For meetings, depending on project management strategy, the important information to keep:

• Date and time of the meeting (location if relevant)
• Who attended the meeting
• A summary of the topics discussed
• Action items
• Information about a followup meeting if needed

Personal Documentation

As a member of a design team it is important to keep your own documentation for several reasons:

• For continuity if you stop working on the project before it finishes
• To maintain your role and personal contributions to the project
• To settle any issues from your perspective (IP, ethics, etc.)

Example best practices:

• Usually best done in the format of a single document or blog
• Based on dates of milestones
• A few paragraphs outlining current work performed and status of the process
• Be diligent in completing it