Myths about information development: Busted

People tend to create stereotypes about things they don’t have much insight into. I broke into information development from a different industry, and I’d like to share my own experience of mythbusting. 

Before starting my career as an Information Developer, I was a translator and had little awareness of the role and its responsibilities. As a philosopher once said, “Theory without practice is empty”, and I’m glad I got a chance to fill the void and break my stereotypes during the first month of practical experience. Let me share some of them with you.

Advertisements

User experience in restaurants or keep your users in mind even at leisure time

Believe it or not, but an InfoDev at work is an InfoDev for life. As Information Developers, we perceive the world from the users’ perspective always questioning ourselves: “Is it clear enough? Can a procedure be shorter? Will that be understood globally?”
Sometimes, before you know it, you find yourself evaluating the user assistance in a 5-star hotel, scrutinizing an airport sign or a restaurant menu, and hunting for the ambiguous, the ineffective, and the incomprehensible with the noble intent to make a user experience smoother.

In this article, I will share my experience of reading the icons in a menu at one of the restaurants.

Microsoft Writing Style Guide 2018: Procedures and formatting highlights

In 2018, we devoted several  posts to the latest writing style guide from Microsoft:

• Microsoft Manual of Style vs. Microsoft Writing Style Guide
• MMoS vs MSG: The old, the new, and the unexpected

Yet, Microsoft guidelines is the topic one can talk about endlesly, isn’t it? 🙂 This time, I decided to focus on a few aspects of procedure writing and formatting that grabbed my attention most.

Grab your favorite drink, turn up the sound, and don’t miss the quiz at the end of the video!

Here’s a sneak peek at the video highlights:

• Use device-neutral verbs.

Users may interact with your product using various devices and input methods.

• Minimize UI terminology (menu, tab, box, and similar.).

Fewer words make actions more clear. Compare these: “From the File menu, select the New option” and “Go to File > New”.

• Mind the look and feel of your text.

Proper combination of font size, line spacing, and capitalization makes your text more scannable and easy to follow. Microsoft provides specific formatting advice to get you started.

Do you use these guidelines in your docs and did they make a difference for you? Let us know in the comments!

TechComm and Artificial Intelligence (overview of a podcast by Seth Earley)

Nowadays, artificial intelligence is a central subject in the constantly evolving world of technologies. It is believed that in the long run, it will define the next generation of software solutions. Simultaneously, there is a lot of anxiety that Artificial Intelligence (AI) is going to lead to significant labor displacement.

So, in the context of Technical Communication, does the advance of AI mean that our trade is doomed to extinction as well?

Evaluating the effectiveness of your e-learning

Having planned your e-learning thoroughly—with the analysis of the training needs, audience, and tasks, storyboarding and prototyping, content creation and testing—it might cross your mind that publishing your course is actually THE END. Not that fast, my friend! Have you evaluated the effectiveness of your e-learning yet?

via GIPHY

Here are a few techniques to check if your e-learning is effective:

• Kirkpatrick Model
• ADDIE Model
• Learnability Framework

UX copywriting series. Dropbox feature descriptions

No matter what you’re writing—whether it’s a small tooltip or a long web article—you need to thoroughly check your writing before you publish it.

Good writing is not just about spelling, punctuation, and capitalization, though we definitely need to keep them in mind at all times, among like… a million other things.

During UI text review, InfoDevs point out things that non-professional writers would never think to think about. Today, I’d like to talk about the most typical things that we stumble upon during the UI text review.

Brace yourselves – it’s going to be a long article but a 100% practical one and so worth a read! We’re going to discuss 6 reasons why Dropbox feature descriptions did not pass our UI text review.

Leading by example in legacy projects

One of the typical ways for agreeing to have project documentation in place is this:

1. Customer voices the need for documentation (on a side note, product-based software companies are not considered in this discussion).
2. Documentation team provides the estimates.
3. Estimates are adjusted and approved.

This works well for new projects and new features in existing projects. On a side note, this also assumes that the people who give the final approval for documentation do understand why documentation is needed.

But what about legacy projects, the ones that are poorly documented or not documented at all? How do you convince the company (or the customer) that documentation is needed?