Unique situations

[Krista Van Laan <kvanlaan -at- UNDA -dot- FI>]

This started out in response to the thread about how much time writers spend
with the engineers. I seem to spend more time with the developers than do the
other people who responded.

I may have a unique situation, though, and I thought it would be
fun to tell the members of this list about what I do. I'd like to
get some ideas from others who have been in similar situations. I'm the
only native English speaker in a Finnish company where _nothing_
is written down. There are no specs, no product plans, no requirements.
After a program is "finished," the developers and user interface
designers continue to play with it until the last possible minute,
adding and changing features and designs until I'm ready to scream.

On top of that, our product (prepress and photo retouch software)
is designed for highly specialized users. So I not only need to
know how the thing works, I have to advise both
beginners and professionals the best way to use it. The only expert user
in the company spoke almost no English when I came here 2 years ago.

I spend a huge amount of time trying to think of everything that might
happen, and trying to get information. One problem
I encounter is that even the Finns who speak wonderful English
have a difficult time reviewing the drafts. It's a lot of hard work
to read a second language, so sometimes I notice they just look at
key words. More than once I have been wrong about crucial details,
but the reviewer didn't notice because he saw that the important words
were in there. It does help ensure that I don't write anything tricky.

But getting back to the issue of how much time people spend
talking to developers, I was surprised by you people who said you
spend very little time talking to the engineers, and I was wondering how
you are able to learn more than the surface details. Do you really
do it by reading the code?

I can behave as a user, and learn that if I select button A, window
B comes up. But how do I learn that I can also
get to window B by pressing some kind of keyboard combination, or
what I do in a trouble situation, or in what situations you use
a certain aspect of the program? I want to be able to tell a user more
than he or she can learn by trial and error.

It's interesting, anyway. Anyone else out there in an unusual
situation? How do you handle it?

Krista Van Laan
kvl -at- unda -dot- fi