The massive shift to remote work this year has largely been made possible by public cloud apps and services like Google Drive and Dropbox. Imagine if all of the file sharing, collaboration and version control had to happen entirely within email?
Actually, maybe don’t try to imagine that. This year is stressful enough.
Many employees may be working almost exclusively within one such app, dictated by the business. But if you’re a freelancer like me, you might have multiple accounts set up to accommodate the preferences of each client. For example, depending on which client I’m working with on a given day, I might need to manage and share files in Dropbox, Box, Google Drive or OneDrive. And each app requires me to work with files in a slightly different way.
The secret to working with these cloud services – particularly when teams are involved – is good file management.
In the virtual workplace, these are shared spaces – even if some of them might function like just another folder on your personal hard drive. And that means you might need to adjust some of your habits when it comes to how you save and organise your files.
If your employer has this taken care of, then job done. But many people might be collaborating with others via shared folders within their own personal accounts – particularly in smaller businesses that may be slower to adapt.
Most cloud storage services have a free tier, and this may be enough when starting out.
But, should you need to store and share larger files such as audio, video and other rich media, the limitations can quickly become apparent. When you’re in the back of a taxi, frantically trying to upload a large presentation into the cloud so it can be accessed by someone else desperately waiting to present to a room of people, the last thing you want is an error message telling you to delete some files to make space.
It’s worth paying the few dollars a month to ensure you always have more space than you need. Plus, paid versions often include extra features, such as enhanced security, deleted file recovery or team collaboration tools.
Like any file management system, it’s all about the folder structure. Put everything in a clearly labelled folder – even if it’s the only item in there. Orphan files left unsorted in the main folder will quickly accumulate until navigating to what you really want means scrolling past a long list of random file names.
A good folder structure also allows you to share and collaborate on discrete sets of files, while others can similarly share relevant files with you within the same folder. Spend a little time planning your folder structure, while considering who needs access to what.
For example, your team may need access to everything in the project folder, but the client may only need access to the subfolder containing only those files intended for their review.
What might seem like a reasonable file name when you save a document might be vague and unhelpful to someone else – or even to you six months later. If you have to open a file to remind yourself what it is, the file name wasn’t strong enough.
And then there’s version control. Which file contains the most recent draft, and which contains the client feedback still to be actioned?
Some cloud apps make version control a lot easier. Google Drive, for example, allows users to easily view, restore and copy from a document’s version history.
However, when different drafts need to be saved separately – perhaps when sharing with the client – the file naming structure you adopt needs to make clear which file is which.
File names should contain as much descriptive information as possible without becoming overlong.
Depending on the project and workflow, a good filename structure might contain some of the following elements, or whatever else makes sense within your team, each separated by an underscore.
[CLIENT/ACCOUNT]_[Project]_[Title]_[Date]_[Author Initials]_[Version number]
Some people use dates expressed as short number strings (e.g., 231020), while others use version numbers (e.g., V1, V2.2, etc.). Occasionally, it might be appropriate to use both.
Sometimes, it may be useful to append extra information to the end of a file name, such as initials to indicate who has provided the feedback (useful when multiple stakeholders are in play), or which stage of production the file is at. For example, _PROOFED would indicate the copy has already been checked for spelling, grammar and style issues, and is ready for the client to review.
Of course, everyone has to agree to follow the same file name structure or chaos will ensue. If someone saves changes or feedback to the same doc without updating the file name, and this is then saved to the same shared folder, it may overwrite previous corrections or feedback. When this happens, no one might notice until a little while later – by which time untangling the error might be difficult.
One final tip: avoid the pain that comes from marking a file as FINAL only for more changes to happen. When you find yourself appending FINAL_FINAL_FINAL! to a file name, the notation becomes worthless. The only way for someone to tell if this really IS the final version is to look for another file marked FINAL_FINAL_FINAL_FINAL, hoping that it isn’t in someone’s inbox.
If a version marked FINAL later turns out not to be, then correct the file name to reflect the version number and/or date etc. as before. Save the FINAL notation for the file that everyone agrees really is the last version in the journey.
If you’re new to working with cloud apps like these, it’s worth adopting good file hygiene from the start. You’ll be surprised how quickly you become reliant on them to keep work in sync across your devices and across your teams.
But any workflow can only be as strong as its weakest link. If you organise and manage your cloud spaces effectively, your team will spend less time looking for files and more time working on them.