"Design" was Re: Tech Writing a Growing Field?

[Ned Bedinger <doc -at- edwordsmith -dot- com>]

Chris Borokowski wrote:
> Technical writers as
> articulators can make sense of the design process, and
> distill it to a logical map. They can refine this map
> in a way that people caught in the trenches of
> marketing, development or user testing cannot. In this
> role, technical writers are an integral part of the
> design process and can do more.
>   


I'm not clear on whether you're suggesting this as something that tech 
writers generally need to be aiming for, or as something like a 
deliverable on a per project basis. So I'll write out my thoughts and if 
you see something of interest then you can ... well, you'll know what to do.


I think this point of yours harks to tech writer manifestos that want us 
to be integrated into the full product development cycle. I need to 
steep in a project to become an integral part of the design process. I 
do subscribe to the theory and practice of long-term project membership 
for tech writers (even when it means working in the crossfire of 
marketing, development, and testing), but I think the design analysis 
functions you mention (making sense of design process, distilling it 
into logical maps) don't fit with the documentation role.


Here are a few initial thoughts on tech writers and our brand of design, 
which I mean in the sense of information design, not geometric 
decorations, fancy fonts and rubric, or whatever.


I do think tech writers are exposed to the vagaries of having to write 
even when the project's requirements and design phases have been done in 
mushy, unsatisfying ways. This is what drives an awful lot of 
information design problems, and is a root cause of mushy, unsatisfying 
documentation (MUD, in shorts).


I also think tech writers are likely, over time, to become sensitized 
and alert to problems that begin with and propagate from weak 
development of the project's requirements and designs.


But for tech writers, design is something that we do in order to be able 
to work with poorly specified projects/products. It is different (even 
as a process) from what other designing members of project team do, for 
example what product architects and engineers do.


Bottom line: I'm willing to articulate my design process, and I imagine 
it is analytical enough to provide some leverage to other team members. 
But I don't see how I would know or articulate THE design process that 
might be influential or of working value to product architects and 
engineers who design their own contributions.


So, in this framework, I wonder if you are saying that tech writers 
should try to drive the requirements and design phases because we're the 
test case--if we can't find the information needed to understand the 
product and project, then something is wrong and needs to be fixed first?


Does this comment make sense in the context of yours? Perhaps my point 
is a kite, but anyway I've been reading about and mulling this design 
thing around for a long time, and am dragging it out into the light 
because it sounds sort of like what you've said.


I'll go a little further with this because I might not get another 
chance soon.


When I read your remark about the contribution tech writers can make in 
areas of design, I think of experiences where asking questions and 
checking my understanding has helped me AND my interviewee become more 
clear. In more general terms, I see that we can facilitate some aspects 
of the design process by capturing what is said in SME interviews and 
dev meetings. We can diagram, summarize, outline, and flow what we 
learn. We can then put it back out for review and validation. In doing 
these things, we can provide a documented perspective, and in some cases 
it would be the only documented perspective and some people would find 
it useful. We do this on smaller scales too--I'm sure a lot of tech 
writers have heard something like "Hey can I have a copy of that?" when 
the developer or SME they're interviewing sees the notes/sketches made 
in the interview. In other words, sometimes we capture and express 
design that is sub-explicit. We make it explicit, it becomes subject to 
review, discussion, revision, ...


But conventionally, I don't expect to see or hear the lion's share of 
the considerations that the architects/designers are processing. 
Sometimes it seems like I'm in the catbird's seat--I do have a lot of 
experience, can provide useful insights, and can ask penetrating 
questions--but as the writer I do not have all the facts, and I don't 
have the engineering background, and even if I had both I would probably 
not come up with the same solution as the other members who have the 
facts and training. This just seems like a lot of baggage for me as tech 
writer. At that point, look out, I'm doing less shuttle diplomacy 
because I'm now covering yet-another-angle of the crossfire. With the 
right role and skills, maybe that would appeal to me, but from where I 
ordinarily sit, it doesn't look very inevitable.


Thanks for asking, hope this helps.

Ned Bedinger
doc -at- edwordsmith -dot- com


>> believe that if only they can create the cleanest,
>> most precise CMS and single-sourcing solution . . .
>> . the documentation will write itself? The engineers
>> really *can* write the doc, because the structured
>> doc interface will force them to write for users?  .
>> . . something like that!
>>     
>
> User Interface design blog
> http://user-advocacy.blogspot.com/
> Code::Design::UI::Consulting
> http://www.dionysius.com/
>
>
>  
> ____________________________________________________________________________________
> Don't pick lemons.
> See all the new 2007 cars at Yahoo! Autos.
> http://autos.yahoo.com/new_cars.html 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> Create HTML or Microsoft Word content and convert to Help file formats or 
> printed documentation. Features include support for Windows Vista & 2007 
> Microsoft Office, team authoring, plus more.
> http://www.DocToHelp.com/TechwrlList
>
> Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
> full Unicode support. Create help files, web-based help and PDF in up
> to 106 languages with Help & Manual: http://www.helpandmanual.com
>
> ---
> You are currently subscribed to TECHWR-L as doc -at- edwordsmith -dot- com -dot- 
>
> To unsubscribe send a blank email to 
> techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
> or visit http://lists.techwr-l.com/mailman/options/techwr-l/doc%40edwordsmith.com
>
>
> To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
> http://www.techwr-l.com/ for more resources and info.
>
>
>
>   

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Create HTML or Microsoft Word content and convert to Help file formats or 
printed documentation. Features include support for Windows Vista & 2007 
Microsoft Office, team authoring, plus more.
http://www.DocToHelp.com/TechwrlList

Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info.