[Sigia-l] The fuzzy line btwn IA and Design

[George Olsen]

Christopher Fahey [askrom] said:
> This question assumes that the Designer is the "recipient of the IA
> vision".

Having come from the design side of things, that's the attitude that really
drives designers up the wall -- especially if they really *do* know more
about layout than the IA.

(There's a whole issue about younger designers who resent being art
directed at all, whether by an IA or an art director, but that's a
different post...)

> but I also like to, as the IA, be the "recipient of the
> Design vision".

We definitely need to be open to things, especially if our background
hasn't involved much design. Let's be honest in acknowledging the things
that *aren't* our speciality. It ain't necessarily IA just 'cuz we're
involved with it.

That's why Christopher's specific recommendations are good ones, especially
the idea of a "visual checklist," which is actually a good way of
presenting it.

I'd actually moved away from "schematics" or "zone maps"
(Christopher's "navigational wireframes") in favor of written checklists
with some description about general placement (i.e. this should be
clustered with that, these need to be above the fold, etc.)

However, I found that written checklist can be hard for some designers to
understand, since they think visually. So Christopher's "exploded cloud" or
a cluster map probably is a good middle ground.

And discussing the layout with the designer is key. Ideally, two sit
together while the designer thumbnails (on paper) various layout ideas
based on the visual checklist.

This doesn't mean the IA has to automatically accept the layout, but
the "burden of proof" should be on the IA come up with a good reason before
speaking out. A left-hand nav might be equally effective as a top nav, in
which case the IA should go along with it -- even if it's not the way
*they* would've done it. But there's a good reason why it's a problem, then
the IA should speak up -- and be prepared to explain the issue.

Conversely, the "burden of proof" should be on the designer before making
any radical alteration of what's on the visual checklist or the interaction
design (i.e. the flow of screens). I won't go as far as Robert and say they
should never change these -- but the designer should be able to demonstrate
why their change is better. And ideally, it's something they've talked
through with the IA/ID/UX already.

> (2) You are often freed up to use some semblance of the correct fonts
> and colors in the subsequent bulk of page wireframes, too. Conventional
> wisdom says it's a good idea to make wireframes in greyscale or black
> and white, but if you already know that all of the headers will be red
> and that all of the fonts will be Verdana, then why not make the
> wireframes reflect that?

This can be useful because the layout often can clarify issues that might
sometimes appear problematic in the wireframes, i.e. color and size
contrast might resolve a potential problem distinguishing focus among
multiple elements.

But it can also be dangerous, depending on who you're presenting to. Some
people won't understand that parts of your wireframes are "real" and parts
are still "rough," leading to potential hassles for both the IA and the
designer about "why does it look bad." So sometimes it's better to keep
things lo-res.


The main thing, as has been said before, is that it needs to be a
collaborative process.


_____________________________________________________________________
George Olsen                           george at interactionbydesign.com
User Experience Architect                                310-993-0467