"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
Sound familiar? It’s a basic principle used by software developers called “Don’t Repeat Yourself” (or simply DRY), which I feel has many implications that can be directly translated to the world of interface design.
Today, interfaces are commonly communicated through single states of an application, but executed by means of multiple Photoshop documents representing those entire states. This in turn encourages fragmentation, convolution, and repetition, ultimately resulting in projects which are often difficult to collaborate and iterate on.
So, what’s wrong?
Multiple documents mean multiple copies of the same elements, resulting in a greater margin of error. Not to mention the time wasted keeping everything up-to-date.
2. Poor Collaboration
Everyone has their own “system”, making it extremely difficult to work with someone else’s PSDs, often resulting in time wasted finding deeply nested layers and elements. For example, how do two designers work on a single screen? Are two copies created? How are things unified?
3. Unsophisticated Versioning
Keeping track of what is new and what is old continues to remain inefficient and complicated, even with tools like Layervault. In order to roll back a feature, the assumptions made are that you’re either:
- saving new copies at certain intervals, which can be cumbersome and results in wasted disc space, or
- that you’re using Dropbox, and relying on Dropbox to create copies at random intervals (not to mention the fact that if you’re not using automatic syncing, updating an existing, local copy of a project means downloading the entire directory from the server each time)
A Pragmatic Approach
It’s obvious that there are some gaps in the way we work; the bigger the project, the more glaring the gaps become. Let’s have a look at DRY one more time:“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”.
With this concept in mind, let’s go back to a few existing workflows, and build on top of them.
Layers vs. “Objects”
What if we took a step back from the single-canvas model, and, rather than looking at it as the combination of many layers, we abstract it to the sum of common elements? As in, looking at the representation of a navigation bar or table cell not as many pieces combined, but unique, reusable entities.
Reducing the canvas to its parts opens up some interesting options, as all of a sudden we’re no longer working with shape layers and text labels, but with objects, which is a huge notion because it brings us closer to that idea of single authoritative representations.
In essence: while a navigation bar or table cell may not be used again in a single mockup, it will most likely reappear somewhere else in your app, and turning it into an “object” allows us to reuse it many times, without creating duplicates.
What does that tangibly mean? “Smart Objects” in Photoshop get the scope of a single document (ie. they can’t be used outside of one PSD), but saving smart objects as independent PSDs (and effectively breaking the canvas down into a collection of smaller files) will remove that scope limitation.
In what sense does it increase scope? Now when we create a second mockup and want to reuse certain elements, we can create links to global files, rather than creating document-owned instances.
(NOTE: This is important because changes to global elements are now propagated across every mockup, automatically updating each instance in every context. This addresses our inconsistency problem by reinforcing reusability over fragmentation.)
Following this pattern for every unique “grouping” of elements across entire project essentially allows us to create a toolkit of global elements which can be combined to assemble an entire application. We’ll cover how that assembly actually happens in a bit.
What does this do for collaboration?
Regardless of how “clean” and maintained the layers inside a PSD are, finding a single piece of information is much easier if it’s contained within a single file (assuming each file has been named with some due diligence), rather than within a deeply nested set of folders or smart objects inside a single “master” PSD.
While it varies case-by-case, here’s an example of how we might name our demo app:
- /master – global elements that don’t change, such as the status bar
- /navigation – navigation controls
- /stories – content in a feed
- /assets – photos
How about version control?
Depending on how you setup your server/delivery method (eg. Dropbox or Github), working with a bunch of small PSDs means versions can be stored earlier, and git or other source-control tools can be used to keep track of iterations faster, without having the overhead of 3rd-party “team collaboration” tools.
Piecing It All Together
We’ve talked a lot about how a PSD can be broken up into many smaller files, but how does it all come together? Enter Illustrator. Let’s look at some of the things Illustrator can do that makes it a great tool for assembly.
Unlike Photoshop, Illustrator has built-in linking tools, meaning we can place a file into our document, and Illustrator will observe any changes made to that file and update accordingly. Not only that, but we can link to other Illustrator files, essentially letting us recursively link files. For example, a Twitter feed could be assembled in Illustrator from multiple “tweet” files, then inserted into an application “frame” in another document, containing navigation and tab bars.
Art-boards for screens
While Photoshop limits us to a single canvas, Illustrator lets us make as many canvases as we want, which gives us quite a bit of freedom. For example, we can assemble a number of different layouts side-by-side, and keep them in the same document. This is especially interesting in scenarios where same elements are being reused in drastically different contexts, such as a responsive application.
The Bigger Picture
So what does it all mean?
- By modularizing our resources and assembling them independently, we’re creating single, authoritative representations of information, and avoiding duplication and as a result, inconsistency
- In the process, we’re addressing collaboration issues by making resources more accessible and understandable, by means of readable files and directories
- We’re addressing source control by introducing lightweight project environments which integrate well into version control and remote storage workflows
That’s a lot to digest, but hopefully I’ve shed light on some insights I’ve had over the last little while that can help us work smarter, and with a slightly more pragmatic approach to the more complex workflows. If I’ve missed anything, feel free to comment below or tweet me @_gabrieloc.