Quality and the Experience

I’m beating a dead horse here (or at least beating an old post), but I have a story to share about quality (product names removed to protect the guilty).

Recently, I had an experience where a piece of software I was using notified me that it would stop working within 24 hours because it was invalid. The software, of course, wasn’t invalid. This software, as I found out, required a handshake with a server every so often to update its "authenticity", and it hadn’t made a connection in the last week.

I had been "off of the grid" for a week working on a project that *gasp* didn’t require internet access. The product, unfortunately expected a phone home to occur at least once a week. I wasn’t planning to connect back to the grid for a few more days, so I called support and asked what to do. Their answer was to connect to the internet, or the product would stop working. I explained that while the product was critical to me getting work done, I didn’t have a way to connect at the moment. Their answer to this was "connect to the internet". I even asked a few more questions, but received the same answer every time.

Fine. I drove somewhere to find an internet connection and connected. Not only did the problem NOT go away, I was now reminded every minute (it seems) that I was running an invalid copy of the product, that I was probably a thief and that I was about to be punished.

I called support back and gave them the story. This time they paused (likely while the "tech" dug up the appropriate script), asked me to reboot, and gave me some commands to run (some policy editing scripts), then asked me to reboot again. I did all of this, and it still didn’t work. The  support person then asked me to run the same commands again and reboot. At this point, I told him to go away and ended the call. On my own, I examined the scripts, fixed a bug in them and re-ran them. My app was then recognized as working, and I was good to go (no reboot necessary).

The "experience" in this case was horrendous. I know this product well, and in every other area of functionality it is extremely sound. If asked if it was high quality, I would say yes – yet this one experience did a lot to change my perception negatively.

A big part of quality is about designing products that make the user happy. A quality product needs to be functionally sound, but it also needs to provide a quality experience – both for mainstream functionality, and for "edge cases".

In this case, if the app recognized that it was invalid, the first thing it should have done was automatically try to repair the certificate before letting me know anything was wrong. Then, instead of telling me I was a thief, it should have explained why it was having a problem. Finally, I suppose it could have given me 24 hours after I connected to the internet before self-destructing.

Comments (2)

  1. Withheld for no reason says:

    Why would one wish to withhold the name of a guilty product?  

    Does that not keep the company from suffering the natural consequences of their choices?

    Unless poor quality and bad choices cost more than high quality and good choices, people, companies, (and lab rats) will almost always choose the former.

    Those to whom the post applies seldom recognize themselves, and the rest of us are robbed of the chance to use this information in our own purchasing choices.

  2. Alan says:

    This is a fair comment and request. I chose not to mention the product name primarily because this blog is hosted on a MS site, and I didn’t want anyone to mistake my experiences or comments as MS opinions.

    I’d also rather you use the information to understand some of the pieces that go into building a quality product rather than give you the name of a product to avoid.