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.
Apparently lots of great minds think along the same lines!
We are beginning to establish some standards for our desktop products and my
role has become that of a facilitator. An initial set of UI standards was
created by the Product Manager for a product we will release later this
year. It's constantly being refined as we get feedback from developers, QA,
and our beta users. I'm working with this Product Manager and our Director
of Development to re-cast these guidelines in a way that allows them to be
applicable across all our products. [Enough process to get the job done,
but not so much that it stifles innovation--OK enough of that :)]
Having worked successfully on both UI design and some standards in the past,
I'm taking the base information, refining and adding to it, applying a
template the developers are familiar with, and arranging for feedback from
all Product Managers, senior developers QA and implementation. The leads
are responsible for obtaining feedback from their team members.
It's a slow process. And it doesn't finish. It can be challenging if
individual egos are far too invested in a particular style or set of
restrictions. But if you have buy-in from at least one person on product
management, implementation, and development, it can be done. The trick is
to find the balance between consistency that aids the user, and the unique
characteristics of a given application. In other words, make the
guidelines, but know when to go outside them, and be ready to adjust them as
the product, the teams, the technology, and the users evolve.
My recommendation: work with one or two key people in development, QA,
etc., to come up with a list of areas the standards will cover. Then come
up with a few basic guidelines for each of those areas. Then begin
soliciting feedback from the rest of the folks you want involved. Don't
give them a blank slate and ask them to fill it, give them a few ideas to
get them started. If you take the initiative, often the rest of the team is
relieved, and will contribute as they really feel necessary. It doesn't
always work, but it helps me keep my sanity!
From: Metzger, Lucinda [mailto:cmetzger -at- dukane -dot- com]
Sent: Friday, June 16, 2000 9:32 AM
Subject: RE: OT: Establishing standards
I've been following this thread with interest since it relates to a campaign
I'm currently waging in my own company. No standards have been set for the
GUIs that our programmers create. I do provide input as I document the
applications, but I find myself pointing out the same problems on every new
app they create. I've called a meeting with key people to discuss this issue
and come up with an action plan for implementing some standards, but I'm
dubious about how successful we'll be. How have other tech whirlers handled
this? Have any of you successfully spearheaded an effort to standardize your