Re: Technical writing, usability, GUI design, and how they fit together -your opinion is needed

[Chris Morton <salt -dot- morton -at- gmail -dot- com>]

Kay provides great input (other than modeling *anything* after M$ Lookout).

I'm a former M$ beta tester dating to the days of MS-DOS 5. I was also an
early Windows adopter, dating back to version 1.0a. Through the years you
cay say that, having a good idea regarding UI flow, labeling and user
messages has pretty much become second nature. Over the years I've also
designed and coded some very small scale utilities when I perceived a need
and was inspired to do so.

Today I'm the sole techwriter at a medical devices company. All projects
emanate with the R&D staff, from which the coders bring their ideas to
fruition. Some are ESLs and all are very left-brained, so early on I saw
one of my roles as being adamant about products we ship and how they are
perceived by medical practitioners. I don't catch everything due to lack of
a formal UI review process, but given my track record I do have carte
blanche authority to (diplomatically, yet firmly) recommend changes.

There are many good UI design books on the market; why not pick one as use
it as the basis for any persuasive arguments?

> Chris

On Wed, Mar 21, 2012 at 9:02 AM, Robart, Kay <Kay -dot- Robart -at- tea -dot- state -dot- tx -dot- us>wrote:

> I have only worked at one place that had a user interface designer. Most
> of the time the developers design the interface, sometimes with internal
> customer input. Usually at my current workplace the business analysts do
> the mockups. However, in several places I have worked the technical
> writers have had a lot of input into the design of the interface.
>
> At my current position, our designs for one application are for online
> forms that are fairly standard, but although I do not design the forms,
> I have complete review authority and the authority to reword any of the
> form labels or tool tips. I gained this authority by showing the product
> manager examples of egregious spelling and grammar mistakes.
>
> In a previous job, I filed defect reports on problems in the interface,
> and I had a coworker who gained so much credibility with his product
> group that they came and asked him to help with the design. Our
> authority to do this was based upon our product group's experience that
> we knew what we were talking about, that is, we had to earn it.
>
> One of the ways I got the developers to listen to me was by asking
> questions rather than telling them what to do. For example, my first
> instance of this at the previous employment I referred to was when I was
> questioning a novice technical writer about the order of her steps in a
> procedure I was reviewing. She explained to me that with two controls,
> one above the other, you had to set the one on the bottom, which then
> controlled what you could select on the one above. (Yes, really! You
> would like to think that no one would make a mistake like that today,
> but I have seen doozies.) I took her straight to the developer and asked
> him to open up the dialog box that contained those settings. Then I
> said, "Do I really have to select this setting before I can set this
> one?" and he said, "Yes, you do. Oh! I guess I should switch them
> around!" After awhile they started coming to me and asking me for
> advice.
>
> Perhaps if you are criticizing the interface in general, it might work
> better to go to specific developers with suggestions or questions. The
> other way to go would be to locate a champion higher up in the
> organization and show him or her specific examples of your concerns. If
> the overall design looks just awful, you might try finding examples of
> existing software interfaces that would provide a better layout. You
> could probably do that by scanning the product pages for some software
> projects. If they have a model they can use for a good design, they
> might do a better job. For example, in one product group, we decided to
> use Microsoft Outlook as our model for what our product would look like.
>
> Kay R.
>
> -----Original Message-----
> From: techwr-l-bounces+kay -dot- robart=tea -dot- state -dot- tx -dot- us -at- lists -dot- techwr-l -dot- com
> [mailto:techwr-l-bounces+kay -dot- robart=tea -dot- state -dot- tx -dot- us -at- lists -dot- techwr-l -dot- com]
> On Behalf Of Robert Fekete
> Sent: Wednesday, March 21, 2012 10:20 AM
> To: techwr-l -at- lists -dot- techwr-l -dot- com
> Subject: Technical writing, usability, GUI design, and how they fit
> together -your opinion is needed
>
> Dear Wise Ones,
>
> At the company I work at - mostly a techwriter - I ran into a
> difficult situation, and would greatly appreciate your collective
> input and experience on it.
>
> Currently, GUI design is mostly left to our developers, who usually
> come up with less than usable interfaces, probably because they are
> programmers and think like programmers, ignoring the users' point of
> view. My fellow techwriter and me keep complaining about the sloppy
> interface designs and usability, but can't really get our message
> across: the interface should be designed by someone thinking as a
> user, and working closely with the techwriters to make the GUI labels
> understandable. (Correcting interface texts is important because the
> English skills of our developers leave room for improvement (mine as
> well, but that's a different problem ).)
>
> So, what is your experience?
>
> As technical writers, what is your relationship to product usability
> and GUI/interface design?
> Which group/department is involved in UI design/usability at your
> company?
> Who has the final word about the design (including GUI texts)?
> Is there a dedicated UI designer / usability expert for each product?
> How much control (language, and so on) do you (or someone else) have
> over the plans / mockups?
> At which point of the design do you review the interface, if ever?
>
> We plan to use your answers to show "how other companies are doing it".
>
> Thank you very for your help in advance.
>
> Kind Regards,
>
> Robert
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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 salt -dot- morton -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.

http://bit.ly/doc-to-help

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

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-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