In the technical writing world in general, and at IBM in particular, writers are becoming more involved in the software design and development process. We're beginning to embed product help directly into the product UI. Our goal is to eliminate the need for our clients to interrupt their work and go looking for help. No longer will separate, independent documentation be the only content that we deliver. The techniques that we use are Progressive Disclosure and Embedded Assistance.
IBM's own Andrea Ames presented these techniques to the Society for Technical Communication summit in May 2012. A blog post by Sarah Maddox (http://ffeathers.wordpress.com/2012/05/23/stc-summit-day-2-progressive-disclosure/) gives an overview of what Andrea said. I'm not going to give a summary of the summary; you can read Sarah's post yourself. But what I will do is give a quick example of what embedded assistance is and how it can make using software easier by delivering information when you need it and where you need it.
For example, in SmartCloud for Social Business, when you start a Community you must choose one of the access options. The options are Restricted, Moderated, and Open. In the old way of doing things, the options would be simply listed. But what do these mean? How do you choose? In the old way, you would have to first find the documentation, and then find the section in the documentation that contained the information. And that's if you even bothered to look; most of us would probably pick the best-looking option, cross our fingers, and hope for the best.
The new way is to add text to the option so that now you can quickly decide the type of access that you want for your Community. The options, as shown in the graphic below, are Restricted (people must be invited to join), Moderated (anyone in my organization can see content but must request to join), and Open (anyone in my organization can join).
Help should be easy to use, easy to understand, and easy to find, and there's nothing easier to find than text right there on the screen.
And although we've made a good start at this, we still have a ways to go. For one thing, it's a whole new way of working. Writers must work with the UX people to make sure that our content has a place, and also work with the developers to get the changes implemented. And like any new way of doing things, the transition is not without its challenges. People who are accustomed to working alone are now working together. Where before we only had to confer with colleagues who were familiar with our own domain (because writers spoke with other writers, designers with other designers, and developers with other developers), we now have to speak to each other. And lets face it, designers and developers are just plain weird. They would no doubt say the same about writers.
But on the other hand, we all learn new things, and because of this our jobs are far from tedious. We also learn the problems and issues and stumbling blocks that our counterparts face in their day-to-day work. And there's a thread that binds us; we all have ambitious plans and tight schedules, and we all feel a little down when the schedule is just a little too tight or the plan just a little too ambitious, forcing us to let something go until the next release.
Overall though, for me this is a welcome change in my job description. Not only do I get a chance to influence the design of a product and the way that a product works, but I also get to think more and write less. And I like thinking!