The one where we discuss getting organized as a team

In this installment the UX and design teams from Nansen’s Chicago, Stockholm and New York offices confab over Slack about the need for standardized file naming conventions

 

It started with two simple questions for the UX and design team: how do you currently name and version files, and how do you organize your projects?


We’re a company that’s growing fast, and the need to get organized across teams consistently is growing ever more prescient everyday. We’re also a global team of collaborators who need to consider the different cultural needs we have — everything from the words we use to the projects we create.

While the questions we ask ourselves are seemingly simple, their answers are wildly varied, and highly personal. Any conclusion we may have (its an ongoing conversation) will have implications for all, and will fall flat if they’re not adhered to. After all, for many this will be a shift from the way they inherently — and habitually — work.

So, with a growing team and even more collaborative projects, it seemed like a good time to tackle file naming and organization. We’re set up on Slack, a great resource for serving as a hub for ideas, preferences, strong opinions, heated arguments and other thoughts that can help steer us to a single, unified filing method. The following is an edited version of our conversation which took place over a few days.


Flo: Here is how I currently break up project files: XXXX0000_ProjectName_DesignStage_Version_Round

organized as team folder view.png

Cynthia: I usually abbreviate the client name only & then the project name as well as versions. The amount of numbers and abbreviations scare me. Depending on the project, i’ll put the projects in folders, and within the folders will be assets, client assets, exports (jpg, png, pdf), and an archive folder to hold old versions. i name these files with an “_” beforehand to make sure they’re all on the top and not scattered in my folder.

 

organized as team second folder view.png

organized as team third folder view.png

Knut: I use a similar file naming convention as Flo, my pattern is as follows: YYYYMMDD-Customer-ProjectName-DesignTask_version_Author.filename

I use initials on author and sometime shorten Client Names to initials if they are too long.

For example: 20160205-ClientName-Project-Task_v1_KJR.filename

organized as team fourth folder view.png

 

Justin: I think by and large we’ll have variations on a theme here; Flo, your breakout is very similar to how I’ve seen it done (and done personally) through the years as well.

One specific that I’ve worked with in the past is the difference between r_x and v_x, where R stands for “revision” and V stands for “version”. Version is an entirely different concept, and Revision is…well, self explanatory. An update to that version. So a file could be: NIN0001_briefdescriptor_v4_r3

Andreas: @knut: What is the purpose of having “DesignTask” in the filename?

@all: Why have both versions and revisions?

Flo: @andreas: In some cases I might have two design directions, so V1 and V2. Then rounds are the major revision rounds. I may only take the first design version to V1_r1 or V1_r2, but I might work the second version all the way through the end of the project, so V2_r7.

Justin: Precisely!

Knut: @andreas: It’s a habit Ihave from working at my former company where it was useful to keep Designtasks in the filename for JIRA purposes (when scanning the attachment section of a JIRA task). I often split files when uploading in JIRA, resulting in:

​_Task-Project1_v1_​ and a ​_Task-Project2_v1_​

This is a great discussion going on about filenames, I like it!

Andreas: @flo: Ok, then I understand. We never do that. But it explains it. I would strongly argue for us to never do more than one design direction but that’s a different discussion.

@knut: Ok, so in the end that would, in Jira, end up in a bunch of files matching tasks in Jira?

Flo: @andreas: I think that would be an interesting side conversation to have! To keep within the version conversation my question is this: Even if we do only present one direction to a client, would we still be internally developing and exploring different design directions (aka versions)? If yes, could there still be a use for the versioning+rounds even if our output to the client is a single design direction? I could imaging the answer being no, just posing the question!

Andreas: @flo: That I agree with. But personally I’d just keep those as quick and dirty sketches and not as a “formal” version. But that is my way of thinking.

organized as team team photo.png
Some of the members of the Nansen UX and design team: Knut, Cynthia, Justin, Flo, Andreas
 

Flo: @stina: @erika @johan and @johan, what are your thoughts?!

Is there anything from the front end/development perspective that we might want to take into consideration as far as the way we name, organize or build files? (Maybe this becomes a side conversation about how we name layers and elements within Sketch.)

Andreas: @flo: Mostly the latter. But since they will overtake our files my vote is on as many “generic” file names as possible. In other words, no initials, no design-tasks. But that is also from how we work/will work here in Stockholm.

Knut: @andreas: Yes, they would co-relate to JIRA issues or simply help distinguish the files in a single task. It’s not something that I’ve used religiously since then, but since Flo asked for a different aspect, I threw it all in there 😊

Using initials at the end is not something that I hand off to someone else, but when working with 10 or more people, knowing who edited the file becomes important (we had 13 designers in the team at my former company all working and overlapping; design version control with a smart system never seemed to work so we went low-tech on this).

…but back to the file convention discussion: the simpler the better.


We know we’re not the first to have this conversation, but we recognize that internal best practices and patterns continuously change. That’s what happens with rapid growth and smart talent: everyone brings their own insights and unique perspectives that influence one another. At Nansen we value and encourage that rapport. And we’re open to your input to — what are your best practices? We’d like to hear. The discussion continues…