[Sigia-l] IA Practice Maturation

[Patrick Hunt]

Customizing documents to each particular stakeholder or group (clients,
business users, GUI designers, developers, etc.) is good in theory but
difficult in practice. Outside of using enterprise systems such as those
offered by Rational Software, how do you manage multiple versions of
multiple variations of multiple documents? Change control on the
documentation alone could become a full-time job, even for small to
medium-sized projects.

Taking cues from other list members' good work, I'd rather create different
levels of (mostly) non-repetitive documentation which I can use with
different user groups. For example, the conceptual model is at the highest
level and is least detailed, followed by the site map and storyboards at the
next level, and the wireframes, content inventories and other specs at the
most detailed. Of course, this doesn't answer the problem when one designer
wants a lot of detail while another wants little.

As an aside, I've recently encountered a situation in which the developers
use the term wireframe to describe "ugly HTML" that designers and IAs have
not yet touched. These wireframes are used for creating rough,
proof-of-concept prototypes of back-end functionality, or as frameworks for
the presentation layer.

Cheers,

Patrick

> From: PeterV <peter at poorbuthappy.com>
> Date: Wed, 17 Apr 2002 14:36:48 -0400
> To: "Peter Merholz" <peterme at peterme.com>, <sigia-l at asis.org>
> Subject: Re: [Sigia-l] IA Practice Maturation
> 
> 
>> Another point of extension, which Victor mentioned, is building a bridge to
>> more of the hardcore technical types--the database administrators, computer
>> programmers, systems engineers, and other folks whose systems we will
>> increasingly rely upon, and whose systems need to be increasingly aware of
>> our requirements.
> 
> I have found working with the techies fairly easy. They come from a
> requirements gathering / UML angle, I come more from a usability / IA
> angle, but we both want good requirements. In the company where I started
> the IA department, I sold IA to the techies as requirements gathering. I
> would make sure to get lots of feedback from them on how they liked their
> requirements: rare, well done, UML, use cases, whatever style they liked I
> tried to adapt. The same with the visual design people. The ones I worked
> with liked their wireframes with lots of detail, so I gave them lots of
> detail. One other one wanted them as spare as possible, so I did that for him.
> 
> One painpoint was how far do you go with your requirements towards the
> techies, while still keeping them readable for the client for signoff. We
> kind of settled on a high level (but still pretty detailed) requirements
> doc (with lots of wireframes but little backend functionality details) for
> the client to sign off, and then a "techie tech spec" for internal use
> only. It was never perfect though, I spent two years working with everyone
> trying to improve documentation so it was easy for them to work with.
> 
> In one case I wrote a high level spec that was supposed to be followed by a
> detailed technical spec, but that step was skipped (because of
> misunderstandings working with a team on a different continent), which lead
> to lots of annoyed programmers and project managers later on in the
> project. Don't let it happen to you!
> 
> Things I learned:
> - wireframes work for clients, but for developers you need to add use cases
> to make things clear.
> - high level use cases work for clients
> - sitemaps work for clients
> - having two specs allows you to add high level descriptions into the spec
> for clients which don't really affect development but that they still like
> to have in there. (ie. The system will be easy to use by
> - a separate spec documenting business and user goals is a Good Thing.
> - many IA deliverables don't need to be signed off, as many of them are
> really working documents (audience analysis, user research, mental
> models...), meant for discussion more than directly relevant to
> implementation.
> 
> PeterV
> http://petervandijck.net
> http://poorbuthappy.com/ease
> 
> 
> Content Management Symposium, Chicago O'Hare Marriott, June 28 - 30.
> See http://www.asis.org/CM
> _______________________________________________
> Sigia-l mailing list
> Sigia-l at asis.org
> http://mail.asis.org/mailman/listinfo/sigia-l
>