[Sigia-l] Enterprise IA

[Thomas Vander Wal]

On 4/16/03 10:17 PM, "Listera" <listera at rcn.com> wrote:

> In my prototype-centric world the Dev team should be essentially
> constructing what's (functionally) indicated by the prototype, in much the
> same way a general contractor builds with an architect's blueprints.
> 
> This is the most efficient way but with one crucial requirement: that the
> IA/Design team (IA, project manager, business analyst, UI designer, etc)
> understand the fundamentals of app design (at least) to the extent that they
> won't spec/prototype something too costly, too time-consuming, too hard to
> maintain, etc.

I have had pretty good success using a requirements team (can be one person
if there is one with the background and desire to do the work) that includes
business analyst, IA (info/data capturing, structure, data modeling,
interaction design), visual designer, and programmer.  The designer is least
important in the req phase, but the programming is essential.  Many of our
projects have components going overseas to India for development and having
functional reqs and specs very well defined is important.  Much of the
design is done in the U.S. on site and it comes in initially toward the end
of the reqs phase.  I have been using functional wireframes when we need
prototypes to help flesh out the requirements to help reduce
experience-based requirements down the road, which are rather expensive to
undo.  

This is not a diminishing of design skills or need, but reality of clients
largely focusing on the skin and not the functionality.  Setting the design
can too early can greatly impact the flexibility needed to get the
interaction functionality and programming usable if not near perfection.
The wireframe prototyping greatly enhances the need for design to draw users
to where their attention should be to complete tasks.

The req team is best comprised with folks that are cross-discipline
experienced.  The IA role is not the West Coast IA as you point out but more
of an IS/LIS/Data Modeler.  The WC-IA (not water closet IA, that is
something completely different) falls in to the visual design component,
which can often fill be very helpful and fill the role for the visual design
role, as well as others where they have experience/competency.  I have found
that Enterprise IA requires a strong understanding of where information
lives, taxonomy, ontology, and where to store information for easy use and
reuse.  The information structuring outside of the interface has a much
greater importance than in Micro IA (Website development - the interface/top
layer IA is important also and very important) and demands somebody to
understand and handle this need.

> In a period where an incredible percentage of technical jobs are migrating
> to India, Russia, China, etc., it's more reasonable to expect IA/Design
> teams to gain better understanding of app development fundamentals than (for
> the immediate future) to expect the overseas development team to understand
> and impact design fundamentals. IAs, in the West, won't be embedded in the
> dev teams for long. (For years, for example, animated movies have been
> designed and architected in Hollywood and inked and produced in the Far
> East, notably in South Korea.) In the long, of course, this will even out.

On our off-shore development we get the opportunity to review the daily work
and comment, which is more time intensive on our side, which eats at some of
the cost savings.  This has been needed to over come communication
difficulties and deficiencies in perfectly writing requirements that can be
understood in another culture (finding workflow is not understood to be
build into an application, but something found in off the shelf products,
but products don't quite exist that do this very well with out the
information being in a proprietary document).

The extra work and detail put into the requirements, functional design, and
data specifications needed to ensure off-shore development success also
greatly shortens the local development cycle.  Much of the local development
can take advantage of a quick meeting or phone call to fill in the holes in
reqs/etc., where off-shore questions could stop development for a day to get
a response or assumptions are made and may need to be undone.

> So, going forward, it becomes even more crucial to produce a functional
> prototype than to hand over to the dev team (that may be continents away) a
> thick pile of docs, charts, use-cases, etc., which they would have to
> reconstitute and interpret into code.
> 
> It all comes to: show'em how it works.

Exactly.

All the best,
Thomas