Article Idea:
Know Your Place
suggested by Nathan Curtis on 2006/01/02
Site coders have server-side includes; visual designers have style sheets. Why can’t information architects join the party? How information architects can structure creative documents in hierarchically nested and reusable ways.
Problem:
Once you start on a second draft, wireframe variation, or even a list of product-based search results, you can feel like you’re doing the same thing all over again: create a header and footer, cut-and-paste a product title/abstract/photo, and more. Then, it turns out you forgot to add a price to your product display, and now you’ve got to update the 6 wireframe variations each with 4 product listings that now need a price.
Solution:
Includes. By linking documents via the Place command, you can nest your entire hierarchy of deliverables: components into pages, pages into flows, components into flows, and each of these into your design spec. Your modifications propagate throughout for faster updates, and your reusable elements enable a quicker, more scalable design process. Separation of content from presentation indeed.
Likely category:
“How to: Deliverables & Documentation”
Software:
Adobe Illustrator & Adobe InDesign
Outline
=========================================
Breaking down a design
————————————————————————————
Component (of a page; e.g. header, product search result, or mini-shopping cart)
Page (via wireframes)
Flow (within a site or application)
Specification (of the entire solution)
The epiphany: Knowing the right “Place”
————————————————————————————
Nesting components within wireframes
Nesting wireframes within flows
Annotating key displays via component variations within flows
Updates? How does automatic sound?
Variations: The key to the communication kingdom [potentially different story]
————————————————————————————
The default
Condition-based variations
Diagramming an interaction
The error state
Placing documents and managing your links
Assembling Documents
————————————————————————————
Want to see this idea turned into a story?
3 people said yes. | 0 people said no.
Nathan Curtis
39 Reputation points
Posted 2006/01/02 @ 07:12AM with
Submitted by Nathan Curtis (nathan@nathancurtis.com), UX Design Lead @ K12, Inc.
Liz Danzico
1095 Reputation points
Posted 2006/01/02 @ 14:36PM with
Neat. You mention Illustrator and InDesign. Would your solution be program-specific, or, are you intending teh article to be more of a methodology that can be applied across programs?
Donna Spencer
159 Reputation points
Posted 2006/01/02 @ 15:16PM with
If you partner with someone who knows Visio, you could cover it in the same article (Visio does all this easily)
Nathan Curtis
39 Reputation points
Posted 2006/01/03 @ 05:06AM with
Donna & Liz,
Thanks for your comments. I would certainly approach this from an methodology perspective. While Illustrator is my vector-based program of choice, I use Visio extensively as well, and would be curious myself to know the analogous Visio techniques.
Nathan
Donna Spencer
159 Reputation points
Posted 2006/01/03 @ 22:39PM with
Background pages (which are nestable and work well for big decks) and shapes (which can be modified and updated across the wireframe deck with the right Visio version, and tediously copied with the wrong version)
Nathan Curtis
39 Reputation points
Posted 2006/01/04 @ 05:28AM with
Background pages can be very effective for making your document professional by providing information on contact (name, group, email, etc), sponsoring company (via a logo), versioning & date, and more. I’ve also found background pages are effective in creating a reusable frames for your page and spec (ie, columns for annotations, etc) if you choose to go that route.
Shapes are probably closer, employed via edited stencils across documents. I’d advocate the use of *Insert > Object > Create From File* followed by *Crop*ping the included object to highlight only the component variation of interest.
For example, imagine you’re including a mini shopping cart through varied views in your app. The mini-cart will ultimately have numerous potential displays, including but not limited to empty, one item, multiple items, different item types potentially requiring different attributes to be displayed, etc. These *component* variations would be centrally stored in .vsd file with a page containing the grid of these variations. For each *wireframe* variation (in a single file or probably best here in separate files), include the object and crop it to the proper, single variation. Then, you can include each *wireframe* as needed into a *flow*, also as objects but probably resized to be much smaller unless the plotter is your destination. Finally, as one *spec*’s the final design, the *component* grid could be included as a figure where, cropped or not, you can annotate the variations in tandem, for such illustrations can be powerful in conveying the breadth of component functionality for a developer.