A couple of years ago, while I was still at my former employer, I thought I'd seen every problem I would ever encounter in software user assistance -- at least twice -- and had a pat solution for every one of them. As an almost 20-year veteran in software startups, with five companies under my belt, I thought I'd seen it all. And just when I was starting to feel pretty smug about my skills, I was hit with two of the biggest challenges I'd seen since learning single sourcing for a standards project at Tivoli back in the early 90s: how to provide user assistance (UA) for a new open-source product our company was sponsoring, and how to provide user assistance for our commercial product using the Agile development process after having used a waterfall process for almost five years.

These two challenges daunted me for quite a while as I tried to think of ways to provide high-quality user assistance to our customers in a timely manner. So what did I do? I hit the Internet, of course, to do some research. I found all kinds of information about open sourcing and the about Agile process as they pertain to software development, but I couldn't find much on how they changed UA development. I went to a conference for UA professionals, where many of the participants were struggling with similar challenges. But instead of trying to learn how to change UA development, most of my colleagues there were trying to figure out how to make the traditional UA process work in this new world of software development. It was pretty disappointing.

So I went back to the office, determined to find a way to develop UA in our new software development environment. Turns out the solutions for both challenges were quite similar. Instead of trying to provide comprehensive UA to all of our customers in the same time frame as the release of the software, the team decided to take a minimalist approach. Because both Agile and open source rely heavily on community and customer feedback, respectively, we decided to write a small, basic set of help files that would get users though installation and getting started with the software. Then the team would review the software for its more complex and difficult to understand features, for which we would create short desktop help videos. Then we would release the product, after which we would work with the Customer Support team to understand common problems encountered by our customers. The support engineers would keep track of how many times the same question was asked. Monitors would mine the Customer Support and community forums for hot questions. From there, we would determine the best solutions for resolving the customer issues and then determine the best way to present those solutions to the users. We would decide whether to add a question and answer to our FAQ, write up a technical brief and post it on the Support site, create an entry in the Support forum, create a short help video, or some combination of those methods.

By taking a more minimalist approach during the development phase; taking a pro-active, real-time approach to resolving common issues after implementation; and folding the results of our interaction with customers into the next release of the product, we were able to satisfy our customers' user assistance needs, while still functioning successfully in a fluid software development environment.

Rate this article ...

{mainvote}{jcomments on}