Users’ Advocate: Structured Content and the Needs of the User

f3darchitecttools2This will be my last User’s Advocate column. I’m not leaving TechWhirl, though. I will soon be starting a series of articles on structured content. In this final User’s Advocate, I would like to build a bridge between the old column and the new articles: the role of structured content in serving the needs of the user.

Structured writing is contentious in the tech comm world. Many authors feel that structured authoring constrains them from meeting their readers’ needs. In some cases, this may be ego. Some writers may feel that they are so skillful as writers that they do not need any artificial guide or constraint to help shape their work or make it consistent. In this, writers tend to stand alone among the professions. Virtually every other profession understands the value of structure in what they do and actively seeks out tools to help them constrain and shape their work.

Programmers use frameworks and design patterns and API definitions and static analysis and programming paradigms to place constraints on what they do to ensure it consistency and quality. Craftspeople use jigs and dies and forms and templates to guide their tools and their hands. Pilots and surgeons rely on checklists, and multiple pairs of eyes, and rehearsed procedures to ensure that mistakes and omissions are avoided. Serious professional people do not rely on the perfection of their memory or the steadiness of their own hands. They structure their work to maintain quality and consistency.

Even in the arts, structure is the norm. Artists rely on color theory and perspective; musicians on meter, scales, and intervals; movie makers on the hero’s journey. True, the modern and postmodern schools in the arts have experimented with twisting or abolishing these conventions and structures, but in terms of the art, music, and film that ordinary people willingly pay their own money to view, all the successes have belonged to the works that stick to the mainstream structures and conventions. Some may claim the true purpose of art is to make people uncomfortable, but no rational person could make the same claim of technical communication.

But I suspect that in the case of technical writing, the objection to structure is more rooted in structured writing practices that were not actually designed to improve or maintain the quality of the content, but to save costs somewhere in the content process through techniques such as single sourcing or reuse.

In other cases, structured writing can involve highly analytic schemas that breaks content down into distinct types such as concept, task, and reference. And while we can all see the analytic basis of these systems, it does not follow that actual content should be written this way, anymore than the analysis of the color pallet into reds, blues, and yellows means that individual painting should be either all red, all blue, or all yellow, or even that it should always be a mosaic of a few monochromatic block types.

This is not to say that techniques such as Information Mapping have not succeeded in improving the quality of some existing content or content processes. A system does not have to be ideal, or produce ideal results, to produce improvement over a current baseline. Still, many professional writers can reasonably claim that these systems don’t solve all content problems or raise content quality to unassailable heights, or that they can do as well or better without the use of these systems. Paint by numbers may allow a novice to produce a better painting than working from scratch, but no professional, or even serious amateur is going to take the method seriously. (And no, I am no asserting the Information Mapping is painting by numbers, only that this class of techniques is often seen as such by professional writers.)

Whether driven by analytic purity or the drive for cost reduction, however, structured writing systems often end up being extremely reductive. In the name of purity or efficiency, they attempt to impose a single set of structures across an entire company, an entire industry, or an entire professions. In an attempt to accommodate many needs, such systems often become quite large and loose in their definitions, which makes them hard to learn and hard to develop for, without actually increasing their range of expressiveness. Thus writers often find themselves confused by all they have to learn and remember, while still unable to organize and express content as they think appropriate.

There is no doubt that these systems can save companies money under certain conditions, but this does not mean that they support writers in doing their best work or that they produce content that is best suited for the needs of the audience.

technical communication poll - robot wrierNor is there any doubt that the content that is produced with these systems is sometimes better than what was being produced before — though whether that is due to the imposition of the structure, or simply the tidying up that went along with imposing the structure, or whether such improvements are sustainable, is more difficult to determine. Certainly there are cases where neither economic or quality benefits were realized. Sometimes things get a whole lot worse.

The result is that opinion among technical writers can tend to polarize into a reductionist nothing-not-approved-by-the-standards-committee camp and a nothing-but-a-blank-sheet-and-my-genius camp.

The question is, does either of these attitudes serve the user?

As I have suggested above, the nothing-but-a-blank-sheet-and-my-genius approach puts far too much faith in the genius of the average tech writer, or even the exceptional tech writer. Even under ideal conditions, human beings are not consistent. We forget things, we assume things, we make mistakes. Every other profession recognizes that they need structures and checks and balances to reduce the errors and omissions that result from our individual fallibility. Writers need them too.

But does the reductionist approach to structured writing serve the user any better? The reductionist approach to structure tends to involve a reductionist understanding of user needs. Its proponents often speak as if the users need can be reduced to the delivery of a single distinct data point. The phrases “deliver the right content in the right format to the right user at the right time” or “each topic should answer one user question” may not have been coined with a reductionist intent, but they are easy to interpret that way. They tend to suggest the possibility of designing a content system that works like a information vending machine. Put in dollar and press F7 for a KitKat.

This is not to say that you cannot personalize content for the individual user, particularly in a marketing context. On Amazon, every page you view while logged on is customized for you based on everything Amazon knows about your buying and reading habits. But this customization takes place in a situation where the reader’s task is very narrowly defined (they are looking for a book to buy) and the vendor has a lot of information relevant to this task (all the other books that they have bought, and that people like them have bought in the past after searching for this keyword).

In most content applications, the reader’s task is far less narrowly defined and the information provider has far less relevant information on which to base customization. (Not to mention that extreme customization is a high wire act that can easily creep the user out or frustrate them by making it harder to fulfil a need the system does not know about — which is why some people work hard to avoid leaving a digital footprint.)

Customizing content is not a technical problem. Given a sufficiently well known and narrowly defined user need and sufficient information about the user, we have the technology and the know-how to customize content. The problem is that in most cases, the user’s need is high level, and poorly understood by the user themselves. Users do not always recognize the problem they are trying to solve, let alone how to look for a solution. Often we guess at an answer and search for a way to implement it, only to find (eventually) that we have asked the wrong question.

Information seeking, then, is not an order fulfillment process, but a kind of exploration. The reductionist view of information seeking tends to view the user as have a very clear and specific information need which is either a set of steps for doing a specified activity (task), a set of data points to be retrieved (reference) or a single idea to be explained (concept). If the order fulfillment model of information seeking was correct, this model might work fine. But for the model of information seeking as exploration, it does not work well at all.

There are, of course, cases where the order fulfilment model is correct, or close to it. When dealing with dangerous equipment or sensitive data, workers require training and certification and the docs are part of the safety and security system. People are trained to use the docs as much as to use the machines or systems. In these cases, though, structured writing is the norm. Docs must fit the structure that users are trained to use. A fully reductionist model is unlikely to apply in these cases however, as the safety system is likely to have more specific structural requirements for the content  — requirement that specifically capture and highlight the specific safety and security issues of the current system and the business environment in which it operates.

Such systems aside, however, real information seeking involves a reader with a problem to solve plunging into an information field and attempting to find their way within it. This wayfinding is not simply about locating a known piece of information (order fulfillment), it is about learning your way through the subject matter until you understand enough to form or find a solution to the problem you are tying it address (exploration and discovery). Thus wayfinding through the subject matter and wayfinding through the content are occurring iteratively and interactively throughout the reader’s journey.

Neither freeform narrative content nor reductionist structured content does a good job of supporting this wayfinding. The freeform tends to assume that the reader’s course is a direct line from the beginning of the work to the end, and the reductionist that it is a direct line to one leaf node in a tree. Neither represents or supports the way real readers move through content.

That movement is neither directly linear not directly hierarchical, but nor is it entirely random. It follows specific clues and relationships within the subject matter. Individual topics that are structured in a way that is specific to their subject matter (as a recipe is structured in a way that is specific to cooking a dish) and that are linked to each other based on the subjects they discuss, provide a highly navigable information field in which the reader’s subject and content wayfinding can take place.

In the series on structured content, I plan to discuss structure from two angles: rhetorical structure, which assists the reader in their wayfinding, and computable structure, which helps writers and information architects create content that consistently follows a sound rhetorical structure and create the forms of organization and linking that support wayfinding across the information set.

This is very much a user-centered approach to structured writing, as opposed to the primarily cost-centered approach often used today. This does not mean I will not be talking about cost-saving measures, but I will be treating them as secondary benefits in an approach aimed primarily at better meeting user needs.

Your comments, requests, and questions would be most helpful in shaping the approach of the new series.

 


Адвокат пользователя: структурированный контент и потребности пользователя | Разработка технической документации

9 years ago

[…] Источник: Users’ Advocate: Structured Content and the Needs of the User […]

Sponsored Posts




Interested in having a sponsored post on TechWhirl? Learn More >>

Subscribe to TechWhirl via Email