December 2, 2005

Trust

Ever since LabVIEW 8.0 released, several LabVIEW developers have been making trips to present at NI Technical Symposiums about the release. It's customary for the developers to write up trip reports when they get back so those of us who stayed in Austin get the benefit of what they learned from customers.

Here's a bit from one such trip report:

I had a customer…come up to me after the…keynote…He had just bought LabVIEW 7.1 and gotten the upgrade to LabVIEW 8.0. He was having a hard time figuring out how to do event-driven programming in LabVIEW. I guess the AEs had tried to lead him to training courses. He was visibly upset that he'd spent all this money on the software, the manuals didn't teach him how to use the product, and now we were trying to extract more money out of him for training. Digging a little bit deeper, he's getting confused by various inconsistencies in terminology, and a general lack of "how-to" documentation around some of our bigger features…[Customers] feel pain when we're not able to devote sufficient time and resources to our documentation.

Now if you've seen the LabVIEW 8.0 Upgrade Notes, you know LabVIEW 8.0 is chock full of features and enhancements—it took over 75 pages just to list them all. It was certainly challenging to provide complete documentation for that many features and changes. In fact, if you look closely at the LabVIEW 8.0 Help, you'll notice a section in the Contents tab called "Miscellaneous Features and Changes," which has the following introduction:

This book contains step-by-step instructions and conceptual information about a small subset of LabVIEW 8.0 features and changes. In a future release of LabVIEW, this information will move to the Fundamentals book in the Contents tab.

So you can probably infer that we weren't able to devote the time and resources to those "miscellaneous" features that we would have preferred. That one book in the LabVIEW 8.0 Help is pretty much the only place those features were documented. For example, if you navigate in the Contents tab to the Fundamentals»Graphs and Charts»Concepts book, you won't find any mention of the new mixed signal graph in the topic titled "Types of Graphs and Charts."

We're already working on revisiting those "miscellaneous" features for a future release of LabVIEW documentation. But the question I struggle with is this: How much damage have we done to our users' trust in the LabVIEW documentation with that "Miscellaneous Features and Changes" book? If the mixed signal graph is one of the main reasons a user bought LabVIEW 8.0 and the LabVIEW Help has very little information about it, how likely is that user to refer to the LabVIEW Help again?

And when customers do feel that pain, as with the events documentation, what can we do to gain their trust again? We'll certainly record the issues reported and look into them for a future release of LabVIEW, but will that be enough?

3 comments:

  1. I definitely agree that trust is earned, and if we fail to meet a user's expectations with our documentation, we give ourselves a little more work to do to gain back their trust.

    But most relationships are not made or broken based on one event or misstep. Rather, they're built on an entire series of interactions. So even though a customer might not find enough help on a specific topic in the LabVIEW documentation, the customer's interactions with the AE's and sales people will also play a big role in how long and how deeply the customer feels pain.

    I think the LabVIEW 8.0 Help is a tremendous accomplishment and shows a good-faith effort on our part to meet all of our users' needs. That said, we'll definitely strive to bolster those areas in the documentation that currently stand in the way of our customers' successes.

    ReplyDelete
  2. I agree that this relationship is salvageable. If handled correctly, it might even strengthen the relationship.

    Your customer is in the position to make a choice. Your company is in a position to sway that choice in the company's favor. The key word here should be FOLLOWUP. Have someone contact this person. Ask if things have improved since he last spoke with someone from NI. If not, what can you do to help him? His suggestions don't just represent him (the individual), but possibly a very large group of clients that have not yet voiced their issues with it. You could include in the documentation a phone number or email address to which these kinds of questions can be directed, in case they want to know more information. The most important thing, of course, is to get the rest of the documentation together for a future release. Be sure to send that information directly to this customer (via email or fax) when it is complete. And, in a subtle way, let him know that he is the first to get it.

    These are just some suggestions. Glad you're writing again. :)

    ReplyDelete
  3. Kelly,

    If I had checked the name at the top of the post, I would have realized it was written by you and not by Ryan. My apologies. I am still not used to other people posting here. Best Regards,

    Kaylene

    ReplyDelete