It's a Training Issue!
By Deborah Gill-Hesselgrave
Deborah is an STC member in the San Diego chapter and also a member of SanDCHI, a usability group.
Some weeks
ago, I attended a UI (user interface) review meeting at a client's site.
The purpose of the meeting, as the meeting announcement declared, was
for the product stakeholders to gather together, review the product's
interface and its interaction, and to make final decisions about the software's
look and feel and its overall interactions.
This meeting was particularly notable to me for two reasons:
1. It was clearly the first time the primary, on-site user advocate (sometimes known as the Product Manager) had ever seen the product (more on that in a future article).
2. Multiple
participants, each representing different arms of the organization, remarked,
"Oh, that. That's a training issue." Or, "Hmmm… I
guess that's a training issue." Or, "It's a training issue."
Or, "Training'll take care of that." Or, … well you get
the picture.
This meeting
occurred early in my relationship with the client at a time when I was
still figuring out its political climate. It was all I could do not to
blurt out, "Ohmigawd! Don't foist this mess onto your poor training
folks!" I'm sure if I had, I would have at least been summarily removed
from the project's inner circle if not from the project completely. As
it was, my eyes rolled, my lips pursed, and my brain exploded inside of
my cranium. Thankfully none of the other participants noticed.
In keeping
with my previously published view, I think that well-designed products
should obviate the need for basic support services typically delivered
through customer support, technical documentation, and training. (Note:
I said basic support services. The business units represented by these
disciplines should still develop and provide advanced, value-adding services
to enhance a company's revenues and to better serve the client base, as
I advocated in my September 2002 article Creating
Revenue Opportunities Through Good Design.)
This article
has a happy ending-for me and for the client's end-users…
Since that meeting, my relationship with this client has formed and its managers seem to be tickled with the value I'm bringing to our engagement. Because of their confidence in me, I have taken the initiative to have a few candid, heart-to-heart chats with the Product Manager, the Chief Quality Officer, and a couple of the senior software developers.
Over the
course of these chats, I have explained my view that companies cannot
and will not prosper—certainly not in sustainable ways—when
they act on the belief that transferring problems to Training (or Docs
or Support) is a valid option for their products.
This client
did not execute a slap-dash effort with its design nor did it implement
the design poorly. It is just that its personnel, like so many in the
industry, have been trained through experience to see the support services
more as janitors who are there to clean up their occasional messes so
they don't have to, rather than as partners in generating renewable revenues
for their products.
Since that initial UI review I have participated in subsequent product reviews and not once have I heard anyone from the team suggest sending an issue to Training instead of going back and fixing it. This is one client who will definitely be successful in their market space!
