File Management As A UX Team

Question

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.?

Answer 1

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.

Answer 2

You could look into UXenterprise from HFI, specifically designed for UX professionals, which precisely addresses this issue and has more features too.

UXenterprise helps with storing all the objects that you would typically use in a UX process, best part since the process is very iterative, its got a versioning feature, that lets you go back to that version and refer if necessary. With every project you can store multimedia objects too. For example after having done a initial stake holder meet, the collected data can be added to the project. Have used it once and loved the idea. It actually keeps inline with the process too. We used to follow a similar setup in our organization, store everything in share folders, and going with timeline based names. But it was a pain when it came to sharing your concepts with your clients, but UXenterprise helped us solve that issue too.

Answer 3

1. A Wiki + a File hosting (Dropbox or something for images/data storage)
2. A working high fidelity prototype which contains all of the recent changes and which will replace the most of the docs (as it described in an excellent book Inspired: How to create products customers love by Marty Cagan)

The main point here is that having a working prototype + a wiki for related information is quiet enough. For example, your prototype (or even several versions of it if you need) will reflect all the value you've gathered during meetings, user research or design sessions, functional specs, etc. At the other hand wiki should contain all the referencing information (like user research statistics, etc) and the things which aren't yet in prototype (like open questions, suggestions, etc). And as soon as these things will become more or less clear to be added to a prototype you should archive them (or even delete).

In my own experience, the more docs/meeting summaries/etc you have the less useful this data is: something is obsolete, something is represented in several versions and you can not understand which one is right and so on. So the people will not look for information but rather ask their colleagues instead, interrupting them from the tasks they're working on.

You should also assume some data has temporary or even technical meaning (like wireframes interaction designer sends to visual designer every day) and they deal with it themselves as they like to (it's cool to have a generic document management system used across the company, but in reality people has their own preferred ways of intercommunication in this situations).