28 thoughts on “Using Tags to Increase Findability

  1. Mark Baker

    I think the most significant thing about tagging is that it represents the democratization of taxonomy. From our earliest mythology, we have recognized that the right of naming things gives power over the things themselves. Thus Adam names the beasts and gains dominion over them. Thus Rumpelstiltskin loses his power when his name is spoken. He who names, rules.

    Writers commonly try to establish control of naming. Many speak of tagging with contempt. The term “folksonomy” itself reeks of condescension.

    And yet the most common complaint about search is that it fails because people don’t search using the same terms that the writer used. (This is sometimes described as the reader using the “wrong term” — as if it is only the writer who knows the right names of things.) Tagging allows the readers, in their plurality and wisdom, to tell us what the names for the things in our content really are, and thus supply the “right” terms by which other like-minded readers will find the content.

    So yes, we should definitely allow readers to tag our content, but I think we can expect a fair amount of resistance from a writer community that does not want to give up the power of naming.

    Reply
    1. Tom Johnson

      Mark, I agree that naming is a power, and that writers tend to guard it closely. I hadn’t made the connection between Adam and the power of naming as a form of dominion, but I like that reading.

      It seems that we are forever dependent on tools to implement our ideas. Suppose I wanted to allow readers to tag help topics. Do you know of any tool that would allow such a thing? Most of the web tools mentioned in Smith’s book are custom-developed web platforms.

      Reply
      1. Mark Baker

        Well, the cure for tool dependency is to learn to make your own tools. That has never been easier, thanks to the huge array of XML based technologies, most of which is available in excellent open-source implementations. I’m not suggesting that tool building is trivial, but it is certainly a reasonable strategy for an organization with specific needs.

        But before we go there, I think we should take a step back. It would certainly be a great think if users were to tag our help systems. It would help us, and it would help other users. But I’m not sure that getting there is a simple as finding or building a tool that put a tag box on every help topic.

        Tagging, it seems to me, is a social act that is performed in a social context. You tag something to make it available to others. But does the reader see consulting help as a social act, in the way they would when they asked for help in a forum, perhaps? If not, why would they tag?

        Add to this that in the case of B2B tech writing, your customers are often competitors. I once worked for an Apple dealer and the local Apple office set up a meeting with the support people from each of the local dealers. They wanted to hold regular meetings and use them as a forum to share our support tips and solutions. There was an awkward pause, and then someone explained to the Apple guys that we were all competitors and the last thing we were going to do is share tips and solutions with each other. In their minds, we were all part of team Apple, but in reality, we belong to competing dealerships fighting that were with each other for market share. It is not a given that your users want to help each other out.

        Another consideration is that while they may be willing to help each other, they may not be so willing to help you. They might perceive tagging your help files as giving you free data.

        Rather than having the tagging be part of our own help system, it might encourage more participation (and actually be more helpful) if the tags were hosted by some separate entity, such as a social bookmarking site. (It is important to recognize that what you need is for tags to be *associated* with your content. You don’t need them to become *part* of your content, and in many ways it might be better if they did not.)

        So, while I am all in favor of user tagged help in principle, I think there are a lot of questions to be addressed before we start looking for tools.

        Reply
        1. Tom Johnson

          Re getting users to tag, good points. There’s no incentive for users to tag help topics. Users don’t have a built-in unselfishness to help other users find the same content. Delicious works because users add tags so they can find content for themselves. Those tags are just shared with others. The trick in working with the crowd is to find ways to leverage their input without asking them to do it. I haven’t figured that out yet (by a long shot), but I am brewing up a post on this topic.

          Reply
  2. Jonatan Lundin

    Tags or metadata is truly an important aspect of designing technical documentation. But the importance of metadata is based on an assumption, which we (technical communicators) all seem to agree on: Users of technical documentation are active and looking for information (that is searching) when stuck with the product. This is in most cases true, as users behave, in many cases as follows:

    Users have a primary goal which is to use the product (your product) to optimize, automate etc something. A user secondary goal is to use the product do reach the primary goal. Reading documentation is not even a third goal.

    Users possess knowledge about the product. If the existing knowledge is not sufficient or “wrong”, users get stuck and information is searched for. John Carroll and his research colleagues has empirical verified the active user behavior. And, the production and assimilation paradox is capturing the user behavior pretty well.

    When users are searching, they are expressing their information need. One of the biggest obstacles for users is that missing knowledge is difficult to formulate. Belkin, a researcher within the information behavior and especially the information retrieval field, says that users cannot easily express what they do not know or what is missing, so the expressed need is in many cases not adequately representing what is needed. That is way there may be a difference between the searchers vocabulary and the vocabulary the technical communicator is using when designing information. And that is one (1) reason to why free text search is in many cases failing.

    So, assigning multiple tags to an information resource is a way to help users find what they are looking for. I argue that we, as technical communicators, must develop taxonomy/taxonomies before we start to write. To write *something* and then start to build taxonomies and categorize topics, according to “see what kind of tags can be derived from our content” kind of approach will make you fail. I’m not talking about taxonomies used to manage content in a CMS, for example “author”, “format” “date published” etc since they are not of prime concern for a searching user. And, a taxonomy according to DITA information types, task, reference and concept does not mirror what users are looking for. Does a user know what reference information is (do you?). All these facets are in my world “user non-evaluateable”.

    SeSAM is an attempt to provide technical communicators with a design methodology to develop taxonomies, as a framework to identify what type of information to write. SeSAM is based on the assumption that a search situation, a user ends up in when stuck in product usage, can be described from several facets. The most important search situation facets are the primary goal the user is looking for when using the product, what secondary goal the user is pursuing, the operating environment the product is located in, the product interface being used etc.

    The search situation facets are the “grid” that helps you determine how many topics you need to create and the size of a topic, implicitly saying that documentation must be topic based. Also, the search situation facets taxonomies are used to build search interface(s), such as faceted search environments.

    Now, maybe your reaction is that the SeSAM search situation facet taxonomies are in some way imposing a knowledge model on the world, to which some users may not agree on. Yes, but I still argue that most users will be able to identify and understand the SeSAM facet values, allowing them to filter out all content that do not apply to a search situation, leaving only a few topics to examine further. For sure, facet values can be more or less “user evaluateable” in the context where information is consumed. One alternative search interface is a “guided faceted search environment”. Guided, meaning that the interface is asking questions to the user: “What do you want to do with the product? Is it X, Y or Z?”.

    Reply
  3. Tom Johnson

    Jonatan, thanks for your comment.

    SeSAM is based on the assumption that a search situation, a user ends up in when stuck in product usage, can be described from several facets. The most important search situation facets are the primary goal the user is looking for when using the product, what secondary goal the user is pursuing, the operating environment the product is located in, the product interface being used etc.

    I’m interested in learning more about the goal-based search facets that you mentioned. How do you establish goals for users? Aren’t these pretty much the same as tasks?

    I once tried to come up with user-based goals for an application, and then ended up being things like, Reduce Time, Increase Awareness, Increase Involvement, etc. Can you give me some examples of goal facets you’ve used for an application you’ve documented?

    Thanks for contributing to this conversation.

    Tom

    Reply
    1. Jonatan Lundin

      Hi Tom,
      Before I answer your question ”How do you establish goals for users? Aren’t these pretty much the same as tasks?” I need to make a difference between organization centric tasks and product centric tasks.

      A certain individual in a certain organization, sometimes using your product, do carry out many tasks since s/he has certain responsibilities. But it is not in the task of a technical communicator, making manuals for a technical product, to develop information on what a certain individual in a certain organization is supposed to do to fulfill certain responsibilities. This is simply because it is impossible, especially for products on a global market place. The user community is most often not homogenous, thus there are a diversity of roles, responsibilities and tasks. But, there are exceptions to the rule. When creating documentation for a (small) product, only used within one (1) known organization (maybe your own) you might know the user roles and their responsibilities. So in this case, the organization centric tasks are overlapping with the product centric tasks. I have elaborated more on this matter here: http://dita.xml.org/blog/for-whom-are-you-designing

      So a technical communicator must focus on the product centric tasks. But what is that? First of all, you might ask why a user is doing tasks in the first place. For the fun of it? The answer is that users are doing tasks to reach the secondary goals, which is to install, use, troubleshoot etc. But why is a user reaching for secondary goals? The answer is to make the product solve the primary goals. But how do we capture the primary goals of a product? According to SeSAM, you need first to identify the meaningful outcome of the product; the meaningful results the product can deliver.

      A technical product, being it an office software, industrial machine or a consumer gadget, is designed to allow the user solve a number of primary goals. The product was designed for a purpose (that’s why you buy it). A result, the outcome, when using a product is what allows the user reach the primary goal. Consider the following example.

      An industrial facility has manufacturing equipment sensitive to exposure of levels of CO2 higher than what is normal in the breathing air; meaning that the equipment will be damage if exposed to high levels of CO2 gas. A certain product, the CO2 gas detector, can detect CO2 and issue an acoustic alarm if the actual level is above a set level.

      The meaningful result here is the acoustic alarm, since it allows personnel in the facility to take action and, maybe open a window to let CO2 gas out. The primary goal, of the owner of the facility, is to protect sensitive equipment from CO2 exposure. So to be able to model the primary goals, you need to find the meaningful result your product is supporting. Then, the secondary goals are to use the product to make it deliver the result as easy, cost efficient and secure as possible. SeSAM includes eight pre-defined secondary user goals. In other words; a user is carrying out tasks to use the product to make it deliver results that solves the primary goals. There are a number of documentation projects using SeSAM at the moment, but I do not have any examples of primary goals to share yet.

      I’ve tried to explain how secondary goal tasks are derived from meaningful results for a mail software, in the autumn edition of ISTC Communicator (http://www.sesam-info.net/Communicator_2011_Autumn_SeSAM.pdf). If someone is interested, I can share the SeSAM presentation from DITA Europe 2011. I’ll put up a webinar about SeSAM shortly.

      You mention user goals such as Reduce Time, Increase Awareness, Increase Involvement. But the interesting question is: What type of result is the application delivering (when user is using the application) to allow the user reach those goals? Your user goals sound like goals for organization centric tasks.

      Finally, another issue that I would like to bring up is the discussion about findability on various blogs and social forums. A lot of technical communicators are trying to solve the mysteries of findability. To me, as a PhD student also trying to solve the mystery, it is worth noting that there are a lot of academic researches that can shade some light over the findability issue.

      According to Donald Case there are over 10 000 academic articles describing how people behave when searching for information. There are many research fields such as information behavior, information searching behavior and information seeking behavior as well as information retrieval (according to Wilson). So we know a lot about how people engage in searching as described by for example Dervin, Belkin, Kuhlthau, Ellis, Johnson, Savolainen, Spink etc. The knowledge includes how people express an information need, criteria for relevance judgment, decision making, picking an information source from the information horizon, information pathways to mention some examples of knowledge areas.

      Reply
      1. Mark Baker

        Jonatan,

        You say, “But it is not in the task of a technical communicator, making manuals for a technical product, to develop information on what a certain individual in a certain organization is supposed to do to fulfill certain responsibilities.”

        But I would submit that this is precisely the direction technical documentation is going in, and that the era of predictive documentation, where we try to anticipate user needs before any user has touched the product, is giving way to the era of reactive documentation in which we respond to specific user questions, no matter how specific or particular, and make those answers available to be searched in forums an archives.

        Many companies seem to be seeing the virtue of doing what traditionally they avoided doing — addressing specific user scenarios and problems through public forums. I think that the growing understanding of the power of content marketing is further justifying this approach, and that more and more companies may question the relative value of resources dedicated to predictive vs. reactive documentation.

        In the end, all product documentation is a sparse matrix in regard to the user needs it meets. It is an increasingly pertinent question to what extent it is best to populate that matrix based on formalisms for predicting user needs as opposed to simply addressing specific user questions as they arise.

        Reply
        1. Tom Johnson

          I agree with Mark here. It is often within the tech writer’s responsibility to specifically address tasks and scenarios by role, not just to produce general information. I am constantly making role-based quick reference guides. Sure we may not be able to cover every possible scenario, but if we don’t give instruction to specific roles and their responsibilities within the app, users probably won’t find the help content useful.

          Reply
      2. Tom Johnson

        Jonatan, thanks for elaborating on goals. I didn’t realize that you’re a PhD student. What are you studying?

        Also, thanks for the recommendation to read Donald Case. Which book or articles do you recommend? If you have a list of a few good articles or books, I’d love to know what they are.

        Also, when you wrote, “SeSAM includes eight pre-defined secondary user goals,” I wasn’t sure how there could be a set number of pre-defined goals for products across the board. Is that kind of like the idea that there are just 7 plots in fiction or something?

        Reply
        1. Jonatan Lundin

          Hi Tom,
          My research field is Innovation and design. My research will hopefully make a contribution to the information behavior (information seeking behaviors and information retrieval) and the technical communication research fields. I’ve just started last year, so there is plenty to do ;-)

          I was referring to a book “Looking for information” written by Donald Case. http://www.amazon.com/Looking-Information-Second-Research-Behavior/dp/0123694302/ref=sr_1_1?ie=UTF8&qid=1326301972&sr=8-1. He has summarized the information seeking academic research up to 2007. He references many good articles written for example by Dervin, Belkin, Kuhlthau, Ellis, Johnson, Savolainen, Spink etc. No one has suggestion an information seeking model for technical communication as far as I know (I suggested one in my master thesis).

          The idea behind the predefined user goals is based on an assumption that there are things a user must do with a product, regardless of its type. Let’s assume that a user can use the product to make it do something “X” that helps the user solve a need, problem or requirement (solve the primary goal). To get the product going, meaning to make the product do “X”, which is meaningful for the user, a user reaches for certain goals (the secondary goals). A user wants to:

          * First of all, install, deploy the product to normal operation as fast, efficient and secure as possible.
          * Use the product during normal operation to make it do/deliver “X”
          * View, check and evaluate that the product has done “X” (if “X” is not immediately visible when using product)
          * Troubleshoot and find the reason to why product has not done/delivered “X”
          * Customize how product is doing “X” to fine tune it
          * Understand what the product is trying to say when it communicates (an alarm, dialog pops up related to “X”)
          * Understand the location, purpose and role a certain interface element has (icon, switch etc) related to “X”

          These goals are predefined, meaning that they must be evaluated and changed according to the need of the targeted audience when doing an SeSAM analysis. SeSAM also pre-defines a number of sub goals in each goal category (some goals/sub goals may not be applicable to some type of products). Some users may not be aware of that they need to have a goal to use the product effectively. But reading documentation will make them aware?

          Reply
          1. Tom Johnson

            Jonatan, thanks for detailing the Donald Case book. I might just check that out. Thank you as well for elaborating more on SeSAM. I think that by and large we probably agree on many things in this thread. We just might express and explain them in ways that might seem unfamiliar. Thanks for the engaging conversation.

  4. Jonatan Lundin

    Hi Mark,
    I agree that there is a trend in our community about how users find answers to their information need. Instead of mass communication (traditional manuals) we are seeing more of a duplex communication where manufacturers try to keep their customers successful in using the product by answering questions on-line. On-line forums are definitely here to stay. BTW; I’ve heard that in China you can get a “baby sitter” to bring home when you buy certain products. The babysitter is then available to answer questions the user might have when using the product. That’s what I call reactive documentation.

    But even if the questions users have are answered on a community forum (or the manual or whatever source), my point is that there are certain questions a manufacturer cannot and shall not answer. Let’s take a step back. Human beings do have information needs every now and then. Belkin talks about an anolomous state of knowledge (ASK). Information is needed to understand, for example “How far is it to Paris”, “Do my employer give Christmas bonus this year”. The manufacturer cannot answer every possible information need; I believe both you and me can agree on that. You can put it the other way around; when do users go to a forum or the manual; what type of questions do they ask then? They don’t go to the product forum to ask how far it is to Paris.

    Let’s take an example. A process operator, responsible for operating a plant where the CO2 gas detector is used, is putting a question in an on-line forum about how to call the boss when an acoustic alarm goes off. “Shall I call, send a SMS or a mail?” s/he says. According to the company policy, the boss must be informed when an alarm sets off in the plant. Another process operator working in another plant (maybe a competitor) also using the CO2 gas detector, puts a comments on the forum, saying that his company policy says that he do not have to inform the boss when an alarm goes off. Here, shall the manufacturer of the CO2 gas detector post an answer? I argue no, because the manufacturer is not responsible for telling how its users shall live their life within their organization (organization centric tasks). Every company has their own company policy, and a manufacturer cannot or shall not interfere. There is probably a legal aspect to it; what happens if the manufacturer says that the boss does not need to be informed and the process operator neglects doing so and when an alarm goes off, the boss gets furious?

    So, I still argue that a manufacturer should not provide instructions on how to do organization centric tasks. Consider users in companies of type A or B in my blog post http://dita.xml.org/blog/for-whom-are-you-designing. The documentation for software Y provided by technical communicator Z in company X shall not describe how users in companies of type A or B shall execute their responsibilities. An individual having a role in company A or B is probably not looking in the manual for software Y to find out how they are supposed to carry out their duties within their organization.

    Even if there is a trend towards on-line public forums, I still see a need for a manufacturer to provide a “starter set” of information (before a forum gets populated). Information that tells what type of primary goals the product is solving, what the user must do to make the product deliver the results that solves the primary goal.

    I hope you are not saying that a new product launched to a market does not need some sort of accompanying information? If not, a user having an information need is forced to go to a forum and ask a question, hoping that some other user will provide the answer. But the “some other user” must have learnt about the product in the first place to be able to provide an answer. Where do this user learn about the product? Trial and error? Or are you saying that the manufacturer shall have a set of technical communicators ready to answer user questions as they arise in a forum. Like firemen that runs to the fire as soon as there is an alarm.

    You final statement I believe says that we need to find the mix between the predictive and reactive documentation “It is an increasingly pertinent question to what extent it is best to populate that matrix based on formalisms for predicting user needs as opposed to simply addressing specific user questions as they arise.”

    Reply
    1. Mark Baker

      Hi Jonatan,

      Actually, I believe it is entirely appropriate for the manufacturer to answer the question you pose, and to say that the questions is one of regulatory policy and/or company policy. It is not always clear to a user is something is a product requirement, a best practice, a matter of company policy, or a regularory matter, and it is appropriate to give them guidance to the extent that you can. Customer retention is all about customer engagement, so it makes sense to engage them whereever and whenever you can (within the bounds of prudance and affordability).

      I agree that some products need “starter set” docs. However, many do not. If you buy a socket set, for instance, it is not likely to come with starter set docs. My Nexus S and my Galaxy Tab didn’t come with any either, other than a one-pager on charging the battery.

      Whether a product needs starter documentation depends, I think, on three factors:

      1. How discoverable it is.
      2. How culturally embedded it is.
      3. How safe it is.

      Since manufacturers are always working to make products more discoverable and safer, and since the digital-generation products that most of us seem to write about are becoming more culturally embedded, I see the need for starter docs continuing to decline.

      My hunch is that the long term future of predictive tech writing lies in the fields of reference material and tools documentation, not end user products.

      Reply
    2. Tom Johnson

      I can see more of your point now. I remember documenting something that had a complicated set of business processes that existed outside of the application. Things like, Contact X person on Monday morning to submit this request, and remind him to look in his inbox and check the yellow paper not the white one, etc. I looked at this and thought, I will never understand the intricate business processes surrounding the application unless I live in this department for months. So I just documented how the application worked and let them document their own business practices for using the application. So I can see your point. However, sometimes applications have specific roles with specific tasks. If those rights and workflows are baked into the application, then I’d say it’s the tech writer’s job to incorporate instructions for the roles. But if the business processes exist outside the app and are subject to change based on the department lead, then I’d say don’t document them.

      Reply
      1. Jonatan Lundin

        Thanks Tom; you’ve summarized what I’m trying to say.

        > If those rights and workflows are baked into the application, then I’d say it’s the tech writer’s job to incorporate instructions for the roles.

        I’d say that this approach also fits very well to a product centric task perspective, if you mean, when you say “baked into the application” that the manufacturer of the software has hard coded certain workflows and rights. Or do you mean that it is the organization, buying a database application which do not have any fixed rights or workflows out-of-the-box, who sets up a workflow and defines rights?

        Reply
        1. Tom Johnson

          Sorry for the slow reply. Yes, I would say that instructions should fit the application in both scenarios you describe — both if the workflows and such are part of the application by default or by customization. The workflows I’m referring to that might not need to be documented (by tech writers) are processes and procedures that aren’t specific to the application but rather the procedures that a department manager might put down on paper for people to follow, and which may change reguarly. Someone inside such a department should probably make such a guide.

          Reply
  5. Jonatan Lundin

    Mark,
    I guess there is no harm if a manufacturer gives certain advice in an on-line forum. Advices such as pointing to best practices or regulatory practices. But such an advice is then merely a suggestion or hint: the manufacturer is then not stating that all users must do the task (to inform the boss) to use the product successfully. My opinion is that an official user manual, provided as a “starter set” should only contain product centric tasks and not organization centric tasks. A discussion in an on-line forum could very well be about organization centric tasks. Let’s take another example.

    The process operator in a certain plant is investigating how to best protect equipment sensitive to CO2. The plant owner has not yet purchased any protection (such as the CO2 gas detector). The process operator is undergoing certain tasks and responsibilities in the way to find the best solution. Should the user manual for the CO2 gas detector give instructions on how the customer should perform the investigation and how to evaluate different solutions? No, since the task is an organization centric task. Different companies do the evaluation differently due to company policies and traditions. And, the evaluation task is not a mandatory task to use the CO2 gas detector effectively. But the manufacturer could very well give some advice on how to evaluate, as an answer to a question posted by the process operator in an on-line forum.

    I can understand why users do not RTFM if technical communicators try to fill it with organization centric tasks.

    The factor that determines if an everyday thing, an artifact, a product needs documentation depends on its affordance. According to D Norman the term affordance refers to the perceived and actual properties of the thing, primarily those fundamental properties that determine just how the thing could possibly be used. Affordances provide strong clues to the operations of things. Norman states that there are over 20 000 different everyday things, we use on a daily basis, that do not need documentation. Pencils, screws, clocks, clips, scissors etc. How come? Because the design of the thing gives clues on how it should be operated. So artifacts (software, industrial devices etc) that have bad affordances must have documentation. I agree that everyday things can be designed to give clues about its use, but a complex machine…

    The user has a mental model. From the mental model we build a conceptual model about the artifact being used. The conceptual model leads us to how to use the product. We build mental models by acting in the real world, using products etc. If the conceptual model is different from the reality and the system interface is not providing any clues to how to use the product, we use the product wrongly and we need a manual. The fact that the user mental model can be different from the real world, is something SeSAM has taken into account. One secondary user goal is to understand what the product can do and how it is done. A manual must therefore include conceptual descriptions that “correct” the mental model.

    Well, every technical communicator should read D Normans books about human centered design. The one I like the most is “The design of everyday things”.

    Reply
  6. Mark Baker

    Jonatan,

    I guess I don’t view the matter in such formal terms. To me, technical documentation exists to meet the business needs of the company that produces it. Documentation is not created based on affordances, but based on whether the company perceives that producing documentation will give them a sales and revenue advantage greater than the cost of producing the docs. (And I think enculturation has more to do with it than affordances — or perhaps I am saying that enculturation is a more powerful affordance than design.)

    Similarly, whether or not product documentation deals with organization-centric tasks is one of business strategy. A tool is an encapsulation of a process, and sometimes the way you sell the tool is to sell the process that the tool encapsulates. (Most DITA vendors, for instance, are currently selling DITA adoption as much, if not more, than they are selling their particular tool. Adobe’s recent defense of FrameMaker as an XML editor is based on selling the process of WYSIWYG XML editing, as opposed to a structure-based approach.) There are companies whose whole marketing effort is centered on selling the adoption of a process, with their tool following naturally if the client accepts the process. In these cases, it can make perfect business sense for the product docs to deal with organization-centric issues.

    Should the user manual for the CO2 gas detector give instructions on how the customer should perform the investigation and how to evaluate different solutions? Yes, if the company takes a specific approach to CO2 gas detection in which the sale of the product depends on the customer adopting that approach.

    When I worked for OmniMark Technologies, I would say 90% of the marketing effort, and a good percentage of the documentation effort, was about selling OmniMark’s vision of how a content processing system should be set up. If your bought into that vision, OmniMark’s products made perfect sense, and the sale was then all but automatic. If you didn’t buy into that vision, using OmniMark’s tools could be very frustrating, which is why the docs often pointed to the operational vision, not just the working of the tool.

    Designing tech pubs is not an academic exercise, it is a business process; we don’t do things because they fit an abstract model, but because they sell soap. Of course, if an abstract model can be shown to sell more soap, then it will be useful to adopt it. But regulatory requirements aside, I think it is business pragmatism that dictates if and where and how companies document either product or organization-centric tasks.

    To attempt to bring this back to Tom’s original topic, the question of user-tagging is not going to be decided based on cognitive theory but on whether businesses actually find that it enhances their business objectives if they allow user tagging, and whether, if so, they can create a environment in which users are actually willing to add tags to content. Not that theory cannot suggest what to try, but only the market can tell us what our objective is, or if we have achieved it.

    Reply
    1. Tom Johnson

      wow, it’s great to see so much discussion here. I agree that business and customer needs trump any kind of predefined theory about what should or should not be the way things are done. There are some scenarios that merit organization-centric documentation, and other scenarios that do not. Bottom line, if the customer needs a certain type of information, that information should probably be created for the customer, without regard to whether it’s organization-centric or product-centric. If it’s organization-centric, someone within the organization may need to write it, though.

      Reply
  7. Jonatan Lundin

    Hi Mark,
    >I think it is business pragmatism that dictates if and where and how companies document either product or organization-centric tasks.

    Well, I guess the world is not black and white, so my statement that technical communicators must always, under all circumstances, avoid documenting organization centric is maybe a too harsh statement. There are of course situations where a technical communicator could provide instructions on how a certain organization should change their set of roles, and what task they do, to be more successful.

    But I firmly believe that one reason to why technical documentation has such a bad reputation, meaning that users often complain that they cannot find what they are looking for and what they are looking for is not available at all, is due to that technical communicators focus more on organization centric tasks than product centric task. Consider the task to write a manual. Where do you start as a technical communicator? First, you do an audience and task analysis, that is you map the existing users (roles?), their responsibilities and the task they must do to fulfill the responsibilities. You probably end up with a list of users that are different in regards to the responsibilities and tasks they do. Then what? You try to find patterns in the data, combine, merge so that you get a “universal” list of generalized users and what task they do. But hey, you are documenting a product, not the daily life of the users, before using the product. Where do the task you are doing with the product come into the picture. And why must a user do a task? Do you “replace” the existing task a user do with the task they must do with the new product? If the above description is not depicturing how technical communicators are doing the design work, how is it done?

    I see many technical communicators struggle with these questions. What tasks are presented in a manual and why are they included? Manuals often become a mish mash of task and conceptual information mixed in a non logical pattern. My advice, maybe somewhat controversial, is to focus more on the product centric task as opposed to the organization centric tasks. First, what primary goals does the product allow you to solve. Secondly, how is the product solving the primary goals (you are using it to get meaningful results, that solve the primary goal). Thirdly, what must user do to get the meaningful results (the tasks). The product centric task perspective does not imply or pre-define that a certain role in a certain organization must do certain tasks when using the product. It is up to the organization, purchasing the product, to decide which employee is doing which tasks; I do think that companies are clever and mature enough to take such decisions.

    To make a survey and identify users, their responsibilities and the task they must do to fulfill the responsibilities in a certain context, is vital when designing the actual product. A product is designed to help its customers be more successful; replacing repetitive tasks, optimizing a process, reducing work load or service time etc. In essence, providing a new process. So to be able to predict a desired situation, you must know the existing situation. Good product design means that all the data about the targeted users, their responsibilities and existing tasks is available to technical communicators, who can then focus on the product centric tasks. But since the data about the targeted users and their existing tasks is often not available from product design, technical communicators are trying to do the job, which leads them onto a wrong path.

    Reply
  8. Mark Baker

    Jonatan,

    I don’t think the user thinks about whether a task is organization-centric or product-centric. What they care about is the task they have to get done, which generally involves the use of the product to solve a problem in the organization. The user’s task, in other words, exists at the intersection of the product’s features with the organization’s requirements.

    To put it another way, the task domain exists at the intersection of the tool domain with the business domain. The language of the task domain, therefore, is a union of the the language of the tool domain with the language of the business domain.

    One virtue of allowing user-tagging of the help would be to give us greater insight into the vocabulary of the business domain, which we need in order to make task-oriented writing something more than just product-oriented writing expressed in the second person.

    Reply
  9. Jonatan Lundin

    Hi Mark,
    It seems like we have slightly different views on which type of task to include in a manual. But I guess that is not a problem. Maybe the difference comes from working in different business contexts, such as industrial (industrial products, industrial systems, military, aviation etc), consumer gadgets, software etc?

    My concern is that it is technical communicators that are not aware of different “types” of tasks. Users couldn’t care less. Technical communicators are often fumbling in the dark, trying to identify the task to write upon in their manuals.

    Let’s say you’re responsible for designing a user manual for a brand new product. How would you identify the tasks to write? Where would you start and go next?

    User-tagging is an interesting beast. It would be really interesting to find out how users would tag content, for sure.

    Reply
  10. Pingback: Looking at Breadcrumbs in a New Way | I'd Rather Be Writing

  11. Pingback: Tagging | Legal Index

  12. Pingback: What Does Content Re-Use Look Like in a Web CMS? | I'd Rather Be Writing

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>