Q:

File Management As A UX Team

Working on a UX team, we've been looking at ways to improve the experience for our own workers in getting their job done and I was curious how other teams have approached file management. 
In the course of a large project with many people involved, our typical project files can be made of scores of user research documents, design references and iterations, meeting notes, and so on. When bringing a new member of the team on to an existing project (or better yet, a new hire), it can often times be overwhelming to get up to speed simply by viewing the project folder.
Has anyone been able to find a structure, a tool, or any sort of method of arranging files in a way that keeps things from getting out of control? Specifically, do you use a native OS's file management system and focus on folder structure and naming conventions, or have some sort of software that manages files in a more comprehensible manner, etc.? 

A:

It seems to me this is what the web was designed for.  A website could be created that presents the assets in any kind of organization you want.  Links would point to the asset files no matter their format, maybe along side a summary or some metadata.  If the format of the asset file is not presentable by the browser the browser will facilitate downloading. Of course it would be nice if as much as possible the assets were viewable in a browser.  The asset files themselves don't require any specific organization as long as the webpages point to where they exist, and if they need be moved the webpages that reference them need to be updated.
This simple model assumes the assets are read only, that there's no check-out or versioning is required.
Once basic pages have been created they can serve as a template, the HTML should be simple enough that a non-web-developer can maintain them (is there anyone on the team that has librarian type duties?).
The great thing about webpages is that everyone already knows how to use them. 
I once worked for a company that required all internal documentation be written in HTML (we were previously using MS Word).  Programmers already knew enough HTML to do so and tech writers had no problem picking it up. As the body of documentation files grew, organizing html pages grew organically around them.  The whole thing was informal but worked great. It would probably have been even better if there was some central planning at the outset.

