Using a standard notation method for audience and tasks analysis

In the previous posts I have talked about the advantages of having a widely accepted framework for technical communication, just like ICT Architects have. This Technical Communication Framework (TECOF) could be our equivalent for TOGAF.

The similarities between Technical Writing and ICT Architecture don't stop at the overview level, we can also learn from the model-driven approach from ICT Architects towards the detail levels of a solution and its context. One of the areas where we can benefit from this approach would in my opinion be the audience and tasks analysis, at the start of a technical communication project.

A structured approach to audience and task analysis
Archimate is an 'architectural language'. It provides ICT Architects with a vendor-independent set of concepts, including a graphical representation, that helps to create a consistent, integrated model which can be used in for instance TOGAF's views.
The business layer in Archimate neatly corresponds with the Business Architecture Component in TOGAF.

In the Archimate business layer we create a model of the business context in which our to be implemented solution or change will take place. The following concepts are used:
  • Actor: organizational identity capable of actively performing behavior. Examples of actors are employees, departments, and business units. In a more complex environment customers or groups of customers (in branches) can also be seen as actors. 
  • Business role: a named specific behavior of a business actor participating in a particular context. 
  • Business function: a unit of internal behavior that groups behavior according to, for example, required skills, knowledge, resources, etc., and is performed by a single role within the organization.
  • Business process:  a unit of internal behavior or collection of causally-related units of internal behavior intended to produce a defined set of products and services.
  • Business service: the externally visible functionality, which is meaningful to the environment and is realized by business functions and business processes. 
Source: Archimate

How to use this approach as a technical communicator?
As technical communicators we are familiar with the concepts of actors, roles, functions and processes, but the thing is we never call it that way.
  • An actor is to us the audience, defined as a group of people, an organization or group of customers.
  • The role is in fact what we could describe as 'the user'; a particular type of person within the audience.
  • Processes and functions are what we would call tasks and activities.
  • The Service is for us a goal-related set of tasks and activities, used as an umbrella for our task-oriented descriptions.
We could use a simplified version of the Archimate model to document how our audience, user types and tasks and activities are related to each other.



With this simple contextual diagram we can create an overview of our audiences, user types, activities and tasks and relate these to each other. During the actual writing of the documentation, we can benefit from this knowledge. 



Create models instead of writing reports
There is no point in writing down long reports about the composition of our audiences. In my opinion the goal of doing an audience and task analysis has always been to document some context information to benefit from it as a writer. No customer or colleague would ever ask me for this document. Can we then save ourselves the trouble of documenting our audience and tasks analysis at all?

Let's put it this way: Say you have made some wrong assumptions at the start of your project, based on information provided to you by your customer. How can you ever analyse the problem and solve it if you have never recorded it properly.

Creating models of the context - audiences, roles/types, tasks and activities - makes it easier to create a quick overview of relevant aspects, without the burden of writing a report that no one ever reads. The model is the information.

In my next articles I will get into more detail on how to use models to describe the context of your information and how we can actually use these models in our documentation. If all goes well I can even add some actual examples from my day to day work at Be Informed in it.

    Comments

    Post a Comment

    Popular posts from this blog

    Using the Golden Circle Model in your resume and LinkedIn profile

    Image
    The last three years I worked as a (senior) business consultant and information architect at software company Be Informed in Apeldoorn, the Netherlands. We worked on an amazing product, a ground breaking model-driven business process platform. And my job was to explain the possibilities of this platform to various audiences. The Be Free program, which I launched in September 2013 was a marketing campaign that targeted on making a wider group of people familiar with the product. The campaign was a great success and I had the feeling that I was really helping people in proving their ideas to their customers and managers. But the interaction was on-line and from a distance, never close enough to really understand their business goals and issues.  The sudden end of my contract with Be Informed, forced me to rethink my professional goals and ambitions. What do I really want? Do I want to be a product marketer, focused on 'pushing' a product? Or do I want to be a business cons
    Read more

    Improve Product and Brand engagement through smart documentation - A White Paper about the challenge of creating user-centric documentation

    Image
    For most product manufacturers, delivering adequate documentation is a constant challenge. The increasing complexity of products and the stricter regulations for product documentation often lead to extensive documentation sets with 500+ pages manuals on-line or in print. The question is: how effective is all this documentation? Smart, user-centric documentation Users can be overwhelmed by long, jargon-loaded user manuals, and frustrated by a lack of clear answers. When customers don’t find a solution, blame inevitably falls on the product and the company. Bad documentation - incomplete, unclear, out of date - creates a negative engagement with products and brands. Figure 1. Smarter documentation asks users what they need to know Smart documentation leads users to success and satisfaction. These are the users who share their positive experience with family and friends, and convince them to become customers in turn. Using semantic technology, we can create the smart document
    Read more

    Laying the foundation for an effective article

    Image
    In this series of articles you can follow my process in writing a new article on Robotics. In the  first episode  I explained my approach towards writing, the  second article  focussed on setting the goal, choosing an audience and finding the right approach. Now that we have a clear vision on goal, audience and approach, it is time to start setting up the structure. Writing requires a structured approach Writing is all about structuring your thoughts. And although this is a process that most of us do in a more implicit way, it sometimes helps - and is actually best practice - to write down your structure on a very high level. The goal of my article is to change the opinion of the reader towards accepting Robotics as a something that brings value to a business and motivates employees, rather than being limited to reducing FTE. So the structure of my article should be build up around the motives used to build up this case. As I want my article to be short and sharp, I don't
    Read more