[Sigia-l] IA Practice Maturation

[PeterV]

>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