Lessons on Branding and Growth

Day 9 and 10 Lessons Combined

---

I’ve begun to earn what I longed, yearned for: my share of the sky in this world. It is just that I spell it as S-U-C-C-E-S-S. For me, success is subject to only a few things, two of which form the core learning from the day 9 and 10 lessons, respectively: engagement and persistence.

It does require a handsome share of mind to come up with new topics to write about and share with all of you. Like I mentioned, I know that your time is priceless, and if I were to wish you to spend it on my posts, I better make the posts worthy of it. But before I talk about the two key elements, I must share with you what I changed on this site.

The idea behind taking this ten-day free course on WordPress was to see which squares did I miss while tiling this site. The efforts were good so far, but now that the site has grown vertically and horizontally, I must make it possible for you to swim effortlessly through the content and sieve out what’s not required.

The site pages are now less intrusive to traverse, searchable, annotated – a few posts that were tucked under pages and menus are now available on the site’s timeline – and easier to read. I’ve experimented with the fonts, colors, and page layout. I’ve also tried to make the posts look more manmade. And, I’ve got the creative juices flowing: a lot of poems and other creative stuff.

With that background, let me bring you back to the two key lessons: engagement and persistence.

There are two things that, for me, colocate with engagement. The first one is purpose. And the second one is commitment. My posts are there for a purpose: one common thought, which through the course of the post, you will share with me. And I am committed to bringing to you only the choicest, original content. Even when I publish a commentary on other’s posts, the thoughts are as original as the ink.

Similar to engagement, there are two things that colocate with persistence, too. The first is flow. And the second one is regularity. Those of you who’ve journeyed with me through this course of posts will agree that there exists a uniform flow of thoughts. And that the thoughts have continued to flow through to you quite frequently in the last five years.

There still are a few things that I will like to experiment with. For example, guest posts and SEO. For now, I am happy with the little share of the sky I’ve got.

Advertisement

Lessons on Branding and Growth

Day 2, Lesson 2

---

I know it is technically day three, but the tasks of day two took time. And, I must say that though on paper I might not have moved a mile, I have covered a long distance to see the blog from the visitor’s eyes.

I’m told that I must look into the finer elements, such as the theme, fonts, and widgets. As a technical communicator, I do look into these things even in my daily work chores. So, I am beginning to see and hold the common threads.

Last week, I tweaked a few things on my site. I can see from the response so far that the changes have paid well — no, not in monetary terms. I can see a positive response, already, because people are beginning to scroll through pages and read even those posts that previously remained untouched. The site is now more searchable, navigable, and simple. But, not all bells and whistles, so to say, are gone.

Like they mentioned, I cannot cover everything in one day. I agree. No one can become a master in one day. Not even masters became who they are, overnight. So, I am determined to refine the content and appearance of the site. And, I look forward to a welcoming response from all of you.

Happy writing.

The Question of Approach: One vs Many

Last week, for our internal communicator’s club meeting, I presented some Tips for Effective Writing. Those who attended the session were mostly developers. And, that’s why it was even more useful for them. To help understand the core need for communication, we used a picture quiz, which you and I will discuss through this post.

Look at the following pictures (courtesy: Internet). The first picture is of Lotus Temple, New Delhi, and not of Sydney’s Opera House. The other picture is a multi-utility tool, also called Swiss knife. Here’s a question for you:

How do you think the two pictures contrast?

Before you begin answering the question, here’s a little built up for it:

As a seeker of information, I am like every other “user” or “audience” – I am like YOU, dear reader. I prefer to take the shortest or quickest path to the resolution. Much like you, I get petrified when I can’t find the shortest route. Much like you, I get petrified when I see unorganized or insufficient information. It’s as simple as that. This puts a lot of responsibility on the shoulders of technical communicators and user experience (UX) designers. Sadly, there is still no guarantee that we, the information seekers, would access the right information tidbit at the right time; or even if we do, we get to use it correctly. This means, despite all efforts by technical communicators and UX designers, the communication remains incomplete if the seekers can’t get to – or comprehend – the right information or the right tool at the right time.

Given that background, look at the first picture.

 

The Lotus Temple, New Delhi

 

Here is the message from the technical communicator within me to the information seeker within me: those who seek answers to oneness and peace, go to Lotus Temple. Don’t drift: the name is indicative. So you can take any temple, mosque, church, or even faith. Seekers like you might have a lot of questions, but each of those questions will lead to only one answer: of realizing the seeker’s true self. So, there may be numerous problems that might lead to just one solution. This resembles the Sanskrit hymn, Ekam sat vipra bahudha vadanti, which largely translates to “That which exists is One. Brahmin (Sages) call it by various names.” Rather than seeking the solution, seek for what you wish to solve – the need. That’s how even I have organized the content for you.

Look at the second picture.

 

Multi-utility tool

 

Here is the message from the technical communicator within me to the information seeker within me: those who wish to complete a task or resolve their issues will seek such a tool. A tool, which has one unique solution for every problem. A tool, which can do a lot, but only dedicatedly. Seek, if you must, the need. The tool is still only a medium to accomplish; it’s a means to achieve, not the end.

But before talking about contrast, let us take a minute to discuss a little about what’s common for both the pictures. The only common thing is the need. The need to discover, resolve, and accomplish; the need to get things done; and the need to get questions answered.

So, here’s the contrast: the contrast is in having one universal solution versus a unique solution for every problem. The contrast is also in stressing the presence of the right information tidbit and of the right tool both at the same time. For the seeker’s shortest route to the resolution is the one that contains a quick and unique solution to their problems; the one that addresses the need.

What’s the lesson for the seekers and technical communicators?

The rules of grammar stand true and remain unchanged. However, there still are different ways in which we can compose, express the same information. Similarly, even though there are style guides and standards, there are hundreds of scenarios that we can count as exceptions. Probably, that’s why we see the Microsoft’s Manual of Style, fourth edition, mention “Microsoft” and “Not Microsoft” ways of creating content, unlike the “correct” and “incorrect” ways in their third edition of the book.

We should choose based on what’s needed, required from the content. There lies harmony where both technical communicators’ and information seekers’ needs meet.

Are Technical Writing and Instructional Designing the Same?

This post originates from a couple of related question that I answered on Quora, which you can find here and here. For those who are rushing, here is the gist of the post: Although I don’t regard technical writing and instructional designing different, I do acknowledge that the tools and methodologies both use are quite different.

For the elaborate explanation, I resort to breaking the big question in parts:

How are technical writing and instructional designing different?

Howsoever thin, there is a line that separates technical writing and instructional designing. Yes, I agree that though the end-result is still similar, the routes taken are different. And, here is the first difference. Technical writers focus more on collecting, collating, and presenting information, while instructional designers focus on streamlining the correlated tasks into stepped instructions and courses. Another difference I see is in the approach. I always say that technical writers are backstage players. No one knows they are there, but they are. And, unlike instructional designers, technical writers can never become the front-stage players.

As a technical writer, I deal with creating and maintaining user guides, help files, and release notes, but if the time and scope permits I also get to write white papers, knowledge base articles, full-scope or abridged customer-driven metadata, and blogs. The goal, however, across all cases of documentation and complexities is empowerment. Instructional designing deals with information that’s both specific and generic. It does include offline or online learning, self-paced or instructor-led learning, and activity-based learning from simulation or gamification. The goal, however, across all cases and complexities is still on learning. But then my exploration limits my knowledge.

The thin line that differentiates technical writing and instructional designing becomes thinner at the object level. For example, when you create a knowledge base write-up, you focus both on empowerment and learning. You wish that when a user reads through your document, they will know what next to do and why. I can also see some rules that apply to both technical writing and instructional designing.

In today’s mobility-friendly world, people want everything on the go, including information. And, depending on what you seek or what you have (a smartphone, tablet, watch, or eyewear), the information complexity, language, and medium changes. This means that both information and instructions must be easy to understand and easy to use. In one way, this means fewer words and more visual content. But, we’ll discuss this some other time. Let us look at the second part of the big question.

Do technical writing and instructional designing require different skills and tools?

Quite rightly, the thin line of difference in the professions extends into the skill set and tool set as well. While it is true that both the skills and tools mostly are common, the percentage of a skill’s or tool’s relevance certainly changes based on the profession. I feel that technical writing involves more researching than instructional design. But, like I said, my exploration limits my knowledge. Instructional design involves more of storyboarding. So, it is good to assume that it will also involve more of action-driven, task-based sentences.

Both involve writing instructions, but technical writing restricts such instructions to stepped procedures in user guides and troubleshooting guides, while the entire storyboarding in instructional designing is task-based and action driven. Instructional designing is more of learning management. Consequently, you should have a better understanding of what users do with your products.

Let us take a small example. Consider that you have a job at a place where even a small error might result in huge losses for the company. Now, we will agree that the software or hardware products that you will get to use in such places will come with manuals. But, will it still not make sense for you to undergo a formal training before you get involved in your daily duties? I hope you can now see the difference. You limit your information goals based on your work processes and sequences of actions; on how a tool is designed to work and how it may fail; and, one how you wish to keep yourself and your peers safe and the work processes smooth.

In the context of the differences in technical writing and instructional designing, given the information goals you seek, it would be right to consider instructor-led training first followed by a regular check into the user guides wherever required. That should lend you insights into the only possible difference in the professions. Let us now address the last part of the big question.

As a technical writer, can I switch profession into instructional designing?

Either way, switching shouldn’t sound challenging; it wouldn’t be easy, for sure. But decide what you wish to do or help the users in accomplishing.

Conclusion

Before I conclude, let me take a moment to help you look at how I’ve understood this indifference. First I determine what the user wishes to accomplish. Then, I determine how they wish to accomplish their learning objective. Then, I look for the resources I could use to help them accomplish their learning objectives. Then, I break that learning objective into logical, sequential parts. Now, I see if I could create content that ushers them through those logical, sequential parts. The point is that I register the impact of each of those logical, sequential parts. I register the growth of user’s learning as they move from one goal to another and, eventually, one objective to another.

You see that the already thin line of difference between technical writing and instructional design further begins to blur.

Let’s just introduce a new word into our discussion: training. The word adds a lot of clarity in our understanding and helps us define the scope of both technical writing and instructional designing. Based on what we’ve discussed so far, can we say we are talking about technical training instead of instructional designing? If yes, can we say that technical training helps graduate a user’s understanding from one logical sequence to another or from one learning goal to another? And if that’s also true, aren’t we negating the difference between technical writing and instructional designing?

This is exactly why I don’t regard technical writing and instructional designing different. They may be two sides of the same coin, and I am OK if they are that way. But, that still doesn’t change the end-result for the users. Despite what users wish to peruse, they seek insights and accomplishment. And, as someone who enables them to achieve both these, I continue to remain a problem solver for the users. And, I don’t care what you name me as.

Which is the best and the most reliable technical content writing software for any technical content writer?

I’d say that it depends on your organization’s standard processes, requirements, budget, delivery formats, and time at hand. I’d choose based on those points. The current trend is shifting from the conventional PDFs through videos, tutorials, and interactive help. But, based on my previous stints, here is the list of usually-used tools I’d say useful to you:

• If you rely on instructional videos for your organization, you can use TechSmith Camtasia to create instructional tutorials, provide voice over, run parallel tracks for superimposing two faded screenshots, and provide animation and special effects, too. The other similar tool, which I find was equally easy to learn was Adobe Captivate.
• If you are heavy on video reviews instead of instructional videos, you can look at other movie making videos like Adobe After Effects.
• For those who still use the conventional PDFs, there is a plethora of choice available.
• If you use single-sourcing and are keen on creating content that is reusable, I would suggest tools like Adobe RoboHelp (the latest version is just fantastic because you now can create Apps, too) and Help & Manual (this is perhaps the most underrated tool, believe me).
• If you are following the DITA XML methods of structured writing, I’d suggest use Adobe FrameMaker. You could also use MadCap Flare
• If you plan to create an online, Server-based, CMS-oriented repository of your work, I’d suggest you use Atlassian Confluence. First, there are a lot of plug-in applications that you can add to it. Second, this is a centrally-managed-and-organized tool. So, this means greater control on who is working on what. Another advantage is that you get periodic updates that get pushed into your system automatically. Just that some of my friends tell me that it is a little expensive to implement. But, since I haven’t used it, I wouldn’t choose to comment on it.

But, there is a lot more to deciding on a technical writing tool that just that. You have to decide on what software will you use in order to implement version controlling. Version controlling will help you create and post versions on a Server so that neither your data is lost nor there is more than one technical communicator working on the same thing. A software, such as Bitbucket (previously called Stash), SVN, and VSS can help you do that.

You should look into a bug (a.k.a issues) management tools like the JIRA. This is a complete tool for creating and managing items that need to be worked upon. You can add people to the item-specific conversations; cross-refer to other JIRA items; create sub-tasks; and drill up, down, and through to the other linked JIRA items. I’ve used quite a few organization-specific bug trackers as well.

Besides, you have to look for a software that can help you push data into the version controlling software. I’ve used Git Extensions to push data into Bitbucket, but I’ve found both SVN and VSS to be of equally good quality in their management and response. You can look at Git Hub, too.

For one of my previous stints, we’ve even used Microsoft Word for creating and managing the content. We would later export it to PDFs to circulate the technical documents to our customers. There isn’t one tool that I’d pinpoint as the best of all. But, based on the points I mentioned in the beginning, you can still zero in on what software you require for your organization.

I hope I’ve been able to answer your question.

Oh, and I published this answer on Quora with a disclaimer because I thought it would be nice for me to come clean.