This side up

Suyog has been a writer for as long he can remember. In his career he has enjoyed playing varied roles like marketing-communications specialist, creative writer, and technical communicator. He currently enjoys preparing documentation for a product-based software company. He loves to talk about technical communication. In his work time, he is an in-demand (Yes!) writer. In his non-work time, he is — more than anything — a busy father.

Suyog Ketkar

If the answers to "Where are we" and "Where do we reach" are the same, do we deviate from techcomm to ID? Tweet!

Listen to this article

Knowledge is like trees: We cannot see the roots, but we can see the branches, twigs, and fruits. Information, in such knowledge trees, flows from roots through fruits. But, this fructification — which ideally is measured in terms of the processing, comprehensibility, and ease in implementation of the information — depends a lot on the presentation of information. The design aspect is, therefore, at the core in resolving information problems. But, is that the only reason most of us look at Information Design as the choice for our next career assignment? Perhaps yes.

Consider these scenarios:

Whereas, we have to repeatedly refer to the table of contents when we read an old book from our bookshelf. The point is: We tend to remember pictures more accurately than words. Colours, graphics, patterns, pictures, and shapes — in short, the design elements — play an important part in the delivery of information. These elements register their impact in the presentation of information. Today, we live in the era of information abundance. And, intuitive designs can help us in our cognition through the abundant information that each of us produce and encounter every day.

From Technical Communication to Information Design

In the last couple of years, I have observed a deviation from the rather conventional technical communicators' titles and profiles. We are now exploring the limits of our strengths. This era of information abundance demands that we present the currently available information in a more compelling, effective, empathetic, and useful format. But, can a small change in our titles do all that?

Imagine seeing only text signs on a road journey. How hard and critical will it be to read (and process) all that text as you zoom past the signboards (oh, textboards)? Thankfully, the design elements can considerably reduce the time taken to process information, and yet improve our message retention. That's because they directly associate with the emotional drivers, such as fear, anxiety, pity, interest, and excitement.

The design elements are just to aid our written content. They cannot substitute the intended messages. The signs for wayfinding and the operating system and applications on our smartphones are examples of how the design elements can visually communicate the underlying messages. These design elements help create cognitive checkpoints in the overall content experience. And, that's why we may not remember the links we access, but we will most certainly remember the clip arts, icons, and pictures we click through to access the required information tidbit.

Design and its effectiveness

So, why this shift? It is because for most of us, technical communication is more about grammar, typography, or pagination rules than about the added effectivity with the use of colours, flowcharts, and infographics. Mostly, our technical-communication resources talk about the ways to improve content legibility, and not about a combination of legibility and visibility. Such a combination can get us a step closer to our users. That's because, every time we plan, research, structure, and write about our product/service, we can textually and visually present it.

The topic-based sections in the following example of a troubleshooting guide cover information from problem areas through possible solutions. The information is broadly categorised according to the nature of the problem. You can read about the nature and its underlying problem areas to know the probable causes, and their solutions and workarounds. The solutions are linked to their respective procedures, wherever required. From a technical-document perspective, the information is properly annotated and described. But, is it effective? Does it reduce the time taken to READ, understand, and resolve the users' issues?

Nature Problem area Probable cause Possible solution
Unable to upload Unable to access Access controls not set. Set access controls to default notification settings. Set default access controls. Click here for the procedure.
Upload/Integration process failed SDK version not compatible Difference in the versions of the {client tool} and {server controllers} Run Update utility to reinstall {Client} tool. Click here for the procedure.
Data-integration Failed Unable to upload data during {session}. An unresponsive {table-specific} window is running in the system tray Close the window and retry executing the {transaction}. Click here for the procedure.
Mismatched Records Incorrect number of records Rebuild {company-specific} files Purge load processes; reestablish {database links}. Click here for the procedure.
Issues in reconciliation Incorrect value records Corrupt Cache Run cleanup utility. Click here for the procedure.
Download/peer interaction failed Limited-capability licenses Need more capabilities to perform {transactions} Acquire licenses for the {modules}. Click here for the procedure.
Download/peer interaction failed {File} encountered failure {Configuration setup} for the {file} is incorrect Re-configure the {file}. Click here for the procedure.

Though the information in the above example is technically correct, the data flow may be a bit confusing to understand. For example, what are my actionable items to conclude my data-integration processes successfully? Let us represent the same table graphically:

So, what's the difference? All actionable items are filtered at level four. Also, the actionable items are interlinked from nature through stepped procedures of solutions. Even though this representation is not graphically intensive, it is easier to drill up, drill down, or drill through to the required information tidbit. And, the added effectivity reduces the time taken to locate information about the issues and resolve them. Shouldn't we ideally focus our quality parameters on how quickly and effectively our content serves the required information?

Information design is about developing an easy-to-understand, remember, and retrievable content that serves the purpose. It is about designing interactions that are natural and intuitive. This is especially effective when we are translating complex technical information, such as in the above example, into a more human-oriented, approachable language. In situations where it is important to connect to the users, information design is a lot more effective method than the conventional run-on-line textual method.

Let us split the phrase as Information and Design. What we get is not two words, but two worlds. Information mostly deals with the textual applicability and relates more to words than to graphics. So, the interface-related points are addressed only toward the end. Whereas, Design mostly deals with the visual aspect and relates more to colours, shapes, and patterns than to the text. But, these two worlds intersect at Message, which is about our intentions to align the information problems and requirements with the information delivery.

The correct design — a combination of words and visuals — lies at the intersection of the user's and creator's thoughts. It is not a substitute for the text, but that added effectivity. It is about the text and its expression in the visual aspect. The design elements make our content appear and appeal, and not just apply. Such designs can help create more rounded content experiences.

Conclusion: Same roots; same fruits

But how and why does the visual aspect appeal and apply? Information flow, if we observe closely, is not unidirectional. The forward flow is toward the users' needs. And, the backward flow starts from the users' intent. The user, and not the product or service, should be the focus. We should research to know how and why our users search for information, how do they process what they get, what do they do with it, and how better can we serve the same information tidbit. It is a cycle. And, with every revolution — at least, theoretically — we can better our information-delivery interfaces.

Think of it this way: the fruits on a knowledge tree connect with the root from information through fructification. And, each knowledge tree connects to more such knowledge trees. So, though each tree is complete in its own right, but it is also a part of a much complex garden of knowledge. Likewise, each information design flows from needs through actions, but it is also a part of a much greater, complex procedure or document.

This proves that redefining our careers as information designers may not be the end. It is not even a means to an end. For us, it all comes down to finding the answers to the following questions: how quickly can the user locate the required information, how easily can the user understand it, how correctly can the user implement the gathered information, and did the user expect the same results. We, as technical communicators, do it anyway. We may find using titles like interaction designer, information designer, information engineer, technical author, or documentation specialist amusing to use. But, do we really need to rename our career titles to answer those questions? Maybe not.


Prajakta Pradhan presents a 2-act play around refactoring a help system: Who is the user?


This side up!

Written and narrated by Suyog Ketkar.