[Sigia-l] card sorting: dealing with multiple placements
Derek R
derek at derekrogerson.com
Sun Jun 1 16:11:01 EDT 2003
>| When order is not observed . . . .
I have a good feeling about the direction of this thread, that it might
teach us something, as builders of Information Architectures and people
genuinely engaged in producing real and solid structures from which
information can be exchanged and communicated without bumping into
obstacles.
My point is, IAs have a pre-conceived idea what they want out of a
particular encounter with a user (whatever you choose to label the
encounter) -- that the IA has, going in (a priori), a 'deliverable' in
mind. IAs call a lot of encounters like these 'exercises' (for instance,
a 'card-sorting exercise'), whose labeling further underscores the
*pre-arrangement* involved with this IA-sensibility. The tendency to
operate this way, this behavior, is counter-productive simply because it
eschews the existing 'way' or 'order' of things (what is real) *in
favor* of its own matrix and pre-conception. This is done because it is
the easiest thing to do. The 'deliverable-method' (my term), results in
something one can walk-away with, something tangible which indicates
labor has been performed (so you know as a business whether you got your
money's-worth or not, a ROI-strategy).
Clearly we can observe a strong pocket of IAs with LIS-backgrounds and
roots which have taught them (any casual glance at their educational
curriculum will show) how to produce deliverables and how to facilitate
others in doing the same -- for instance, the 'reference-interview'
where the librarian sits down with a person and 'helps' them build a
'research-deliverable' as a road-map/check-list for stability/authority.
The aim is *always* to end up at a fixed and predetermined
place-of-stability with which one can walk-away feeling satisfied.
Indeed, this is the definition of the 'deliverable' which I use here --
something promised for something desired; a 'surrender for security';
production, exclusively, of what is expected (i.e. 'The pitcher
delivered the ball').
Now, this is all fine and good in our understanding and indeed it seems
quite natural that this 'deliverable' is what the Information Architect
would want to be about. IAs of course (one assumes), should WANT 'to
deliver' an architecture in the information/IT environment using all the
methods and skills at their disposal. This is all naturally reasonable.
Except, we have been down this road before. We have *experience* from
using this above described approach, and this experience teaches us
differently. It teaches us that we may be kidding ourselves in believing
that we can supply what is desired or expected and get away with just
that (Boo.com). It teaches us that anything in life is not that easy,
that it might require more work and labor on our part than we originally
expected or thought in order to reach achievement (AOL/Time-Warner). Our
experience teaches us that even though we believed, or lead ourselves to
believe, one-plus-one equals two upon going into a venture, that *in
reality* this doesn't automatically compute (Pets.com). How things
*really* add up can be quite different than expectations. The
abstractions we dream of do NOT necessarily transfer over, seamlessly,
to rugged hard-nose experience. Indeed, we learn that there is NO
substitute for 'experience' (Amazon.com) and one can NEVER *know* what
will happen with anything, until it necessarily happens. Suddenly what
is naturally reasonable takes on a whole different meaning.
But, don't get down or begin feeling defeated. Our lofty ideas,
fortunately, just end up being what they are -- 'lofty.' Our ideas and
abstractions, facilitations and conciliations, in the same way, are just
what they are. They are a head-in-the-clouds mentality. They are the
top-down, God-view approach which is quick and easy, being absolute, but
ultimately born-out-of negative attention. We are NOT God-like deities.
Only a fool thinks they know it all. We must build from the bottom-up,
from the foundation, if we are to achieve, and this can be more
difficult.
First of all, slinging-your-butt low-to-the-ground, to bend-down low, is
dirty business. You reap what you sow, so to speak, in the bottom-up
approach. But perhaps I've said too much already and discussion of real
and true methods (things in pursuit of achievement), should be reserved
for another day. For now it might be sufficient to note that 'dealing
with multiple placements,' dealing with reality (what actually occurs)
is all-together different and unlike any conceptual ideal (what an IA
may have in their mind as a simple 'exercise' in pursuit of a
'deliverable' which can be handed-over, hands clean). We need to be more
than this 'expected' or 'desired' mentality if we are to build REAL
information architectures and use the title 'Information Architect.'
Without doubt, we need to 'deal with' things, and do it in a genuine
manner, not just face-paint, so that we walk on-the-path, and do not
just fool ourselves in believing we're 'on-course' so we can get paid.
The rewards of actual achievement are far greater and produce much more
monetary reward, being successful, because it endures (not pacifies).
More information about the Sigia-l
mailing list