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

  • 1
    +1 for good question. If several people need to work on the same project, i.e. same mocks, wires, docs etc. I think Dropbox can be a very helpful tool. It just keeps a backup of files and files are always in sync so everybody is working with the latest version. I look forward to the answers here. Nov 12, 2012 at 15:52
  • The problem is often too much documentation. I'd start there. Look into 'lean UX' and the like.
    – DA01
    Nov 12, 2012 at 19:30
  • @greenforest Good call, I will need to look at Dropbox as a reference and potential solution. Thanks!
    – gotohales
    Nov 12, 2012 at 21:09
  • @DA01 Definitely. I have actually been looking into Lean UX this morning and it's been very helpful.
    – gotohales
    Nov 12, 2012 at 21:09
  • As much as I like Dropbox, at the end of the day it's not more than a plain file system (albeit shared, which is great). As such, it doesn't require the users to organize the information in any particular way, which is the core of this question as I see it.
    – Juan Lanus
    Nov 15, 2012 at 15:42

3 Answers 3


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.

  • I didn't want to potentially affect any of the answers by mentioning it from the get go, but this is the conclusion I came to first as well. I have been considering putting together a custom web interface for those exact reasons and seeing how it works out, though I wanted to see if anyone else had tried that solution, or anything else for that matter, and to what degree of success. Thanks for your feedback!
    – gotohales
    Nov 13, 2012 at 14:21
  • I like this answer very much, but it's still at the technology level. HTML sites are great, but remember that content is king. We have seen hideous page mazes based on this same technology, alongside with excellent sites. Obelia gets it when commenting about the need for planning.
    – Juan Lanus
    Nov 15, 2012 at 15:53

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.

  • Thanks for this extremely helpful tip! I have been looking into it and the Object Oriented UX approach is quite intriguing. This brings up all kinds of ideas how to work with a number of issues we face.
    – gotohales
    Nov 14, 2012 at 16:45
  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).

  • Thanks! So you would also go with a browser-based structure it seems? There would definitely be a lot of room for improvement on how much information we keep on hand and how we organize it into what is really important and what is dated or otherwise less useful.
    – gotohales
    Nov 14, 2012 at 16:48
  • Definitely. The great thing about wiki is that you will be able to relayout structure very easily if needed, without figuring out how to reorganize files on the disk. It's no matter where (and how) files are located physically (in a Dropbox, or at a some other service or server), the main point is reachability, isn't it? Nov 14, 2012 at 20:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.