SIGIA-L Mail Archives: RE: SIGIA-L: Re: jumping in on sitemaps
RE: SIGIA-L: Re: jumping in on sitemaps
From: Perrin Rowland (prowland_at_novocorp.com)
Date: Thu May 03 2001 - 18:40:13 EDT
Re: jumping inOK, my $0.01,
Is there not a difference between what we are calling a site map and what we
are using a site map for? Are you creating a site hierarchy? a site map? a
site architecture? A site flow? Perhaps we assume that these are all the
same things. Or that one document answers all these issues, when we all
know they cannot. Is not our first document an interpretation of information
so that we understand what it is we are about to build?
Deconstructing siteXXXX, I recently discovered that there are different ways
in understandingand presenting the information you have to work with but the
deliverables all serve the same purpose: presenting the information you do
have so you can move to the next deliverable that shows a greater level of
detail. Site maps (arch, hierarchy, etc) are all statements of
interpretation and they allow you to move forward to set up your user flows
and create your wireframes.
All of our deliverable are almost milestones in understanding your
information in order to push you and your team ahead in the next round of
detail. Sitemaps (etc) are high level interpretations of your data so you
can understand what loopholes or missing pieces of info you have and where
you have to pay attention to move forward. They are not definitive
statements. They are growing documents and a way of interpreting your state
in the project. They are a first stab at presenting what info you have
gathered and starting point for the next phase of the project.
And like many IA (ID) deliverables, I find that they are mainly argument
starters. A "Here is an interpretation, now we can tear this apart and move
forward with purpose" document. Very few of my deliverables are answers,
rather my deliverables reinterpret the information and the problem,
coordinate my team, get us on the same page and focus on the task. We tear
apart the doc or see where we have problems, and move forward to
illustrating further detail.
A sitemap to me, has always seemed a good way to interpret the goal planning
documents. Depending on what I use, I find that a visiual display is easier
to understnad thatn something people have to read. However, if your
audiences are not understanding the information you are presenting than you
have to redefine your sitemaps. Almost all information can fall into a map
form. Redefining how your maps work can help you present your information
clearly. No one says a sitemap has to be done in Visio.
Check out www.cybergeography.org
They have dozens of mapping techniques.
Senior Information Designer
Professor Information Architecture
From: owner-sigia-l_at_asis.org [mailto:owner-sigia-l_at_asis.org]On Behalf Of
Sent: Thursday, May 03, 2001 3:30 PM
Subject: SIGIA-L: Re: jumping in
I agree on the site map issue... I am new at this, and the market I work
for (Latin america) is even newer. I just donít get site maps... How can a
static, limited and not user oriented document can communicate something
that is dynamic, unlimited (as in space) and supposed to be done with one
thing first in mind: the user!!!
I hate sitemaps, and I do have to work with them cause ďis just what IAís
are supposed to deliver first!Ē
That brings me to a point: strategist expect me to produce the site map
first (our methodology was put on paper by one of them)... I donít get it
either, when I do the rest of the process the first conception of the site
(the site map) changes enormously, changes again when I interact with the
rest of the team, including the client, thanks to their imput...
Anyway... I want to know what you veterans think!
(again sorry for my english!!)
A little new to this list, I'm startled by the need to talk about, the
to discuss deliverables and/or/instead of methodology. A woman of action,
I'm going to dive in the deliverables and methodology themselves.
I find deliverables and the way I practice IA to be intertwined, but not
blended. Site maps are the one piece that crosses over and I'm beginning
rethink the idea.
In a client service situation, I feel as though I have multiple audiences
(engineers, developers, marketers, business strategists, etc) with
goals and *none* understands site maps. With development teams and
engineers, I've found wire-frames and butt-ugly prototypes are a better
of communication and then follow-up documentation that details the<
List archives are available at:
To subscribe or unsubscribe, send mail to majordomo_at_asis.org with the
appropriate command from the list below in the body of the message:
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:38 EST