Just curious how teams are handling collaboration from things like version control, project folder structures, and file naming conventions across product/design/engineering teams. Thanks!
I usually find something like
I find that too confusing so in addition I also do my folder structure like this:
Designs > Final > Archive > Final2 > Best > updated > Final
You are a gentleman and a scholar.
I work in an agency and we have lots of projects going on the same time. Now, that's say
- First three characters of client/company name = XXX
- First two characters of project/brand name = YY
- Our own project ID = 1234
- My initial = RC
This is an example of our naming convention for a wireframe file saved today: XXXYY-1234-wireframes-160805-RC.pdf
And this will be saved on Server/Client/XXXXX/YYYYY/WireframesandIA/
I actually don't like it but looks like it works... Really want to know what's everyone's approach!
I really like the structure of AREA 17 http://guides.area17.com/design-techniques/#file-organization
I find BEM also interesting to explore on file naming.
[client] -- [project]
---- admin (SOW, estimates, etc.)
---- ux ------ inputs -------- ------ build files -------- [client] [project] ux.sketch ------ screens -------- [friendly screenname] [- variation (optional)] [- sub-variation (optional)]
---- gd ------ inputs -------- ------ build files -------- [client] [project] gd.sketch ------ screens -------- [friendly screenname] [- variation (optional)] [- sub-variation (optional)]
… something like that. Because yeah, Dropbox (and/or Invision) handles the versioning.
We try to do something along:
[client/project] _documents _resources web identity 01 research 02 sketches [title] [designer] [version].[filetype] [title] [designer] [version].[filetype] ... 03 proposal/presentation 04 sketches phase 2 05 proposal/presentation 2 06 finishing 07 final delivery
We use SVN and organize something like:
Client Project Source (working design files) Section (for larger projects) Reference (notes, interviews, videos...) Deliverables (exported images, prototypes, PDFs...)
We get by pretty well without a naming convention for our files. I usually adopt a simple: "
Meaningful Page or Section Name v.1.0" (don't be afraid of spaces!) and increment versions when I'm taking a different direction, or doing the next iteration. Using a human-friendly, descriptive naming scheme has made searching for files a breeze for me. It also helps new people on a project know what's inside before opening them.
Why version when we're already using SVN? Because I want a simple way to have multiple versions of these open at a time to reference. To keep filesizes down and my design apps happy, I delete unneeded content from newer versions and stay focused on the most current designs. It also helps prevent painful mistakes and conflicts when using SVN (which we have no choice but to use). We would favor Dropbox or Google Drive, but alas, strict corporate security.
Within the Source folder, I have an Archive folder to wrangle up old versions to keep old/thrown out ideas handy or any assets I deleted in the new version accessible.
Our folder structure is more of a folder unstructure. So let me just share our naming conventions:
Though, I believe there are some aspects that can be improved, such as the order of variation/version.
Hope it helps!
Thanks for the feedback!
Hey Win Lin,
We use Dropbox for our version controlling on all our PSD, Ai, Sketch etc files. Our naming conventions start off being in capitals for parent folders and as we get into the child folders we go lowercase.
We set version numbers on all our design documents title page but also in the file name so when scanning our management tool clients and our self can see which document is the latest without having to open them. I think it all depends on what your team is used.... you guys have a current way of naming right now?
We're still exploring, but I'm considering dropping things like version number (files should inherently have version control in them), author initials, using all lowercase, using underscores between words, etc.