This blog post lists a number of questions asked by a technical communicator about SeSAM, trends in the technical communication inudstry and problems end users are facing when using technical documentation. Below you will find my answers.

Have you applied the SeSAM principles in documenting? What were your success points and what was the downside. 

SeSAM is currently used or being evaluated in a number of projects. One of the success points is that the SeSAM design methodology and information architecture is describable, since it contains rich descriptions of its key concepts. This means that it is possible to present, discuss and get acceptance for the applied design methodology and information architecture from stakeholders outside the technical communication process, such as product and project managers and SME that does review or provides input. Since the SeSAM design methodology and information architecture includes the rules and principles on what type of information to develop and how to organize it and also guides the technical communicator in designing end user documentation, a SME can agree or disagree to it.

The traditional way of doing the design leads to difficulties for people to understand why certain type of information is placed on certain locations in a manual, since the design rules and principles are “in the head” of the information designer. My experience is that technical communicators often cannot give a decent explanation to SMEs why a certain topic is placed on a certain hierarchy level in a user manual. It is more like a feeling: “it looks nice there”. If everyone involved in the content creation process understand and accepts the rules and principles behind the design methodology and the information architecture, the risks can be mitigated of ending up in various situations where the principles, on how topics are written and how information is organized, is being questioned.

Another success point is that SeSAM is really focusing on the users, their primary goals and that documentation is designed on the assumptions that users are searching for information. The projects that are applying SeSAM are really re-thinking what type of information to provide to its end users. Technical communicators are no longer organizing information around the features or product components of a product.

On the downside, a lot of effort must be put in getting everybody to understand and accept the methodology and the information architecture. Since there are rules and principles to be followed, time is needed to get everybody onboard.

Why did you think you needed a new methodology for your documentation?

Well, simply because I could not find any existing design methodology that was rich and detailed enough. You have minimalism, user centered design, information mapping, task and topic oriented approaches etc. But none of these was helping me to the level I needed. I was responsible for documenting a product and I knew that I needed to come up with a design specification before starting to write anything. To start to write something ad-hoc was not an option. But where was I supposed to start? The existing approaches are philosophies and rough frameworks; I needed something concrete that could tell me where to start and what to do next.

I also felt that the existing approaches had the wrong starting point; to first try to map out the target audiences. As you know, in SeSAM you do not start by analyzing the target audiences. To understand the audience is of course fundamental also in SeSAM, but the focus on users comes later in a SeSAM analysis.

A technical product/system has a target group. In B2B environments the target group is certain organizations on certain markets, the end users. There are a multitude of individuals in these organizations that are at some point doing something with the product. Technical communicators often try to divide the target group into target audiences such as installators, operators, network administrators etc. The question is how do you divide the target group into finer groups (the target audiences)? My experience is that it is very difficult to come up with a list of target audiences that becomes valid for every organization since there is not homogeneity among the organizations in the target group, meaning that each organization has their own set up of roles. So you end up developing generic content that is not suitable for anyone.

What are the current problems the users are facing? Name the top 3 or 4.

In respect to technical documentation I think difficulties in finding the information they need is definitely the top 1. The issue of finding is a problem on many levels. First a user needs to find the information source judged to be relevant. An information source can be a manual, a forum on the internet or a colleague. If the user selects an information source containing a lot of answers, such as a manual, they also need to find the answer within the manual. To be able to find the answer they must know what to ask. From research within information science we know that individuals have problems in expressing their information need. Think about the user who has problems in using the photo copier machine. The user says “the paper is stuck in the what-ever-it-is-called-thing in the machine”. You cannot search for "what-ever-it-is-called-thing in the machine".

Another problem for users is to judge whether a found answer is actually the relevant one. Yet, another problem I see is that there can be a mismatch between the instruction and the state the product is in. If the user has changed some setting in the product that was not taken into consideration by the technical communicator writing the instruction, the result of following a particular instruction may not be the result the user wanted. What I mean is that the instructions often imply that the product is in a certain state and if the product is not in that state, it may behave in a different way than assumed in the instruction which makes the user confused.

What do you think are the solutions to address these problems? What are your recommendations?

First of all we (technical communicators) must understand the information behaviours of users. Many users are active and goal oriented. They often start out by using the product based on what they know. If what they know is not in accordance with how the product was designed, the user may end up in an error situation. Users need information and they ask questions. Users start to search for information. That is why technical communicators must understand information seeking and searching behaviors and know what questions end users ask. Better up, as a technical communicator you must be able to predict user questions since you often work alongside product development. SeSAM is actually a methodology to predict user questions.

So instead of managing user manuals, you should manage user questions. Let’s say your department is managing 50 user manuals today. Tomorrow you are managing 1500 user questions. The notion of a manual becomes irrelevant. User do not want to spend time on searching, thus an answer must be findable. They do not care about manuals, they want an answer. So you need to not only focus on predicting users questions, you must also make the answers findable. That is why SeSAM includes a methodology to design search interfaces. Finally, I think topic based documentation is the future since it is very suitable for the question-answering approach to documentation. A DITA topic shall answer one (1) user question.

What are the latest trends and which way do you think this type of documentation is heading in coming years?

The internet and social media collaboration has changed it all. Now users are helping other users. The internet is actually documenting certain products (like consumer gadgets). Technical communicators must acknowledge and understand how this paradigm shift affects their business and way of working. Users have a multitude of channels to find the answer. Also, the amount of information is ever increasing and the time users have to spend on searching is ever decreasing. That is why focus on findability will be the top issue in the future.

Technical communicator can no longer deliver PDF, on-line helps etc including a big static table of content. We need to think about rich search interfaces such as faceted browsing, where taxonomies and topic classification plays an important role. A search interface must be built to accommodate small displays used for example in smart devices. In future, many users will use a mobile smart device to find information about product usage. There are tools out there to build faceted search environments based on taxonomies for technical documentation. But the trick is to know what taxonomies to use and how to develop them. This is where SeSAM comes into play.

And also, technical communication processes needs to be built around the searching user. Thus technical communicators are interacting with the user and answering questions, not writing user manuals. This means that technical communication departments can merge the content creation process with support/help desk departments, since they are also answering questions. Both the technical communication and support/help desk processes can use DITA to manage the information, since each topic shall answer a user question. In fact, the whole company should integrate how user questions are answered. It is all about bridging the silos.