A scalable, multi-designer Photoshop Framework
Recently at Infusion (inspiried by my CD Layla Keramat), I was challenged to take a more scalable and dynamic approach to Photoshop. In essence, I wanted to make the Photoshop workflow more conducive to having multiple designers on a single project, with some ability to have easily updatable externalized elements. This was a pretty tall order, as out of the box Photoshop's ability to link to external objects dynamically is simply not supported, save for elements coming from other Adobe products. Internal Smart Objects weren't an option either because those are embedded in the parent PSD which means there is no opportunity to edit them externally. What I ended up creating was a way to have global external components (think navigation bar, button sprite sheets, footer, etc.) fed into one Master PSD file, with the ability to update the elements dynamically, and having multiple designers working on a single project at once, without millions of versioned PSD's floating around. An ambitious undertaking indeed.
Before I could solve this quandary, I needed to think about how large scale projects are executed from a design perspective. First, on any multi-page design project (be it Mobile, Web, or Touch) there will always be common elements used across the application - things like navigation bars, sidebars, modal overlays, etc. Then I needed to think about how to logically divide sections into PSD's, and finally figure out how to extract Layer Comps (best things in the world) from each individual PSD and feed those into a master PSD.
What I devised is a tiered approach; the thread that ties everything together is the Master, the Components are all the reusable and common elements, and the Screens are all the individual pages that get sandwiched between the Components in the Master. I want to walk through the theory of how they work, then talk about how this actually done in practice.
he Components are predominantly PSD sprites, elements that are globally used across the whole design; things like headers, navigation bars, backgrounds, footers, etc. They are intended to be linked in both Screens and the Master to ensure consistency across all visuals, especially since they will be updated dynamically as the file changes. Though, the best way to describe the advantages of the Components is to illustrate a problem I have run into many times thats hopefully mitigated with this new framework. Say I'm working on a web page which has a common nav bar at the top, and all the pages are spread across multiple PSD's, as the projects goes on the client wants to suddenly change the color of the nav bar. I would have to go into a whole set of files and change them all manually, however with this framework I would only need to change the single component and it would then propagate all the changes to the Master and Screens. There is a still a little grunt work but its far less tedious than updating each and every PSD individually.
Screens are the sections that eventually get stitched together with the Components in the Master. They are meant to be all the individual content pages of a project, things like the home page, about us, and feature pages. I needed to consider the inclusion of Layer Comps in this system as well, as they are the best way to create separate interaction states of a design in a single file. To cover the Layer Comps scenario, I had to first get this amazing update to the standard Layer Comps to Files script, then I imported the saved out Layer Comps as new dynamic items in the Master. I needed the updated script to ensure the filenames are always the same when exporter Layer Comps - with the built in variant, there are aways sequenced numbers before the Layer Comp name, which are susceptible to change if they are ever reordered.
Screens are essentially the linch-pin that allows multiple designers to work on disparate sections pages across the project, however the sections need to first be divvied up so there is no confusion of who works on what. I tried this out on one of my current projects and at one point we had 3 designers working on separate pages and feeding them all into the Master without any issues - simply because all the screens were separate PSD's.
The Master is where the Screens and Components are collated together into one final set of composite. The way sprited Components are used is the group them in a masked folder to only show that needed portion - for example on the sketch shown to the right, all the states of the nav have been sprited out but we only need a particular one at any given them. With this system the layer would simply move up and down to show the right part of the nav. This would be the same for any other component that has multiple states capture in one sheet - like buttons (highlighted, hover, clicked) or even modals. Screens are imported on a page by page basis, if a Screen has a sub-screen then once they are exported via Layer Comps, they are brought in individually as well. The Master is simply the aggregator of all the outside elements, and uses Layer Comps itself to hide/show whichever Components and Screens are needed.
Making it work
To pull this whole concept together I needed 2 parts - the first is an excellent extension written by Aaron Powers called CanLinkIt (this should have been built into Photoshop 10 years ago) which handles all the dynamic linking between files, and the second is Dropbox or any other file sync solution which enforces a common folder structure. As long as you have these two things, the framework should work flawlessly.
I put together a small project to show how the concept works in practice. Its nothing crazy, just a simple iOS app I designed for dog dating called Puppy Love. This should give you a good idea of how to split elements into sprited Components, how to divide Screens and export Layer Comps if necessary, and how to bring them all together in the Master.
NB - You will almost certainly need to re-link all the CanLinkIt Smart Objects in the Photoshop file, unless you have the exact same folder structure as me somehow, which you don't.
There you have it, a scalable, multi-designer approach to Photoshop projects, thought this could work equally as well for a team of one just jamming away on a complex project. Conceptually I wanted to show its possible to break up a single large scale project into smaller pieces that can eventually get pushed dynamically into an all encompassing composite deck - Using the Components, Screens, and the Master with tools like CanLinkIt makes this approach a reality.