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 ...
( 4 Votes )
Comments
Agile was designed as an approach to software development, not user assistance development. In a waterfall process there are tried and true ways of creating user assistance that fit within the software development process. But with agile, we have new opportunities for creating better user assistance than ever before. I believe that those of us who are working to help users with new software products have to think about helping users get access to the most accurate information in a timely manner. Going straight to the source — the developers — is the answer.
And thanks to the agile philosophy of getting feedback from customers at every stage, user assistance professionals can provide just what the customer needs and not try to second guess those needs by producing volumes of user docs.
And so, I agree with you again, when you say "… the key point is about producing the right doc at the right time." That's why I believe user assistance professionals must now learn to provide accurate and easy-to-access user assistance in and on-demand fashion.
It may mean becoming more of an editor and a project manager than just a tech writer.
Quoting Norm Gundersen: Quote
What people sometimes get confused by is that agile does indeed say not to produce endless *developer* doc.
For example, the agile manifesto says that we alue "working software over comprehensive documentation". In context, what fowler/highsmith were clearly talking about is engineering documentation. They clarify this when they say " We also want to restore a balance: We embrace modeling, but not merely to file some diagram in a dusty corporate repository. We embrace documentation, but not to waste reams of paper in never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment."
Another example: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. In a recent workshop, a software development manager questioned the feature or story approach to
iterative cycle planning. "But aren't requirements specifications and architecture documents important?" he asked. "Yes," Jim replied, "They are important, but we need to understand that customers don't care about
documents, UML diagrams or legacy integration. Customers care about whether or not you're delivering working software to them every development cycle‹some piece of business functionality that proves to them that the
evolving software application serves their business needs."
So, the key point is that agile is about producing the right doc at the right time. Just like it's about producing the right code at the right time. Quote
RSS feed for comments to this post.