Welcome to TechWhirl Forums

Sign in or Register to get involved in our discussions.

Tips and Tricks: Getting from Obvious to Valuable Technical Content

TechWhirl WebsiteTechWhirl Website United StatesPosts: 396 admin
edited September 2013 via Wordpress in Technical Writing and Communications
imageTips and Tricks: Getting from Obvious to Valuable Technical Content

Users complain that they are only getting information they already know—and they’re not particularly interested in consuming this “obvious” content. Unfortunately, in the name of rapid production, much content that is written describes the obvious about features, and doesn't do justice to content that is truly valuable to those who want to consume it. Getting away from obvious content is at the heart of producing valuable technical content. Here are five tips to getting to valuable technical content.

Read the full story here


  • mbakeranalectambakeranalecta CanadaPosts: 53
    via Wordpress

    I think you hit the nail on the head with the questions you pose:

    “Why do I need to know this?” “What does this term really mean, and how does the corresponding concept impact my product use?” “Why did you use ‘4’ in this example? Is this the value I should use too? How do I decide what value I need to use?” “These results you are showing me, are they good? Why or why not?”

    What is important about these questions is that none of them are mechanical. They are all decision support questions. This is where I think tech comm has really dropped the ball on task oriented documentation. We need to understand that the part of the task that the user usually has trouble with is not the mechanics of how to press the buttons, but with the decisions they have to make in order to know what order to press the buttons in.

    Of course, providing decisions support is much more complex than telling people how to press buttons. You can't get at the decision support information by sitting in your cubicle playing with the beta software.

    But what users generally want and need is decision support content, not help on pushing buttons.
  • Jonatan LundinJonatan Lundin Posts: 4
    via Wordpress
    I find your tips to be really valuable. What you're talking about is really the ingredients of a design methodology. Technical communicators tend to focus too much on single tasks and not the reasons to why users want to do tasks. A design methodology must help technical communicators move beyond just simply listing tasks as the fundamental process when designing manuals. For the last five years or more, I've been advocating a new methodology called SeSAM to design and plan technical documentation where focus is to predict the questions users ask when using a product.

    First of all, why do companies develop technical products (hardware, software etc)? Frankly put, since they have recognized that people on certain markets have needs to solve problems, requirements or desires. Why do anyone buy and use a technical product? Because people have a need to solve problem, requirements or desires. They (users) are willing to use it since they have understood that a product can help them solve a problem, requirement or need (=a primary goal). Technical products are designed to be used to deliver an outcome that solves a need. Users use the product to make it deliver the outcome that solves the need. Users are not doing tasks without a goal in mind; no user is doing tasks just because it is fun to do them.

    At certain usage situation, users ask questions during the process of using the product to solve a problem or requirement. They end up in a search situation, which is due to the "least effort approach", active and goal oriented behavior (minimalism etc). Users want the answer quickly and without putting in a lot of effort. So what questions do users ask? And how do we get to know them before they are asked (as in a predictive, pre-release approach to documentation)?

    According to SeSAM you need to model the primary goal(s) a product is designed to solve, similar to the "root goal analysis" you are depicting. Then you must model the secondary goals the user must perform to make the product solve the primary goals. For each secondary goal(s) for each primary goal, it is possible to derive one or many sub goals, called a task situation (equal to a use case, user story or scenario). SMEs are a great help when modeling these goals.

    Task analysis (using for example hierarchical task analysis) is done to model the steps that the manufacturer recommends the user to follow to reach a sub goal. To perform each step, the user must possess procedural and conceptual knowledge. The information architect must identify the steps, meaning the procedural and conceptual knowledge, that the user community is assumed to know, which means that a lot of steps can be "removed" from the task analysis tree. Usability tests are one way of identifying what users already know or can figure out from the UI. The remaining procedural and conceptual knowledge that the user community is assumed to not know, is transformed into user questions.

    You end up with a number of questions which are classified according to the SeSAM facet taxonomies. The SeSAM facet taxonomies are populated as you analyze and identify the primary goals, secondary goals etc. To allow a user to find an answer a rich search user interface must be designed, for example as a faceted browsing environment. The SeSAM approach means that you are not organizing content in static arbitrary hierarchies (table of contents).

    As a technical communicator, you move from managing user manuals to manage user questions and their classification.
  • EnaEna Posts: 3
    via Wordpress
    Thank you for your comment.
    Yes - task-based documentation implies "task- and decision-based. I agree that this part of technical communications is not mechanical and is therefore more challenging to write. However, decision-based information is probably the most important information we can provide such that the user can extrapolate future actions.
  • EnaEna Posts: 3
    via Wordpress
    This is an interesting idea:
    "...you move from managing user manuals to manage user questions and their classification..." It reminds me a little of what the Tech Support world is trying to achieve. Except, in your case, these are questions that Content Developers anticipate users will ask (at least before the features are released) AND the questions users actually ask after getting the features. Sounds like there may be an opportunity for a tighter integration between Content Developers and Tech Support specialists.
  • Jonatan LundinJonatan Lundin Posts: 4
    via Wordpress
    Yes! To integrate tech com and support is something that I'm sure will happen more and more in future. I recently suggested to the DITA community (and TC) to integrate content management support for tech support content into DITA (see a discussion here http://tech.groups.yahoo.com/group/dita-users/message/26192).

    Technical communicators are predicting user questions (or should be doing it) since we often work in a pre-release mode. And or focus should be to design rich search user interfaces (SUI) that allow a user to find the answer quickly. So our focus should be to 1) predict questions and craft the answers and 2) design a SUI that enables a user to find an answer. To be able to predict user questions, we must understand the information-seeking behaviors of users. Something I have elaborated on here: http://dita.xml.org/blog/do-you-know-how-to-design-for-the-searching-user.

    The tools (editors/viewers etc) we use today constrain us to some degree since they do in many cases only provide a mechanism to create table of contents or indexes. We need something else. Or our users do.
Sign In or Register to comment.