"Known Limitations": Making the Negative Space of Help Content a Little More Explicit
After releasing documentation for a calendar application, we received so many questions and frustrated feedback from users that I started thinking about publishing a page in the help describing what the calendar doesn't do. I'm in an agile shop, so the calendar is still undergoing development, and many of the features people want are eventually coming; other features are problematic due to bugs; other features are frustrating by design. :)
I was trained to spin documentation in a positive light, so I'm accustomed to explaining what you can do with the product. You can do this, and that, and look how wonderful this thing is! You can do this, and if you want, you can do that...
Well, for every "can," there's a "can't." And it's not always clear to users whether a task they want to do falls in the can or can't bucket. Maybe you can do something with the app -- you just haven't figured out how. Maybe it is possible, if you know which menu to click, or how to access a certain dialog box, or a deeply buried menu option. Or maybe, after trying for hours and not finding it in the help, you're forced to conclude that you simply can't do it.
After expressing a need for negative documentation, Paul Scholar told me the term is "Known Limitations." I like the sound of it.
My Known Limitations page is here. It's not too long, because the length alone would send the wrong message. Also, the list doesn't cover every bug, since many bugs are still invisible to users and listing them all, or a lot more of them, would lower confidence in the app.
I initially included some limitations by design. For example, the calendar doesn't have a Day view, but I later took these out, since all the other known limitations would be fixed in a later release. So these other "crappy features by design" didn't fit.
I like this known limitations idea. When I get frustrated with an app, I want to consult the negative space of the help content. Is what I'm trying to do even possible? Rather than skimming and scanning through hundreds of topics, looking for a little note or caveat, just tell me up front the shortcomings of the product. This will save me time, and your honesty will increase my respect for you.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.