Category: Technical Writing

The Interplay of Information Architecture and Fictional Storytelling

As humans, we’ve been telling stories for a very long time. We’ve grown ourselves out of the various phases of human evolution because of the untapped contribution of stories in our lives. In this article, we discuss the interplay of stories and information architecture.

Insights from information architecture

Information architecture is the structure in which we produce information for consumption. It means that I must invest myself in understanding how I, as a content designer, can understand something before I help my readers put it to use. I understand this by using an analogy of online maps, for example. To reach anywhere, you input the destination, choose your mode of transport, and supply other conditions. Your route is your information architecture. Your choice of vehicle is your persona. Each persona has its set of conditions, speed of learning, and a preferred alternative (more than one route, in the case of online maps).

Let us look at what insights we can glean from information architecture and if we can apply those insights in fictional storytelling.

On perspectives

The following words are from a poem I wrote in 2021:
“Just as you have companions, my friend,
I have stories to keep me company.
The cat has only nine lives, remember?
As a writer, I realize, I’ve rather one too many.”
 

Sometimes, I am the user; sometimes, I am the project manager; sometimes, someone from the third party or vendors; I am everyone. I can assume any voice depending on the information I want to convey. I can adopt the indicative, imperative, or subjunctive mood. I can use the third-person perspective, much like Dr Watson’s voice that plays Sherlock Holmes’ mysteries in the reported speech. Or I can refer to the reader by a generic pronoun called “you”. I can sound encouraging through my words, such as “We recommend using this method for configuration”. Sometimes, I can sound cautious and be didactic, “Wear protective glasses when operating this machine”. I can also be someone who tells how the information must be accessed. Or I can be someone who tags the information for translation and use.

Each perspective has its way with words and will appeal to a specific set of readers, accordingly. I will explain things differently if you are an administrator and not a business user. As a technical writer, I can assume any role and adopt any voice to get my point across. We’ve discussed how we can make more believable characters and how we can use world-building to create contextually meaningful messages. The same thing can be applied using information architecture to create categories of contextually driven content.

On feedback

The reason feedback is often called a gift is because it lends you invaluable insights into the seeker’s brain. If a user story helps you step into the seeker’s shoes, feedback lends you an insight into their reactions and responses. Did the feature deliver what the users need? Did the users find what they were looking for? Did the users configure it correctly? Did the users accomplish what they had set out to? Will the users remember where to find the feature and its information again? Numerous such questions help draw invaluable insights. However, gathering feedback can be difficult. Therefore, to implement documentation and gather feedback, some organizations have begun using chatbots. Soon, we might use technologies like chatbots, artificial intelligence (AI), and machine learning (ML) to drive company-specific generative content, to help improve the findability of information. This translates to fewer support tickets and improved results from our cost-to-benefit equations: a better bottom line. All successful fiction authors follow the same or similar breadcrumbs from their readers. They are keen to glean such insights and implement them into their works. And much like fiction authors, we use the user’s footprints to lead us to the right design.

On clarity of thought

Of the many things that mire out my editor’s brain is the absolute thoughtlessness and absence of clarity that sometimes drips through a writer’s work. I infer, “If that’s how they write, that’s how they must think.” But sometimes, it is not the writer’s fault. It is the fault of the premise with which they begin to think. It turns out there is an order in which we must fix such issues. Begin, that is, with defining the customer’s expectations. We often get into this habit of describing our products’ features. But is not useless to tell what the product does? I can vouch that users are not bothered about the features. All they want is the underlying benefit.

In the context of fictional storytelling, this is much like the cliché, “show, don’t tell”. We must begin with the feature, yes, but we must end with the benefit. Perhaps, this is why, in the context of technical writing and information architecture, we focus on the underlying benefits. As a rule of thumb, ensure that your content doesn’t tell what the product does but what the users can do with it.

On techniques

Amongst the few techniques that help me write better are:

* Progressive disclosure: This involves spreading the message such that it unwraps itself over time. It unravels itself before dear readers such that its learning curve remains relatively flat. I prefer to use this structure when I am creating conceptual content. I lead the users to explore the concept before they delve deeper into the content. Consider this as an inverted pyramid where the tip of the pyramid­—which, in this case, is toward the bottom—denotes the most important message. The focus is on comprehension. In fictional storytelling, we use progressive disclosure for world-building and suspense revelation.

* Pyramid approach: This is easily the most used method in technical communication. I reserve it for all referential content and tasks. I share the most important information before I share the remaining content. This means the content is more usable. In fictional storytelling, we use the pyramid approach when describing an important event or narrating anything that involves a lot of action and drama. It helps create gripping content.

On copyediting

Seldom do we come across a better job than one that pays us to find other’s faults. I kind of love and hate it at the same time: On one hand, I speak of it in delight, but on the other, I abhor the idea of finding faults. However, I do like the idea of making things better. Besides, the task of editing makes me a better thinker. As the copyeditor for my team, I cannot afford to be slippery in my approach, thoughts, and words. At the same time, as a content designer, I cannot undermine the benefits of my copyeditor’s vision. The same skilled artistry that (sometimes) irritates my teammates also empowers my users. I cannot fathom not applying it in fictional storytelling, either.

Speaking of which, let us look at the insights that we can glean from fictional storytelling.

Insights from Fictional Storytelling

Fiction is imaginary literature that is written in the form of prose. It can be short stories, full-length novels, and epics that create a series of novels surrounding the life of your fictional characters. Fiction writing and storytelling both are about the art of writing stories. The difference is that writing is an art and storytelling is a skill.

Let us look at what fictional storytelling teaches us about our profession woven around writing, and if we can apply the insights in information architecture.

On characters

I cannot deny the power that our everyday conflicts have lent to our mental decision-making system. Conflicts trigger response, which triggers action; that passive sense of purpose (of resolving the conflict) is reassuring to us. It is even more useful if we can summarise our conflict in a single sentence. From start to finish, we can take our readers on a journey where they move from a mere thought to a compelling urge. We can drive their imagination to wherever our words take them—with them following us compulsively and unconditionally.

I also like to couple a character’s conflicts with their character sketches and motives. In all kinds of writing, those writers who do not characterize motives tend to lose their readers. Only when your characters can passively show why they are the way they are, your readers will understand why the characters feel or do things a certain way. Bear in mind that the readers don’t have to agree with the characters but must only understand them.


In the context of technical writing, personas are often detailed descriptions of who our users are and how they behave in a certain way. We use these personas to create content that matches the users’ requirements. Such writing has a twofold advantage. One, persona-based documentation is findable. Two, it passively empowers the readers by lending them the power to choose whether they agree with the persona. They understand the persona’s perspective and find common threads.

On choices

Writing fiction is difficult. It is a daunting task to find your way through emotions to seek the right description that matches the little bracket of word choices you and your readers are blessed with. To make the readers bleed through their eyes, you must first bleed your way through words.

You must consciously choose to rewrite repeatedly until you get to those core words that move your readers. Brevity in describing emotions is the key to this transaction. A character’s pain, for example, might make us feel that our pain is a lot lesser. In this way, writing is compassion woven into words. But this has a flip side. There is another type of people who find others’ lives as joyously painful and theirs to be painfully joyous. In another way, writing is decisive; it makes you take a stand. It must.

While I agree that there is no place for compassion in technical writing, I see the sense in which it is applied. All troubleshooting information and, sometimes, error messages are written in the same format: what happened, why it happened, and how to fix it.

On observation

We all uniquely understand reality. Each of us has a design, a pattern in which we comprehend this world. The fictionist within me is enamored by the enormous amount of detail that goes into this kind of world-building. I am fascinated by the works of writers like Charles Dickens whose novels are decorated with characters that speak who they are. For such writers, Babu from Mumbai doesn’t sound like John from England.

I want to make my characters believable, otherwise, how might you—my dear readers—will become the invisible observers of the characters’ lives? How will you believe that you are witnessing everything in real-time?

World-building does not apply to technical writing. At least not directly. But we do create documents that contain information built around the insights from world-building. We have different product and installation specifications for on-premises versus Software as a Service (SaaS) products. We have prerequisites for installation and requirements that might help our users in creating and deploying a virtual environment for testing. The more accurately we can describe the details of the environment, the more accurate the user experience is.

Conclusion

The art of information architecture is primarily restricted to setting the design right. What it lacks is often supplied by the insights gleaned from imagination. This is where the faculties of fiction and information architecture meet.

On conflicts and resolutions

To create a brilliant design, you must pare usability down to its simplest form. And, unless you understand the user’s point of view, it is difficult to know what matters to them the most. I am always curious to know what my application’s users think and want. I break those insights down into ‘manageable chunks of workload’. The input of workload contains cues to help me quantify output.

When I say, ‘manageable chunks of workload’, observe this hierarchy: User stories are divided into user scenarios, and user scenarios are divided into use cases. Each use case, therefore, has specific steps to reproduce, assess, improve, implement, and measure—in the same order. Much like with fictional storytelling, each use case, user scenario, or user story has a unique design in which the user comprehends, refers to, searches for, and builds their understanding.

On skilled storytelling

A world of masterful storytelling involves the elements of good content and good intent. It is not just how you do things, but also why you do them that impacts the people around you. Good content is “what and how” (underpinned by information architecture), whereas good intent is “why” (underpinned by fictional storytelling).

People often say that you eat first with your eyes and then your mouth. Likewise, you first listen to a story with your ears and then your heart. If the structure isn’t right, it might never reach your heart. A good design is like a delightful recipe that not only tastes good but also looks mouth-watering.

On wording

The art of writing is in meeting shifting targets. We all learn as uniquely as we explore. Yet, when it comes to reading, we all move in one direction: From the logical start to the logical finish. Yes, we sometimes skip the timeline to introduce or understand topics of interest. However, it all still points in only one direction. This “shifting target” of moving from the figurative Point A to Point B is immensely fulfilling for the human mind. It lends a sense of satisfaction. In one sense, writing is so much like life itself. We all learn life lessons before we glean the benefits. Likewise, while reading, we learn from wise words before the story fructifies.

Such is this mix-and-match of information architecture and fictional storytelling that leads us to invaluable insights into both fictional and functional worlds.

Wayfinding through Everyday Challenges at Work

“Do working hours drive you crazy too?
Often there is a lot of work to finish or even in normal days there are late eve meetings or some deadline to meet. Have you faced such a situation? If yes, what are such situations and how do you manage the work-life balance?”

Someone posted the questions on a regional WhatsApp group. I can hardly be blind to the question. And since there is so much to say, I thought of sharing it in a post here.

Yes, the prolonged work hours have now begun to show their effect, especially because I have not had the opportunity or window to go on a vacation. It has been some years since I took a leave for a few days at a stretch—and have purposely been away from work. Within this time, I’ve noticed that my capacity and productivity have gone up. However, my boiling point has considerably lowered. This means I get more angry more easily and more frequently. Even the fact that someone put up this question annoyed the hell out of me. 😀

However, with an emphasis on the word “However”, I have also noticed a few unexpected changes in me. I have become more patient with myself. I take time to understand things and I excuse myself for it. I feel tired, drained out, fatigued by the end of the day and I can barely crawl to my bed, but my quality of sleep has tremendously increased because I know that all I have to recharge myself are those five hours. I have entered into my automatic zone where I can barely feel myself doing my work-related tasks, it just comes naturally. In fact, if anything, I feel bothered and uneasy if I do not face any challenges on a given day. Each passing day reminds me of the “Hamdard’s Chinkara” advertisements that were aired when we all were young. Challenges or not, I feel I must pay either way; either with my callousness and lack of experience or with my dexterity and lack of time.

A lot of it depends on how you approach your work. AND a lot of it depends on how dependable your manager thinks you are. If they believe in “leading by example”, they can give you the authority, responsibility, and ownership of your products. It is an unsaid agreement that has mutual benefits and mutually dependent conditions. If I were an individual contributor, I’d choose to step up to match my role, expectations, and work. I’d clearly communicate how my doing my work impacts MY performance and MY life. But, if I were the team lead/manager, I’d communicate how my sharing the ownership and flexibility will help the TEAM grow. I’d share how little contributions from the team contribute to making a huge impact.

I’ve observed that unforeseen challenges, scope creep, new tools and methodologies, and more products/projects/features, all make me a better “me” every day. I am increasingly becoming efficient at compartmentalizing my thoughts and tasks, accordingly. Sometimes, I can foresee and plan for challenges and work items based on the product roadmap. Sometimes, I can accommodate last-minute challenges. Much like everyone else, I am guilty of letting my work creep into my personal schedule on a few occasions. But I can be flexible with how I approach my work. I can log off for some time for lunch. I do not have to worry about my login and logout timings. I can step out of meetings. And I can catch up with my work on Saturdays if required.

As for the work-life balance:
Set aside some time in the work schedule for:

  • Create (and stick to) a work schedule. Have definite login and logout times.
  • Ensure that you’re consistent and predictable in your work and work schedule.
  • Keep Fridays for only yourselves. Clear backlogs. Listen to recordings. Learn and share. Speaking of learning…
  • Learn something every day.
  • Listen to stakeholders. Tell them what you need. Help them with their last-minute tasks. Even a tiny help goes a long way. Remember, language is your forte and their challenge. Capitalize on it.
  • Make a list of work items for each day, each week, and each upcoming week.
  • Sort things/resources for you to use them the next day/week.

The key is to learn to communicate. Everyone feels burnout. We must voice our opinions when we feel fatigued. We must learn to say No. We must learn to listen to and consider the other side of the story. We must learn to look at the bigger picture. We must learn to listen to our hearts and follow our judgment. It is as simple as that; it is as difficult as that. Still, there always is something unaccounted for, unforeseen, or unplanned. But then, isn’t life more about the moments that take our breath away than about the ones that don’t?

I’d be curious to know your opinion. Please feel free to add to the Comments section.

What conducting interviews taught me about life

By definition, an interview is an interaction. By nature, it is an interrogation, where people question one another to explore mutual interests or growth goals. By application, I found it to be rather exhausting. Fortunately, by design, this all is purely subjective. Be it may, that is how we began searching for potential teammates. In this post, I mostly talk about what I learnt. I also rant about a few noticeable things.

The assessments and the shortlisting

It isn’t the first time I have helped my team in hiring. And, I assume, it wouldn’t be the last, either. But, unlike previously, I have encountered a few things that I had never encountered before.

In the post-COVID world, we send the questions online. And candidates are instructed to submit their answers in a couple of days. The submissions we received were based on two separate sets of written assessments (or question papers). We know that our written assessment isn’t easy. So, we selected those who showed even a little bit of promise. After all, the assessment is only an initial test, and we use it for sieving through to the candidates that might show some potential. I say ‘might’ because, in this case, we still had a lot of unanswered questions.

The interviews

We conducted several interviews over a couple of weeks. Yet, surprisingly, we did not find the candidates we were looking for.

For reference, we have a list of questions that can help create a conversation. On a ‘happy path’, candidates can expect us to crack a conversation with them, where we ask open-ended questions. When we do expect them to be exact, candidates can be specific. And we usher them to those questions appropriately.

The feedback

This one is interesting. A couple of weeks back, when we couldn’t select anyone, we chose to share the information on a (technical writer’s) regional WhatsApp group. After we shared this work opportunity, someone from within the technical writer’s community commented on the post. Here is an excerpt of it, “One feedback – Few of my friends and acquittances applied. Once single exam papers comes. I have see that too. and then one round and then poof… nothing happens. This is the 3rd time I am hearing this in the last one and half year. Has anyone from this group successfully got into from AHM (sic)? Am really curious. If no, then is playing pranks. or AHM TW are not up their standards, which i doubt. If anyone has got selected from AHM, please put here. I might be wrong in my notion.” (Please note that AHM, here, is an acronym for Ahmedabad, the location for which we were recruiting.)

Later, toward the end of the week, we received an email from one of the candidates whom we had interviewed. He had written, “I understood from today’s interview that I can’t be a potential candidate for further processes, as I haven’t don’t have relevant experience in developing technical write-ups (documentation). No problems with the decision, I respect that. However, wouldn’t it have been a better decision if this was considered before I was asked to develop content and attend a technical round? My whole purpose behind writing this email is to bring to your notice that there are some candidates like me, who do preparations before attending an interview — and the preparations take time. So my earnest request is that before you start screening a candidate, the top management should have a look at the resume before proceeding with any assessment process.”

The ranting

We took the feedback with due respect and diligence, and we will refine our hiring processes.

None of the writers had the skills we were looking for. Simple. The reverse of it, however, is equally true. Our attitude is subject to the side of the interview table we occupy. As recruiters, we take a few things for granted. But, sadly, as candidates, we assume a lot of things. The question is not if one side is more important than the other or who is right and more ‘just’ than the other. The question is whether we are ready to accommodate the other side in our own story.

If, for example, we email all those candidates whom we might have rejected in written assessments, will that not create an unwanted additional liability? Will the candidate, who raised this request, be able to justify the cost (in terms of time, effort, and money)? I agree that it makes sense to inform at least those whom we might have interviewed irrespective of their selection. I have been on the other side and it hurts when you do not receive any communication (good or bad, favourable or not). This questioning has no end. Would you not ask them why they rejected you if and when they tell?

In reply to the comments and questions, I have a few questions of my own:

  • Is the question paper (the written assessment, that is) the only round in the selection process? Even if it was, would we (as either candidates or assessors) be able to highlight all the mistakes, oversights, and shortcomings based on the written assessment itself? If only the resume or written assessment could guarantee success, we all would have hired robots for writing.
  • If we don’t select anyone based on the written assessments, people come back to us saying something similar to, “this is the 3rd time I am hearing this in the last one and half year”. If we consider them for the interview and then don’t find them fit for the role, the candidates might say, “wouldn’t it have been a better decision if this was considered before I was asked to develop content and attend a technical round?” These are two contradictory opinions. Is it wrong to give everyone a fair chance that is based entirely on their performance?
  • Did the preparation for the technical round not teach you anything? Candidates prepare for interviews, I agree. They must. They invest a lot of time and effort, I understand. How is the learning subject to the selection, then? Irrespective of the result of the selection process, did you not learn? If you have, the rejection email (or its absence) mustn’t bother you. If you haven’t, it is good that you didn’t make it.
  • If you get a better offer from another company, would you bother to give us a call or send us an email stating that you are rejecting our offer (and why)? I have seen cases when people didn’t turn up on the day of their joining. Only after they were given a call did they confirm that they joined elsewhere. Besides, what is the guarantee that you will not use an offer to bargain for another one? In such a case, do you inform the companies?
  • If all companies share their feedback on why they rejected you, what would that do to your confidence? Would you take all the feedback positively? What is the assurance that you wouldn’t bad-mouth the company or its selection process?
  • In most cases, people can learn from introspection. But did that happen here?

That’s enough ranting.

The takeaway

To begin with, the episode has taught me an invaluable lesson: hiring is tiring. The interview process seems similar to searching for alliances for an arranged marriage. Everything from behaviour to qualification to skills is taken into consideration.

Life is a race, and I don’t deny that you must run. And run fast. You must project yourself as a sprinter and a marathoner. What surprises me is that some of us don’t see the obvious. We are just too busy running after the outcome to even pay attention to the joy of running itself. Why can’t we enjoy the view as we run past our milestones of growth? This episode has taught me to not overrate success by equating it with heavier brand names, higher salaries, or longer titles. It has also taught me to not underrate or ignore my countless little successes. Each release, every new tool, and all the work items I closed in a sprint were extremely joyful moments. Every time I pumped my fist, a moment got added to my bucket of memories. I’ll say, stop running. Or, at least, learn to slow down every once in a while.

You didn’t plan to be ‘here’: you didn’t plan to be born as a technical communicator—a good majority of you, that is. You did not plan to be an employee of a certain company. You simply hope to do so. And that’s all the difference there can be. People, places, companies, designations, and salaries don’t define your success. They cannot. Life is not an outcome of only accomplishments. Life is a grand total of experiences. You don’t define your life by when you die, but by how wholesome you’re finding it to be. The episode has taught me to not bother about the destination when I can enjoy the journey.

Each company has its template for candidates. Selection or not, it still is an experience. Let us learn to acknowledge that difference. The episode has also taught me to be a bit more considerate. I purposely wish to create some room for someone else’s micro-story within my own success story. I have also realised that my success cannot define my path. But my path will define my success. And, while that’s how I choose to forge ahead, I am still looking for teammates.

Documentation Insights: My Derivation of a Design Thinking Technique

While I can never understate the importance of documentation standards, its inspiration or source is often overlooked. Today, organizations have their own sets of guidelines. So, when my manager asked me to create a set of guidelines for my team, I took to it with the utmost consideration. I realized later that the care I bestowed upon creating the standards itself underpins the very core of our everyday tasks. Thus began this little journey of experimentations and revelations.

The Problem(s) at Hand

Creating or having documentation standards isn’t the challenge; ensuring their adherence and relevance is. So, yes, we had a relatively bigger problem at hand. However, the real problems lay much deeper into the layers of our existing processes, legacy documentation, and upcoming challenges. First, we had multiple sources of truth. That is, if it was even the truth — or if it was still relevant. And, second, none of us knew how we could align our tasks with the other teams. Our team was to document the stuff just as it was ready to be pushed out of the door. So, documentation was to be found on the priority list only AFTER the other things were ready.

I am a LUMA Practitioner. It is a design-thinking approach that lends you 36 insightful human-centered design methods. My first introduction to the technique happened briefly during one of our quarterly meetups. As our instructor lead us through his story, I realized how even in this case, the problems weren’t the ones at hand but the ones buried within the layers of their processes, tools, and challenges. Back then, he and his team followed British Design Council’s Double-Diamond — another human-centered design approach. Even though this method wasn’t a part of LUMA, I could immediately see its effectiveness in helping me resolve the problem(s) I had at hand.

The Technique and the Insights

For those who might not know, Double Diamond is primarily a team-driven activity that breaks down the thought process in waves of divergence and convergence. Each of the four stages, viz., Discover, Define, Develop, and Deliver, follows a pattern where the team members are required to either diverge or converge their thoughts. The idea is to discover the root of the problems and then brainstorm to derive a solution. Discovering the core issue, therefore, requires your team to diverge. But, Defining, which is the second step, requires your team to converge their thoughts and come up with the definition of just one of those core issues.

Those who want to read more about British Design Council’s Double Diamond, click here:

https://www.designcouncil.org.uk/news-opinion/what-framework-innovation-design-councils-evolved-double-diamond

As I skimmed the Internet and continued to refine my ideas, a few things became clearer:

  • I was already past the Discover stage.
  • I, on my own, could continue to refine my ideas using this technique, even though it is a team-based activity.

I assumed that my understanding was at par — until that mental checkpoint, at least. So, now I had the right approach, intentions, and need.

The Derivation

To further align my thoughts with this approach, I revamped Double Diamond to create a version of my own. The new four stages, for me, were: Define, Design, Develop, Deliver. I categorized the first two and last two in pairs. And for each of the pairs, I came up with role-specific guidelines for both writers and editors. But before I talk about the actual guidelines, I’d want you to remember that the guidelines are specific to my team and might not necessarily apply in your case.

In the ‘Define and Design’ phase, I recommended that writers come up with the following questions for clarity:

  • What is your business proposition? Or, what problem do you solve with this product offering, tool, or solution?
  • Do you have time constraints? Or is this a project with a shifting deadline (an ongoing project), something that you might build on the go?
  • Where will we keep the content?
  • Who will remain the owner of the content?

For the same phase, the editors would ask questions like:

  • How is the product placed in the overall ecosystem? How does it interact with the other tools? Or, typically, how does the data travel from Point A to Point B?
  • How much ownership does the writing team have?
  • Who else is involved in the content finalization process?

In the ‘Development and Delivery’ phase, I recommended that writers lay stress on the relevance of content. To help writers build their understanding of the term ‘relevance,’ I broke it further into four points, each of which adds significantly to the content:

  • Critical relevance: The content should help readers survive through, or triumph over, the uncertainty, lack of information, or misinformation.
  • Contextual relevance: The content should be what the reader was looking for when they chose (yes, looking for information must be their conscious decision) to get to your content.
  • Emotional relevance: The content should help readers make decisions on their own, rather than we deciding on their behalf (unless we are recommending something).
  • Strategic relevance: The content should help them see the previous and the next steps. Or, it should help them see how what they are working on fits within the bigger picture.

For the same phase, the editors had to do relatively smaller yet more critical work. They were required to preserve originality.

The Conclusion

My version of the documentation standards is a five-pager Wiki that highlights time-critical information in a time-efficient way. It may not be perfect. Still, it does what it is supposed to do. Did we become better writers? No. But we most certainly became better readers (of the user’s thoughts, that is). We developed an empathy for the readers. We now understand their pain in a much better way. None of the stages diverge or converge, yet the phases make you think. And that’s enough for a better start. So long as we ask meaningful questions, we can hope to derive equally meaningful answers and insights.

The derived version of the Double Diamond approach aligns better with what I had on my mind. Three months down the line, I see that we can take care of a lot more work than we used to. In addition to ensuring consistency and reducing the efforts in edit iterations — which were some of the primary objectives — improving work efficiency turns out to be a bonus. I’d be curious to know if there is any such approach that you found helpful. Or if you, too, have a derivation for your reference?

My Article in CIDM Matters (October edition)

In the October edition of CIDM Matters, I talk about the top 3 things to consider when writing for internal customers or subject-matter experts. Here’s is the link to my article that recently got published in CIDM Matters, which is the electronic newsletter of the Center for Information Development Management. To know more about CIDM, click here.

My Article in STC India Chapter Indus (September edition)

In the September edition of Indus, I talk about how I broke into the field of technical communication. Here’s is the link to my article that recently got published in Indus, which is the electronic newsletter/magazine of the India Chapter of the Society for Technical Communication (STC). To know more about STC India, click here.

My Article in Writing & Beyond (September edition)

In the September edition of the Writing & Beyond, I talk about the top 3 skills for a technical writer. Here’s is the link to my article that recently got published in Writing & Beyond, which is the electronic newsletter of the Tech Writer’s Tribe. To know more, click here.

The Interview and the Strange Feedback

Last month, I attended a formal interaction for a job opportunity within my team. One of my teammates is looking for an instructional designer. Since it is a small team, they included us to review the candidate. That’s how and why the interaction happened last month.


In India — specifically in all the interviews that I have attended either as interviewee or interviewer — there are a few things that have gone unnoticed, unsaid, or but understood:

  • The interviewer asks more questions than the interviewee
  • The interview process has to cover all questions relating to the candidate’s professional life, including if and why was there a gap in their career
  • The interviewer has to have an upper hand or can interrupt


Thankfully, I have never followed any of these rules… and thankfully, organizations are evolving. Come 2021, I have rarely heard anyone facing such questions.


I am of a firm belief that first, it is an interaction and not an “interview,” and two it has to be two-way communication.

But, the recent interaction went from an interaction into an interrogation. And I am speechless.

So, here is how it went.


My first impression was that even though the candidate had over 20 years of experience, she didn’t have the positivity I was expecting her to have. So, I motivated her to talk more or elaborate right from her first answer. It might be true, after all, that the interview is over in the first 50 seconds.


Then, I asked her a few questions, which she answered promptly. And answered a few of her questions. Hopefully, I answered those questions satisfactorily.


Then I happened to ask her about the Oxford comma. I expect that a technical communicator with over 20 years of experience will have, at least, heard about it. She didn’t know what it was. To which I told her that I would have expected someone of her experience to know such things. Nevertheless, she appreciated me for pointing that out, and we moved on.


Then I picked up a few sentences from her resume and asked her to find out if and what was wrong with those. I was prepared to hear her say that the sentences were OK, which they weren’t. To which I would have said nothing.


But when she could not point out the oversight, I pointed out those to her and told her that she could correct those. Even though I realize this is an interview, I thought this helping hand would be acknowledged as a welcome gesture. Besides, I even clarified that the answers to those questions would not impact the interview result.


On a side note, let me tell you a secret. For all the interviews I have attended, I have purposely asked for the interviewers to point out the instances where I could have gone wrong or improved myself. I have always received welcoming replies. In the process, I have made friends with the interviewers… Selection or no selection, we have gone above and beyond those social boundaries to create a collaborative environment. I still talk to a lot of them, more as friends.


So, back to this interaction. I told the candidate how I committed mistakes and overcame those by asking the right questions. I also told her how I liked the interaction to be two-way, and not one-way. Within a week after the interaction, I heard from my boss — during our weekly interaction — that she found me to be aggressively authoritative and egotistic. Although we did clear the confusion between us (my boss and I), and even he felt nothing wrong with my approach, I have since learned a few hard lessons the hard way.


At least I now know one more thing. It is OK for me, as an interviewee, to ask what mistakes I committed. But, as an interviewer, I must not point out the scope for improvement, despite how objective and positive my intentions maybe because not everyone shares my state of mind.


Let me know what you think.

Relevance is the Key

It was a busy week for us. Amidst the lockdown and the pandemic, we managed to see the doctor adn got our medical certificates done. Then, over the weekend, we traveled to our hometown. I did all the planning, packing, and traveling to and from the hospital in the work breaks. This helped me manage the work, meetings, and other priorities. But the writer’s brain continued to work as usual, and thoughts continued to spin their web. So came this post.

While creating the guidelines for writers in my team, I realized how important it was to write crisp instructions. The guidelines were for reference. But most writers would go to the wiki not before, but while preparing the content. They would be more productive and busy in writing their content than digging into my referential one. Relevance was the key.

And, based on the little head pounding that I did on the subject, I zeroed-in on this:

Contextual Relevance

The profession of writing is an interesting one, for it teaches us more re-writing than writing. Staying true to the context is, therefore, second nature to us. You will not find a single sentence that doesn’t serve the purpose, the core, the topic. There could be more than one sentence to stress the importance of the point.

When creating the content, I reckon that we focus on writing about what the readers are searching for. We must write about what leads the readers to look for. We join context and content: the resolution to their problems, the remedy to their pain, the destination to their journey of searching for information.

Emotional Relevance

How empowered was the reader after going through your content? Could they make a decision? Could they press the button? Did they feel as empowered as you wanted them to? Or are they still looking for something they thought after looking at the title of your content? Ask yourself questions like these. Check your content to see the possible impact of it on the lives of the readers. One of the results of your writing the content is empowerment. Ensure that readers feel confident after going through it.

Strategic Relevance

Your content should help them see the whole picture in a logical sequence. The readers have embarked on a journey, remember? So they are entitled to see from where they have come, where they are currently, and to where they may lead. The clarity of steps is the clarity of mind, at least in the context of instructions.

Critical Relevance

Just as important as it is to know whether or not to press the button, it is equally important to see if it would solve the problem or lead to the next step. Instructional content is seldom laid on the same foundation as that of creative writing. That’s because creative writing doesn’t always have to deal with the What’s-in-it-for-me question. So the result of instructions is a definitive outcome measured in tangible or intangible results: it could be pressing that button or reaching the end of the instructions.

Conclusion

Yesterday, while talking to one of my ex-teammates and long-term friends, I shared some ideas on how they could get started with their work. I told him that one of the best ways to learn was to teach.

I just realized that the inverse of it is equally true, too. One of the best ways to teach anything is to learn to do it. And while I will continue to polish the writing and editing guidelines and add more reference-worthy points to it, I will continue to keep things relevant.

There aren’t many ways in which technical writing and creative writing differ, but for want of the outcome of actions. Relevance is critical when it comes to measuring the result. Isn’t it?

My Article in CIDM Matters (December edition)

In the December edition of CIDM Matters, I talk about empowering the seeker. Here’s is the link to my article that recently got published in Matters, which is the electronic newsletter of the Center for Information Development Management. To know more, click here.