Designing Better File Organization

Without a good file organization strategy in place before the work begins, inconsistencies in product design and inefficiencies in team collaboration will grow. Simply put, it costs the business money.

Recently, our design team at Creative Market conceptualized and implemented a new file framework for our team Dropbox account.

I wanted to share the changes that we made, because our file organization is working much better for our team now. If you’re struggling with messy folders, inconsistent file names and sloppy layers, then maybe our plan might spark ideas about a restructuring that might make sense for your company.


How Our File Debt Grew

When Creative Market was in its startup phase, we churned out a ton of design work at neck-break speed. We built the MVP with dozens of important features over a 6 month stint. We had a loose folder structure in place for that initial design work. It worked well enough.

After we shipped the MVP, our file organization strategy (or lack thereof) didn’t handle what came next very well.

We started to ship features and initiatives at an accelerated pace in an effort to scale growth. We didn’t pause to reset our Dropbox folder structure or archive past work, and probably should have done that shortly after the MVP shipped. The debt that came with disorganized files grew too as we continued building. Our Dropbox account slowly transformed into a wasteland of incoherently named files, random folder structures, and dead PSDs full of sloppy layers.

The next thing we knew, two and a half years had passed.

Our Digital Mess

Our parent Dropbox had 15-20 folders. Most of our product design work was buried four tiers deep in a structure that looked like this: Site > Design > #features. It was surrounded by many folders at every tier, which made it hard to find quickly.

Our Site > Design folder had around 30 feature folders at the time we launched our MVP. It housed well over 100 feature folders last month.

Our disorganized file system had negative impacts. It was clear that our Dropbox file system wasn’t set-up for long-term success. If we wanted to audit its effects, we could probably put a dollar amount on how our file disorganization disrupted our business.

Here are a few recurring issues that we had:

  • New Projects: These were named at will, placed in subjective locations, and didn’t have clear folder or file hierarchy inside them.
  • Existing Project Additions: We had V1, R1, Archived, Active, Iterations, Final and more inside of existing project folders.
  • A/B Optimization Tests: We shipped over 30 tests in Q1 of 2015 with 80 variations. We didn’t have a clear approach for how to integrate tests with feature folders. We cobbled together a stop-gap solution.
  • Work Inefficiency: It was difficult for the team to find the work they needed. There were many incidents where work was moved, mislabeled, and temporarily or permanently lost.
  • Team Onboarding: It took new team members a while to learn our file structure. They tolerated the pain of it, and veteran team members endured it for a long time.

We decided to act.


Designing A Path Forward

The design team had been talking about fixing our file structure for a few months. When our team trip in early June finally came around, we grabbed a conference room, debated what wasn’t working, and shaped a plan of attack in about 4 hours.

Folder Structure

We simplified our Dropbox account by housing everything into four main folders: Campaigns, Operations, Platform and Resources.

Parent folders.

Campaigns

Campaigns — Folder Structure

The Campaigns folder is our home for marketing and community initiatives, which are one-off or repeat projects that usually don’t impact our core product eco-system.

Campaigns

At the top level, there is an _Archive, _Active and _Template folder. Projects that are currently being worked on are in _Active. When they are complete, they are moved to the _Archive by the year that they were completed (2015, 2014, 2013, or 2012). The _Template folder houses files we need to spin up repeat design work such as social images, Facebook ads, and more. We systematically use underscores in important folder names to keep them at the top.

Campaigns — Folder Naming Scheme

Our project folder naming scheme for Campaigns is pretty simple. Underscores are used to separate the segments of the project name, while dashes are used to represent spaces in the file name.

Formula: Campaign-Type_Campaign-Name_Year
Example: Discounts_Fourth-of-July_2015

Project folders may have sub-projects, elements or features as required by the project. Within those, we separate by the type of work produced (e.g. Copy, Comps, Wireframes, etc.) if needed. Then, we use standard versioning (e.g. V1, V2, V3). Inside of each version, we’ll have sub-folders by file types (e.g. JPG, PSD, PNG, etc.).

_Active > Project Folder

We typically leave copy, research and strategy content out of Dropbox. We place those in the corresponding Asana task, and link to a Google Doc when the content is too deep to place in an Asana task description.

If starting a new Campaign similar to one that previously ran, we encourage the team to copy and paste the folder structure to ensure consistency.

We never use the word final, and just rely on the last version being the latest work. Otherwise, we could constantly be updating the final folder to be relevant, and inconsistencies could quickly grow.

Campaigns — File Naming Scheme

Our file naming utilizes a pattern that helps us easily identify several key data points quickly. Just like our folder system, underscores are used to separate the segments of the file name, while dashes are used to represent spaces in the project name.

  • What parent- and sub-project the file is associated with
  • What version the file is (e.g. _V1)
  • What iteration the file is (e.g. _V1a)
  • Who worked on it (e.g. _gl)
Campaigns > File Naming

Formula: Campaign-Name_Sub-Project_Version_Author’s-Initials
Example: July-Big-Bundle_1024x1024_V1_gl

Campaigns — Archiving

After a Campaign project is complete, the project lead removes the year off the end of the folder name, and moves the project folder to the latest _Archive folder (e.g. 2015).


Operations

Operations — Overview

The Operations folder is our home for company-specific documentation. The folder structure and files within are grouped by content theme, and if sub-folders are required, there are no rules really. This is essentially an archive of documents.

Operations

Resources

Resources — Overview

The Resources folder is our home for assets that our team creates in-house or collects from external sources. Inside Resources, the folder structure groups files by content type and theme. The sub-folders inside those groups are organized in a clean manner.

Resources

Platform

Platform — Folder Structure

The Platform folder is our home for our core product design and eco-system.

Platform

At the top level, there are _Archive, _Templates, Components, Initiatives and Product folders. _Archive houses the design of our pre-launch teaser page. _Templates contains design templates for recurring initiatives such as our monthly bundles and occasional discount promotions. Components houses icons, colors, illustrations, grid, fonts, and complete UI library. Initiatives contains projects that the design team creates and leads to ensure product consistency and instigate feature redesign efforts. Product is where the meat of our design work is for the desktop site, mobile responsive work, apps, extensions, plugins and more.

Platform — Folder Naming Scheme

Our project folder naming scheme for Platform differs slightly from Campaigns, especially in the Product folder. In Product, we list out all features instead of using an _Archive approach. We have an _Active folder where all of the current Product design work occurs.

Platform > Product

Folder naming is similar to Campaigns. Underscores are used to separate the segments of the project name, while dashes are used to represent spaces in the file name.

Formula: Product/Feature-Name/Sub-Feature-Name
Example: Product/Account/Payouts

The interior of product folders may or may not contain sub-features. Within the primary feature or sub-feature folders, we add folders by the type of work produced (e.g. Copy, Comps, Wireframes, etc.) if needed. From there, we use folder versioning (V1, V2, V3). Inside of each version, we’ll have sub-folders by file types (e.g. JPG, PSD, PNG, etc.). The conventions here largely follow what we do in Campaigns.

Platform — Types of Product Feature Work

Our Product feature work currently takes three different shapes, which are as follows: Stand-Alone Features, Eco-System Features, and A/B Optimizations.

  • Stand Alone Features: These product features are mostly isolated parts of the site, such as the following: Shop Pages, Product Pages, Category Pages, Blog and more. Whether it’s a new feature, updating an existing one, or completely redesigning a feature, stand alone features usually impact less (instead of more) of the product eco-system.
  • Eco-System Features: These product features impact many sections, page states and user states in the platform. Examples of eco-system features are as follows: Dropbox Integration, Product Liking, Extended Rights License and more.
  • A/B Optimizations: These smaller tasks are growth tests in which we make design tweaks to singular feature states or parts of a user’s flow through a feature. The goal of these growth tests is to improve our many key metrics throughout the product. Examples of a/b optimizations are as follows: Pinterest Button Positioning, Sign-Up Incentive Variations, Discount Flows and more.

Platform — File Naming Scheme

Our file naming utilizes the same pattern as Campaigns, which is as follows:

  • What parent- and sub-project the file is associated with
  • What version the file is (e.g. _V1)
  • What iteration the file is (e.g. _V1a)
  • Who worked on it (e.g. _gl)

Formula: Product-Name_Sub-Product_Version_Author’s-Initials
Example: Sales-Dashboard_Affiliate-Feed_v1a_ns

Platform — Archiving

After a Product project is complete, the project lead moves the folder out of _Active and into the folder structure for the related feature.

It’s important to note that our three different types of Product feature work require that we consider how we archive the work.

If the Product work is a Stand Alone Feature or Eco-System Feature, we typically move it from _Active into it’s respective feature folder. In some instances, the Eco-System Feature should be sprinkled into the Stand Alone Feature folders it impacts when the work is moved from _Active into the main feature folder. We’re still figuring out the best approach for this.

If the Product project is a Growth_Test, then the design lead moves it from _Active into the corresponding Growth_Tests folder inside the feature.


Issues with Moving Files on Dropbox

I wanted to share some insights about making a big restructuring move on Dropbox. We incurred pain points and a few lessons along the way.

  • We instigated our Dropbox reorganization on June 19th, and the bulk of the folder and file shuffling occurred over the weekend so that the team wouldn’t be actively working in Dropbox when it happened. The task was too large for one weekend, and micro-shuffling occurred over the next 7 days thereafter. The dust didn’t settle until July 3rd. Lesson: Plan for more time than you think you need. Move folders and files during off-hours.
  • We didn’t back-up our current files and structure before reorganizing, and lost a decent amount of non-critical files during the move. Lesson: Back-up your messy files before you make massive folder changes or file deletion.
  • I reached out to Dropbox, and they gave my three solutions which were unhelpful for our situation. Lesson: Dropbox has not figured out how to keep shifting files and folders from computationally disappearing. Proceed with caution.
  • Solution #1: “Deletion events like this can sometimes happen when someone reorganizes files in a new location or moves them to their desktop. Since the files are no longer in the Dropbox folder, those changes are synced to both the website and other connected devices. If you’re unsure about how a file was deleted, you can see more detailed information about which user and computer added, deleted, or changed a file by looking at the “previous version history” on the web site. https://www.dropbox.com/help/11Lesson: Dropbox deletes some stuff when you make big folder changes. Those deletions didn’t show up in my previous version history.
  • Solution #2: “In most cases, you can restore deleted files directly from your Events page on the Dropbox website. To do so, please sign in to your account, and select the Events tab. From there, click the event you’d like to restore.” Lesson: Since nobody deleted the files in our Dropbox, there weren’t on the Events tab to recover.
  • Solution #3: “Rollback your Dropbox business account.” This was the only true solution that would have worked for us. Lesson: Backup before beginning. If we rolled back our account, it would undue the 20 hours of reorganization work we had done.
  • Next, I took to Twitter to lament, and Dropbox Support opened up a dialog with me that resulted in the same three solutions that their support person gave me. Lesson: An angry tweet won’t bring back lost files or create other options.
Unhappy customer tweet.
  • I alerted the team that we were going through a Dropbox planning exercise and asked for initial feedback or concerns. Lesson: It’s good to give folks a pre-heads up.
  • I let the team know that the Dropbox restructuring was going to occur on a Friday afternoon, and suggested folks turn off Dropbox syncing until after it was done. Lesson: This was key for a better experience for the team.

By the end of the restructuring, our Dropbox account went down from 77 GB to 56 GB. That’s 20 GB in savings. The level of folder surgery and file deletion that I performed was moderate. There’s probably still room to get back even more storage for our team, especially after we truly archive unnecessary, older files.

We’re Still Figuring It Out

We’ve got our new folder organization up and running well for us so far, so our plan is working! That being said, we’re still figuring it out. I bet we’ll need to adjust our file framework again as the team grows, the platform changes, and the work evolves too.

I’d like to shout out a special thank you to Noah Stokes and Zach McNair for their contributions to this plan. Thanks guys!