TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Re: Technical writing, usability, GUI design, and how they fit together - your opinion is needed
Subject:Re: Technical writing, usability, GUI design, and how they fit together - your opinion is needed From:Robert Fekete <fekete77 -dot- robert -at- gmail -dot- com> To:"techwr-l -at- lists -dot- techwr-l -dot- com" <techwr-l -at- lists -dot- techwr-l -dot- com> Date:Sat, 24 Mar 2012 09:07:26 +0100
Thank you for everyone for your time and for sharing your experiences.
It was really helpful - and also hilariously funny at times - and
hopefully we will be able to influence the management to allow us to
help more to the developers.
Have a great weekend!
Robert
On Thu, Mar 22, 2012 at 2:21 PM, Chris Despopoulos
<despopoulos_chriss -at- yahoo -dot- com> wrote:
> I have a bottom line... If you can't document it clearly, it needs to be redesigned. Period, full stop.
>
> That doesn't always apply, but it often does. When it doesn't, the problem is usually related to schedules, history, and other realities that you MUST take into account if you are to maintain credibility. But you still register the issue so it can be addressed next time. Remember, your job here is to ADD VALUE, not cause problems.
>
> In my last three full-time positions, I have interacted with product teams. These teams had one-three people who defined the product. Participation in GUI issues generally began with them, and ultimately turned into direct collaboration with the developers as they designed their features. In the not-so-long run, the teams learned that it was quicker and more efficient to just talk to the pubs people before committing the code. The amount of time it takes to get to this stage varies... In some positions it was part of the job description, in others it was a matter of winning credibility over time.
>
> I have never worked with a dedicated UI designer. I think there's an urban legend in there somewhere...
>
> I generally have final say over wording in the GUI. That's because part of my job is to maintain the terminology for the product, and the GUI has to fit into the overall scheme (or vis versa???) I do not have final say over work flows and overall GUI design. But I do have a seat in the meetings, and if I see something I'm free to raise the question. Sometimes the question is valid. Again, it's about adding value... If the value is apparent, no problem.
>
> I have zero control over plans and mockups. Actually, with the exception of base terminology, I have zero control. Control is given to the IDEA, no matter who voices it. I try to have access to plans as early as possible, just to serve in a consulting role. The more credibility I have, the earlier I get invited in. This is an ongoing process, sometimes referred to as a relationship. It's what we do for a living.
>
> All that said, I know a writer who is in a constant fight over GUI issues. The product GUI, for historical reasons, is downright irrational, and nobody is willing to work together to bring it in line. This writer does what can be done to unify terminology and work flows, but it's hard going. Again, after YEARS of building relationships the writer has gained credibility, and actually makes some progress. But more often than not, the writing has to violate the cardinal rule (see above), and prolix documentation is required as a band-aid to even worse work flows. Some people are unlucky, I guess.
>
> cud
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
>
> Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
>
>http://bit.ly/doc-to-help
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> You are currently subscribed to TECHWR-L as fekete77 -dot- robert -at- gmail -dot- com -dot-
>
> To unsubscribe send a blank email to
> techwr-l-leave -at- lists -dot- techwr-l -dot- com
>
>
> Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit
>http://www.techwhirl.com/email-discussion-groups/ for more resources and info.
>
> Looking for articles on Technical Communications? ÂHead over to our online magazine at http://techwhirl.com
>
> Looking for the archived Techwr-l email discussions? ÂSearch our public email archives @ http://techwr-l.com/archives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create and publish documentation through multiple channels with Doc-To-Help. Choose your authoring formats and get any output you may need.
Try Doc-To-Help, now with MS SharePoint integration, free for 30-days.
