[Sigia-l] Role Creep - From Apples to Pears

[John O'Donovan]

I don't really care about the definition of IA but I do wonder about the
application of IA in terms of deliverables, process, methods and the roles
IAs play in a team.

There is a hint of devils advocate below but I'm really looking for
comments - if you don't like what is said, just don't all bite me at once.

The arguments around what an IA is and the reactions to it are very
revealing - this is a group of people who do not like to be boxed and are
unwilling to fully describe what they do as if this would in some way limit
them. I find this viewpoint very naive yet totally sympathise with it - I
hate being boxed.

None of what follows is to say that I do not hold the principles of IA in
high regard, but lets stop re-inventing the wheel and get to grips with how
IA fits into the process and the team. What are the deliverables? What is
the process? What is the Team?

Software design has been dealing with IA type issues for years and
struggling with the complexity of them. What has proved useful is the
definition of framework processes and methods. This has ranged from "Lets
just get on and build it" to "Lets plan everything before we start" -
neither of which are particularly useful but there is a lot of ground in
between.

As an example, think about these principles:

- Active user involvement is imperative
- The team must be empowered to make decisions.
- The focus is on frequent delivery of products.
- Fitness for business purpose is the essential criterion for acceptance of
deliverables.
- Iterative and incremental development is necessary to converge on an
accurate business solution.
- All changes during development are reversible.
- Requirements are baselined at a high level.
- Testing is integrated throughout the life-cycle.
- Collaboration and cooperation between all stakeholders is essential.

They are the principles of a systems methodology, DSDM, which has solid
founding in other methodologies that pre-date it. If you find this too
restrictive then there is no hope :)

Why use a methodology?

1) You will understand how you are going to apply a toolset in an end to end
process
2) So will everyone else

The following comments set some alarm bells ringing:

Christina Wrote
> I'm tryign to find an IA who knows stuff like taxonomy
design/classification
> and the like-- and I keep geting these site map+interaction types.. west
> coast IA's. How do you tease them apart? Anyone else go up aginst this
> problem? advice?
> My apologies if I gave offence-- I just hit hard the wall of our fuzzy
> definitions.... I wish we were clearer...

> In my experience, stringent highly structured methodologies breakdown and
> get thrown out, while highly flexible toolkits of skills and techniques
are
> better suited to the wide variety of problems that come our way.

JJG wrote:
> I have some slight reservations about the "IA can be taught" part -- IA
> can certainly be *learned*, but perhaps not from a teacher -- but the
> point about instinct is right on.

I think this final point is a distraction but I am interested to understand
what could not be taught. In this context I think the whole point is that IA
needs to be taught. Maybe categorised...

When it comes to frameworks though I can buy into the Adaptive Philosophy or
the Cooper Process. From a consultants point of view you do need to
understand what your engagement will be otherwise the client won't know what
they are getting. Thing to remember is that there are other methodologies
and members of a team - if the input an IA makes does not gel with this then
it's value is reduced.

I am very much coming to the opinion that IA in the broad sense is not a
role, it is something that you do within your role. It needs to be *applied*
to make sense.

My job is not specifically titled IA, yet I find that I work across many
similar issues which is why I am here and interested.

IAs appear to want to be involved in many parts of the process, but they
partly suffer from what I would call "Role Creep" - IAs want to be involved
in and own so many parts of the process that it's difficult to see how they
fit into the team. To quote Alan Cooper:

"you need to have "skin in the game". You have to be committed. Not just
prepared to stand on the sidelines and toss [their] advice in to the guys
hitting hard - the programmers."

This applies to multiple areas of design and build (not just programming)
but the implication is clear - what strategic value are you adding and what
are you delivering to the people who are building whatever it is you are
building.

For example, if you are dealing with front end build, what are you adding if
you have experience in taxonomies? Is it more important to consider the work
around classification / categorisation / content analysis / etc and deliver
this for the front end team to work with - the framework that they can
apply. If you are also a designer / developer working with UI then great,
make input, but otherwise back off a bit.

Likewise, systems architects along with business, systems and data analysts
don't just deal with the front end. They deal with business goals, system
requirements, interoperability, etc... Methodologies and patterns are at the
core of this business technology modelling and therefore these need to be
considered. Perhaps these people don't need to work with an IA - they need
to become aware of IA issues which they likely already are.

Front end or back end, front end or back end...

So maybe we could think about these things, which are not an exhaustive list
but enough for now:

- An IA should state or understand what type of IA they are as would an
artist or programmer or scriptwriter etc. Even artists and painters will
define what type of art they do - few painters work with all materials. As
an employer you need to ask.

- You can't do everything on every project! And if you do try, you need to
accept that there are people who cover many roles already in greater detail.
For example data and systems analysts do solution modelling at a highly
detailed and contextual level. You need to figure out how to work with these
disciplines that may have very well formed methods and deliverables.

- From a methods point of view what will you deliver? How do you know that
this is all you need to do?

- You need to get strategic and think beyond the web. Thinking purely about
the web is often the limiting scope in most of these discussions. We are not
all building web sites, and even when we are it's not all about information
retrieval - but yet IA is still relevant.

- The role is difficult to define but then that is not the point - the title
is just a title. It is what you do that is important.

So finally, how do you make people understand that IA is a skill more than
it is a role?

Cheers,

jod

Also maybe read the following relevant snippets that you may or may not have
read before - there is more out there but you will need to find it
yourself...

http://www.boxesandarrows.com//archives/why_im_not_calling_myself_an_informa
tion_architect_anymore.php

http://www.livlab.com/texts/who-died-and-made-your-boss-of-user-experience.h
tml

http://www.interactionbydesign.com/thoughts/perspectives/00000003.html