"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?

1. Inconsistency

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.

Creating Links

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.

  • Fabian Orthen

    Interesting approach! Wouldn’t InDesign be an even better tool for assembling with its ability to build interactions between pages?

    • Gabriel O’Flaherty-Chan

      I’ve considered using Indesign a number of times before, but find myself constantly returning to Illustrator, due to the fact that Illustrator has a far more sophisticated suite of drawing tools (eg. for one-off visual elements).

      Not to mention the fact that Artboards are vastly more flexible than Indesign’s “pages”!

      • Luca Rosaldi

        Yup. Not to mention the “Save for Web” feature, which is fundamental IMHO.

  • Benjy Stanton

    Interesting article. We use Illustrator almost exclusively for our web design workflow (only using Photoshop to create certain elements). Having multiple art boards really is handy when designing responsive websites, you can also set global colours swatches and paragraph styles in Illustrator (I think Photoshop has just caught up with this feature).

    • Gabriel O’Flaherty-Chan

      There are a few things Photoshop can do which keep me from ditching it entirely. For example — when creating assets, a pixel grid is a must!

      • Benjy Stanton

        I agree that Photoshop is probably better for pixel level detail, but I thought Illustrator does have a pixel grid (as of CS5-ish)? P.S. I love the level of detail that you’ve gone into with this article, the illustrations are superb.

        • Gabriel O’Flaherty-Chan

          As far as I know, the concept of a pixel grid is non-existant in Illustrator, which is a vector-only tool. Thanks for reading!

          • Shane

            A pixel grid is present in Illustrator, as Benjay says from CS5 on (maybe CS4 as well, can’t remember). Zoom in far enough and you’ll see your shapes as exported; work with “Align to pixel grid” always on and your vector points are aligned, and get the edges you’d expect and want on your shapes. It’s rare that I go back to PS for anything that isn’t editing a photo these days – for everything UI/webapp, it’s Illustrator all the way :)

  • ❧ david hoogland

    Interesting article indeed. I think I’ll give this approach a try on a project I’m working on right now. But instead of photoshop (or illustrator / indesign as in the previous comments) I recommend giving Sketch App a try for web en app design. I’ve been trying it out for a month or 2 now, and hardly open any adobe apps anymore.
    Thanks for sharing. =)

    • Gabriel O’Flaherty-Chan

      I’ve considered using Sketch in the past but have found it far too limiting.

  • Tim

    I wish sketch had something smart objects or links.

    • dannysmith

      I’d love this too.

  • Sean

    Interesting insight, every attempt to introduce fireworks into this work flow? i think setting up master pages and not leaving the pixel environment are some great advantages. Also consider that anyone (PM) can view the png files and linked image can be set up via an extension (http://johndunning.com/fireworks/about/LinkedImages)

    • lcandela

      Sadly Fireworks is dead. The last iteration is full of bugs, especially if you use it with a Wacom tablet and highly unstable. Adobe killed what conceptually was their best tool for UI design, I hope they are going to replace it with something better, so far they haven’t.

  • Stéphanie Walter

    I used to do the contrary : creating artwork in Illustrator like icons and send them as smart objects into Photoshop, but I really like your idea and might give it a try for interface design. Do you have by any chance an exemple of this into files that we could take a look at and play with just to test the method ?

  • lcandela

    I did that in the past, it was ok for myself but broke down collaborating with others that were less passionate about keeping things neat. Truth is, Illustrator or any other Adobe tools are not designed to work this way. Pick up Antetype and you have all the benefits of this approach with none of the downsides.

    p.s.: I’m not paid by them in any way, I just like the tool.

    • http://allanwhite.tumblr.com/ Allan White

      Antetype looks very promising. I’ve been bouncing between Illustrator (artboards FTW!) and HTML mockup tools like DivShot and jetstrap, depending on how much fidelity the client needed.

      I think if I was doing UX full-time, Antetype or something like it would be a good choice.

  • marcelomazza

    Great methodology!

    It’s sad to say this, but Fireworks (R.I.P.) would be an even better tool for doing this: you could use Common Library to share repeating elements across different documents (like linking in Illustrator). You could even set different states for those elements. And instead of artworks, you could have different pages on each PNG… we’ll miss you Adobe Fireworks :(

  • Rasheed

    I like the approach, though I’m using a retina MacBook and photoshop only has a retina canvas making designing UI components hard because everything is 50% smaller. This is a known issue for all who are using photoshop on retina machines. Any suggestions? I’d love to try this approach.

    • Gabriel O’Flaherty-Chan

      Design in retina.

  • Olof Olsson

    I would love to try this. Would you care to prepare an example for download?

    • Gabriel O’Flaherty-Chan

      I’m working on it, stay tuned!

  • NetscapePizza

    Use Fireworks…

    • tranhelen

      Fireworks has been deprecated. Although using Fireworks may work now, depending on it for your workflow full-time may not be the best choice.

  • http://www.lepetitgarcon.com/ Anton Sten

    I’ve just adapted to a similar workflow but as mentioned below, using InDesign instead of Illustrator. I think what you loose in vector tools, you gain in performance. I think it works far better to move multiple objects across artboards in Indesign compared to Illustrator. And what’s the big difference between Art boards and Pages?

  • Caleb

    Sounds like you’re craving Adobe Fireworks Symbols and States. So should Pho-Pho Shop just absorb that functionality??

  • Patrick Visser

    Great write up and a workflow I adapted a while ago. I’m still hoping that Photoshop will incorporate the linking smarts of Illustrator so we can share Smartobjects across PSD files.

  • Hervé Mischler

    Great article! This is also the way I am working. I create templates in illustrator with a complete library of reusable components and I have different artboards for portrait/landscape on 4″, 7″, 10″ screens depending on the projects we are working on. Illustrator is a great tool to deal with multiple resolution and working at the component level makes it easy to export assets for multiple resolution (especially for Android).

    9-slice scaling in objects is a great feature that makes illustrator a good alternative to fireworks (even if it’s not perfect).

    Having a library of components is a good way to separate Visual design and Interaction Design and to enable both team to work at the same time on their tasks.

    The final screens can be done in illustrator based on the wireframes but the real thing will only appear once it’s implemented in code.

    I’m not a photographer and therefore I never use photoshop and I don’t understand why people are still using it to design user interfaces.

    Illustrator is a good choice is you are designing native applications, but if you are designing web apps the tool of choice is definitely code and versioning your designs using git.
    The component approach will be exactly the same as in illustrator but the reusable component will be built using CSS preprocessors like SASS or LESS.

    I’m thinking of doing a full post on how to design applications for the mobile web… stay tuned ;)

  • James

    Funny how it looks like print design workflow circa 1995. (Create individual treatments, copy, illustrations, etc in Illustrator and Photoshop and Word, and assemble the layout elsewhere.) Totally agree that InDesign could handle the job assembling all the pieces together – it’s what it was built to do. Multiple paste boards a bit kluge IMHO.

  • Trevor McNaughton

    This is great, I’m currently struggling with refining our process at work and I think this could be really helpful. I never thought about piecing all of the parts together in illustrator either. Super clever.

  • http://jacobmcdaniel.com/ Jacob McDaniel

    Really great concept here. Have you tried the latest tool from UI Parade called PixelDropr? http://pixeldropr.com/

    I use this daily and it has changed my life in a very similar fashion. I do like this approach though. Very interesting and thanks for sharing.

  • Denis Kugappi

    When you have a series of engrained habits, it can be quite difficult to adapt to a new workflow, but this article makes a great case for rethinking or rediscovering alternate design systems. Designing atomic components as opposed to pages as an idea isn’t new, but is yet to be embraced en-mass, or effectively implemented in most shops.

  • Silviu Bucsa

    Very good article, this is something I’m doing for a while with large projects and the things that saved and kept my sanity (to a degree) are these:

    http://www.canlinkit.com/ – in a nutshell a plugin that links external psd (smart objects) to a master psd – just like Illustrator / InDesign does natively.

    and Pixelapse / LayerVault – the visual versioning tools.