|
Fully
Functional 30-day FREE Trial
-  |
06.08.04
 By
Lynn Stott
As more web practitioners have assumed the title of Information Architect
to describe the work they do, and as more information architects (and
user experience designers and user interface designers and information
designers) are multitasking on reduced staffs, information architects
have uncovered a wide range of ways to view both the practice and
ourselves practicing. Unfortunately, a common response to this multiplicity
has been to reiterate certain narrow definitions of information architecture,
to impatiently seek consensus, and to view with suspicion those who
don't fit.
The efforts to define our field and our role are understandable by-products
of our economic times and of forces in our contexts of practice. However,
most of us haven't paused to examine the pressures behind this quest
for definition, nor have we considered the options (and potential
advantages) of refusing to pigeonhole ourselves. This essay takes
a moment to do both these things. |
I'd
like to first examine the impetus behind the pressures we feel toward
narrow definition. Then, I'll suggest ways we can use insights about
our diversity to fight pressures to define our work narrowly and to
forge more respect for and responsiveness to the work of information
architecture as a whole.
Pressures to define IA
Fervent efforts to define information architecture far outpace the
evolution of the discipline in actual practice. As a group, we're
attempting narrow definition before our praxis has reached its natural
range and depth. However, we're not rushing to definition just for
the fun of it. We're under pressure from all sides-to justify our
positions, to demonstrate our value, to explain what we do and why
we need to be included in projects. The pressures to define our practice
and our role on web teams are varied, yet interrelated. Most fall
under these main themes:
Current economic pressures mean there are fewer IA jobs to go
around-and we're hungry;
We're under semantic pressure from Computer Sciences and IT to
craft our roles into something that better fits known protocols;
Despite gains in visibility and credibility, we often find it
very difficult to explain to others what we do;
We're involved in a bit of sibling rivalry with colleagues identifying
as professionals practicing user experience design (UX), information
design (ID), interaction design, and, sometimes, usability.
Let's take a moment to examine each of these elements more closely,
to better understand the context for our drive to definition. Then
we can ask whether it's really in our best interest to do so.
1. It's an economic thing
Business's constrictive response to recent economic uncertainties
means that, for the moment, there is less work out there than there
was three or four years ago. Corporate web groups have pulled the
purse strings tighter and have often (wrongly) deemed the value information
architecture brings to the web planning process to be luxury rather
than necessity. Information architects are starting to feel panicked.
This real threat to our livelihood is the first of many pressures
information architects are feeling to define our work. With pressures
to justify information architecture's return on investment (ROI) at
every turn, we feel compelled to define and clarify the format and
value of our deliverables, justify the time it takes to do the thinking
and analysis so much of our work requires, and explain repeatedly
to stakeholders why information architecture is necessary to the work
of the design and development team. As a result, we're seeking to
define our discipline more precisely and to demonstrate competencies
and deliverables that can be measured and evaluated by all-so they'll
see how we matter and will let us keep our jobs.
But we should be cautious. Our responses frequently take the form
of dogmatic entrenchment and can lean toward a potentially dangerous
commodification of our work. I suggest that both these outcomes are
undesired-even detrimental-to our success as a field of practice.
2. Pressures from IT processes and roles
The push for an easily evaluable practice and set of deliverables
comes, in part, from an information technology worldview. In many
corporations and in a good number of solutions firms, web planning
and development has been structured under models formulated first
by database development teams and information systems construction
and management. In many of these models, team participants are certified
or licensed in competency in particular programming languages or project
management protocols. Competency is measured based on passing certification
exams and deliverables are clearly defined according to the requirements
of the next "client" in the work process chain. This work generally
can be evaluated and, to a certain extent, duplicated, by any other
similarly licensed professional-regardless of that person's work context
or past experience.
| Complete
audio and web conferencing services - No contracts, subscription
fees or monthly minimums. -> more
info |
Since many managers and team members in web project design and development
spring from IT backgrounds, there is a general tendency to expect
the same type of standardization on web teams. And some web team roles
do conform closely to more traditional IT roles. In general, programming,
project management, quality assurance, and even graphic design roles
are not viewed as problematic.
However, information architecture (and related practices such as user
experience design and information design) has, so far, been less fortunate
in gaining wide acceptance. As many of our number have noted, IA (UX,
ID) done well is, for all purposes, invisible in the final product.
When a web solution goes live, decision-makers see graphic design,
images, navigation elements, and text. One can view the code for all
aspects of site function and presentation, but one cannot easily view
the products of the information architect's effort, because they are
so completely integrated into the site as a whole. For these reasons,
information architecture's role in project success is often questioned
by team managers and product leads, particularly by those who are
under pressure regarding the costs and timelines of solutions production.
[One persistent exception to the invisibility of information architecture
is the group of IA deliverables with roots firmly in the field of
library sciences. Metadata taxonomies, search term indices, and controlled
vocabularies are visible artifacts and their role in simplifying database
construction and search/retrieval interactions is not disputed. This
is likely the reason many more "successful" attempts to define information
architecture as distinct from user experience or information design
are those that define it in terms of library sciences categorization
and cataloging practices.]
Read
the Full Article
* First appeared in Boxes
and Arrows
About the Author:
Lynn Stott is an information architect and user experience consultant
with a Ph.D. in anthropology and religious studies. Her IA and UX
work is informed by insights and analytical processes developed in
10 years’ of instructional design, in academic work in community structures,
symbols and meaning, and in studies of literature and classical rhetoric.
She has developed in-house IA/UX teams in large corporations and now
teaches, conducts workshops, and consults with clients in a variety
of industries through her firm, Vivid
Think.
Read this newsletter at:
http://www.itmanagementnews.com/2004/0608.html |
|
 |
|
