Sharing work with clients is crucial. But staying organized and maintaining version control can be tough — especially for engagements that span many months. As a design agency, it’s critical to bounce ideas and proofs around, getting everyone involved in the conversation: the account strategist, the client, the designer, and the developer. To achieve this back-and-forth with less friction, we’ve been creating subdomains, which help us share more work, more often.
However, setting up a subdomain to share project revisions and updates entailed more work than we thought was necessary, so we took this subdomain creation process that worked, and then made it better.
We chose Dropbox to streamline our workflow, make sharing files with clients easier, and (as a bonus) implement a rough version control system. Since the whole office uses Dropbox, tasks like file movement would be intuitive — and also have the changes stored in Dropbox with the option to revert to an older version. Our previous method with FTP was unforgiving; if someone mistakenly deletes a folder in FTP, there’s no undo button.
But first: Why do we use subdomains for sharing?
With any agile team, deliverables happen quickly and often. Sharing your work through email or project management tools often proves to be ineffective at distributing and managing designs that may rapidly change. Viewing items in a browser also helps answer the question, “Where is the fold?” that so often crops up (even though the fold is a myth).
By using a password-protected subdomain to share designs, we’ve found that both client and agency teams can quickly and confidently view the most up-to-date version in discussion. Subdomains eliminate the need to dive through emails and posts, and then sifting through endless comments and feedback to view the evolution of your work.
Before the Betterment
Before we improved our project sharing process, we ran through a complicated series of steps, and usually the designer or account strategist would both follow the instructions and consult with a developer to finish the process.
Since the task was broken up by waiting for the subdomain to be created by the system, our project could take 15-20 minutes (if you were an expert at the 14-step process, and feeling up to a hefty dose of deft clicking, scrolling, waiting, and patience). Our betterment brought that time down to a mere 15-20 seconds (a simple form to fill and button to press). We thought we could significantly improve the process quickly if we didn’t let advanced features get in the way; we did it in just three days.
After the Betterment
Gotta admit that we were pretty proud of our progress: We had taken what looked like an absurd challenge and actually conquered it — quickly. We created a simple, functional UI to create a subdomain with a mere click of a button.
Additionally, you can check people’s names off a list (and enter email addresses) to send the team members the subdomain address & password. This invite email is great to have so that everyone has a receipt of the password in their inbox.
We also built a system that can create secure, very random passwords. Not only does it give us peace of mind to know we’ve made good passwords, it also puts the client’s mind at ease: It reminds them that the people you’re entrusting with your intellectual property and business are careful, value your work, and pay attention to details.
That said, our current subdomain system is pretty MVP. We didn’t take 40 hours of team training and testing. We didn’t leverage someone else’s CMS, so we had to stick to our guns and not get distracted by any not-quite-critical features (like an automated password reset). There are plenty of features we’re excited to keep rolling out for our internal use.
Morals of the Story
Here are some lessons that our subdomain betterment project taught us — and reinforced. Definitely share your own lessons in the comments! We’re eager to keep refining our processes.
1. Take on (& take ownership of) innovative projects within your company to reduce headache for others (& yourself!).
2. Ask a developer to help; they’ll automate those repetitive tasks (& make them awesome).
3. Use a system & UI you’re already familiar with (even more headaches reduced & risk minimized!).
4. Launch MVP without getting distracted by all the features you think up along the way (make sure you keep track of them somewhere for later).
5. Sweat (some of) the “small” stuff, like creating über-secure passwords. Besides taking pride in your own work, you also build trust with your clients and demonstrate how much you care about their work.
Now that we’ve explained our process, we want to hear from you: What lessons have you learned as you’ve improved your workflow? Do you resonate with our “morals of the story”?