EightShapes, LLC is a user experience design firm specialized in web sites and web applications.

Using a Build File to Source Your Library Artwork

A build file is a document used to create and maintain all of the page and component design artwork for an entire library of reusable assets. Yes – all the boxes, symbols, text frames, buttons, and more that you use to create artifacts like wireframes or comps.

At EightShapes, we create build files for each collection (typically, one per client) and lay out each component on a separate page, tied together neatly in a single InDesign file.That said, we’ve recently begun to drift from paginated Build File “documents” to Build File “posters” (read on below).

Why have a Build File?

You aren’t seriously thinking of publishing a library of reusable design assets by throwing bits from all sorts of different project deliverables haphazardly into a few stencils, right? Nah, you have to treat a library with a bit more care to be consistent and manageable. In fact, you have to compose library art deliberately, and treat it like source code. The build file provides the place – and mindset – to do just that.

  • By centralizing the entire library (or at least, a considerable portion of it) in one file, you can:
  • Cut, copy, and paste from one canvas or file, instead of opening, closing, and bouncing between multiple files
  • Synchronize and maintain typographic and objects styles as well as instantly propagate and review style changes
  • Aggregate contributions from different authors in one place, and smooth out differences between how each person distinctly constructed their parts
  • Export items to reusable libraries (a Visio stencil, an InDesign object library, an InDesign snippet) more quickly
  • Transform the build file into a useful deliverable itself: serve as a source artwork repository AND serve as a visual gallery that can be PDFed (see below).

One Build File or Many Build Files?

Why not create an individual file for each component, or even each group of components?

Once you separate the management of each library item into a different file, propagating changes becomes really challenging. Suppose you want to change the typographic style for “small paragraph” from 10pt to 11pt. One build file? Change one style, and skim across the artwork to check for impacts. Individual component files for source artwork? Open each one, change the style, see what’s different and if it breaks things, close the file, move on… 100s of times.

Build Files vs. Project Files

Should you architect a build file (source artwork for reusable library elements) to match how you architect design files for individual projects? Hardly.

The primary purpose of a build file is to maintain source artwork in a way that eases maintenance and exporting to libraries of reusable bits for everyone to use across projects. It’s just artwork, and there’s no benefit to separating out all that art into separate files.

In InDesign, that means a handy place from which you can create object libraries (.indl), snippets (.inds), or both. It’s actually very easy – and fast – to export each item from a build file. Select, drag, drop, rename. Select, drag, drop, rename. Select, drag, drop, rename. If your artwork is in separate files, then you’ve overlaid a tedious find, open, and close onto that workflow for each bit.

On the other hand, particularly with how InDesign works, it makes sense to modularize component artwork for a project in separate documents (.indd), so you can:

  • Reuse the same component file (.indd) placed in and linked to multiple page design documents (also .indd)
  • Lay out component variations together in one document (.indd) to foster comparisons, separate from the context of a page
  • Place that same component file (.indd) in a deliverable document (.indd) annotating the component  or reusing it in a storyboard.

Annotating the Build File

If you’ve used EightShapes Unify for any period of time, you’ve come to understand the distinct purposes of design files (namely, wireframes) and deliverables (namely, paginated documents). The templates, style namespace, page setups, grids – they are all distinct across those two document types.

So, then, if you’ve got a build file with wireframe components and page types (or other design artwork), should you really be muddling annotations content with it? Actually, sure, if the build file will also serve as a visual reference.

Tips for annotating a build file include:

  • Use a separate layer for all annotations, so you can lock artwork and not muddle the two
  • Use a separate style namespace for headers, paragraphs, and other annotations. In the build file, this is most easily accomplished by create a separate style folder called “annotations” or “deliverable” that separates that tree of styles.
  • Never, ever, export annotations with the artwork when creating the reusable libraries or snippets. Instead, keep that artwork pure so others can create designs without worrying about stuff that users don’t end up seeing.
  • Be brief and systematic with your annotations. Component groupings, sections, and brief intros may be helpful, but don’t try to transform the build file into the library’s full documentation. That’s insanity. If you find yourself extending beyond improving the build file’s use as a visual reference, you’ve gone too far. For example, the image of the [Page Title] component page probably includes too much documentation. It was hard to maintain and people wanted a web destination for that content.

Try One-Page Poster Build Files!

Since Modular Web Design was published in mid-2009, EightShapes has had great success composing the build file not as a multi-page document in tabloid or letter size, but instead on a one page poster. All the artwork is in one place, in one page, and assuming you are adept at zooming (CTRL-spacebar) and panning (spacebar), it ends up feeling very rewarding and efficient to build a library on that single canvas.

But even better? Teams have LOVED the output, not just in having the entire library easily passed off and it’s organization understood, but moreso because then people see the library:

  • Intimidating: Receiving a single template and…100s of awkwardly named items with tiny thumbnails across a range of library files or snippet folders.
  • Motivating: Receiving a single template and either opening a 1 page PDF or walking down the hall to see the entire component library landscape in one view.

Seeing the architecture of the library – how all the components and pages relate together in one big picture – has elicited sighs of relief and confessions of “Oh, it’s not really as complicated as I thought” and “Really, that’s it? That’s all there is?” That’s exactly the kind of small, incremental win you need to get a library off the ground.

While obviously small, grayed, and otherwise “sanitized,” the images above portray build files that are actually approximately 4’ x 6’ in size, plotter-printed, on display in UX team areas, and distributed as PDF that – if zoomed – reveal all the precise goodness and detailed love you painstakingly invested in producing it.

Learn More About Build Files

To learn more, there’s an entire section devoted to the topic in Chapter 11: Build of Modular Web Design.

RSS 2.0  |  Trackback


Comments

Add a Comment

Email addresses will not be published. Required fields are marked *