Re: Product Reviews

["Lisa Wright" <liwright -at- qwest -dot- net>]

Hi Shelly,
I'd say there are any number of places to integrate interface and related documentation copy edits in the SDLC, and the best place(s) will depend on what your lifecycle looks like. I'll say right up front that we are working toward this goal ourselves and have much still to do. But maybe this'll give you some ideas.

For the software:
1. Functional spec: If your functional specs include the UI, check the text. You could have typos from the very start.
2. UI prototypes: At our company, the interface designer develops actual screens as prototypes (no sense doing the work twice) and we sign off. Part of the sign-off should be checking for typos. It helps if your interface designer understands that the interface shouldn't just be a loose interpretation of whatever s/he was given. 
3. Peer reviews: = peer pressure. Are developers held responsible for conforming to the spec? The prototypes? If not, maybe you can start to introduce the idea of quality by developing standards documents that accompany specs. We have an "interface standards" guide in progress. Developers will be responsible for following it, and it will be an automatic attachment to every func. spec. we do.
4. QA: In addition to asking the QA tester to pay attention to such things, this would be a very logical place to insert a tech writer to do a review of the screens.

For Web pages and documentation:
Get thee an editor (or rotate among existing tech writers), and simply make it a requirement that everything gets a once-over from the editor before being published or put online. You don't need to make this terribly formal unless you need extensive CYA.

As for stepping on developer toes, that is a little tricky. They may stubbornly refuse to comprehend that yes, it does matter that you use consistent terminology and user experience from screen to screen, not to mention using correct spelling; then they get all twitterpated and their fragile egos get hurt when you point out that they misspelled "Click." (Note: This reaction will also depend on whether you're dealing with adults or adolescents in adult bodies.) You could put it in business terms for them to make it less personal: "Potential customers have a negative reaction if they think we have a quality control problem." "Image and first impressions count." Blah, blah. Make it a corporate goal, everybody's affected, it'll take time but we're starting here, etc. 

Hopefully you have developers who understand quality issues--if they need a little educating about quality extending to the correct use of language then so be it.

Also, hopefully there wasn't a lot of blame going on after your demo, though I'm betting from experience that there was. If so, you'll have to do some extra work to get the developers to understand that YOU are focused on solving the problem, not on blaming anybody. Let them vent if they need to, then help them see that this new editorial review process will help everybody.

HTH,
Lisa Wright
Product Manager
PeakEffects, Inc.


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

*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com

Sponsored by Information Mapping, Inc., a professional services firm
specializing in Knowledge Management and e-content solutions. See
http://www.infomap.com or 800-463-6627 for more about our solutions.

---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot-  Visit
http://www.raycomm.com/techwhirl/ for more resources and info.