The Visual Communicator

coworkers looking at each other gadgets screen

The Visual Communicator/Designer is involved in the page layout, the framework, the elements on a page; it is never ending for a Visual Communicator. Creativity is everything for a Visual Communicator. As a Technical Writer, you also have to be a visual designer. You need to be up on all the popular tool sets as well as be aware of the more popular methods of presentation. Let me elaborate on that. Popular methods of presentation include webinars, blogs, mobile, classroom, meetings, storyboards, and online lecturing. Presentations are relevant for delivering information to the target audience and to keep them interested, you have to be prepared with dynamic deliverables.

It is a good idea to have viewed a lot of presentations yourself to see what is liked or disliked. Presentations can’t just be graphs and its components. It has to be visually appealing to maintain the audience’s attention. It has to show relationships between all the different elements on a screen or page.

Images

Use illustrations, tables, charts, graphics, and even print screens; let the image do the describing and make sure you note any exceptions to any process. For images that also involve text, separate the graph from the text. Keep the audience’s attention, for example, by not just presenting a graph or chart; add in light bulbs, colorful fonts, or other images or patterns to highlight certain key points or areas

Humor

Whether it is process that you are presenting or a new product, it is a good idea to include a little bit humor or cartoon to break up the material or else the audience will be on information overload. Have the cartoon do the pointing for you. They need this humor to digest it all.

Text

For a presentation that might involve a lot of text, use bullet points and make it simple; less verbiage. Also, use icons, numbers, and/or alphabetize. Include flow diagrams when moving from one point to another instead of verbiage.

White Space

To reemphasize, make it visually appealing, logical, organized and helpful by separating out data or material. In other words, use a lot of white space. The simpler the design, the better.

Mobile Devices

With mobile devices being so popular, once you create your visual design, test them out on certain mobile devices to see how they appear. You may need to make adjustments so that images will not be cropped or cut off.

As with technical writing, visual designs have to be clear, concise, organized, and provide what your target audience requires.

F is for Focus

Young lady presenting while writing on the board

We continue with our alphabet of terms for great speaking.

Focus. When we speak in a focused way, all our energy works toward the same end–getting our message across. Our thoughts, our words, and our bodies all work together to send a unified, cohesive message. When we are in this particular state, words tend to come more easily, we gesture more dramatically, and it is almost as if we forget about ourselves. We speak fluently, with fewer fillers like “um” and much more dynamic expression. So how do you get to focus? Sometimes it is by directing our attention on the audience and what we bring to them. Sometimes it is being clear and passionate about our subject matter. Very rarely does it happen by thinking about our own selves or how well we are doing.

Friendly. Once again, when we focus on ourselves, or on the words themselves, we tend to get very serious. Our faces tense up, and often our bodies do too. We are there, but not there. We are all in our heads, not present in the moment. We often don’t even see the audience in front of us. Next time you speak, before you begin, make a conscious effort to connect with the audience. Look at the faces before you. Extend your gaze. Soften your eyes. Put on a welcoming smile. Breathe. Now you are ready to begin. Allow yourself to be present, to give of yourself to your audience. Don’t worry so much about what words you use, but about the thoughts and messages you wish to share.

Fresh. Are your ideas, your words, your very phrases stale and outdated? Or do you bring fresh perspective every time you speak? Sometimes we give the same presentations over and over until we get bored with them. We go on autopilot, mouthing the words without really connecting with them. Guess what? The audience can tell! If you have ever gone on autopilot, consider it an opportunity. Once you know the content well enough to go on autopilot, you have the opportunity to play with it. Change the sequence. Change the stories and illustrations you use. Instead of telling, use dialog to get everyone discussing the information. One well-known consultant in our area says he changes one third of his content every year, so he is constantly adding fresh content, and every three years it is completely revamped. This seems healthy to me. If your presentations seem stale, do something different each time you speak. Trust me, it will wake you up and keep you on your toes. It will make you a better speaker.

Are you a focused, friendly and fresh speaker? How did you get that way? How do you stay that way?

If you think of great words for upcoming letters, please add a comment.

To Train Or Not To Train A Technical Writer

An instructor training a staff while pointing at the laptop screen

Lots of questions have been asked as to whether or not you need formal training to be a Technical Writer. Personally, I feel the answer is yes. You need to have some kind of training or degree, whether it is a degree in journalism or a certificate in Business Writing, or a degree in English or Communication. But it is even more than that. Today’s Technical Writer needs a technical degree or a technical background to get a foot in the door, such as a degree in the Sciences, i.e., Biology, Computer Science, Engineering, etc. Many companies have hired people who are not technical and are just writers and have been disappointed in the results. Reason being, their responsibilities included:

  • Gathering requirements from subject matter experts such as clients, developers, etc.
  • Translating complex technical information, development and relational database concepts into clear easy to understand language for developers and users as well as for training and marketing material
  • Understanding complex technical information and organizing it into logical sections that can be followed by the target audience
  • Creating a variety of documents that involve standard operating procedures, request for proposals as well as usability testing and regulatory compliance requirements
  • Having good communication skills and being able to stick to schedules
  • Developing project plans and being a knowledge liaison across departments.

Originally, people started off with a degree in writing (i.e., journalism, Business Writing, English) and worked in various companies or did freelance work. Sometimes this work took them into the technical writing arena. From there, they gained more and more experience within the technical field.

If you begin with a technical degree, you can end up writing for an infinite variety of industries from financial to education, to technical companies to publishing, to Civilian and Defense industries to government contracts, to any kind of global contract. If you begin with a degree in the sciences like Biology, you can possibly end up working in pharmaceutical companies or in a related field. Also, fields such as engineering, chemistry, physics, aerospace, manufacturing, computing, finance, consumer electronics, and biotechnology all need Technical Writers. The field is wide open to you.

So yes, you need some sort of training to be a Technical Writer, because a Technical Writer has to comprehend technology in a way that can be explained to a target audience. You have to be able to research and understand the technology you are working in. Think of the position as a Technical Communicator, because we are translators and professional editors. We are translators because we break down technical terminology into understandable everyday usage for our target audience. We are editors, because our documentation has to be error free in the usage of grammar, spelling, etc. This is especially important when producing writing matter such as marketing, training, or compliance material, which reflects upon a company’s image.

Do you agree?

E is for Energy

Team rejoicing working together on a project in an office

If you follow this blog you know we are working our way through the alphabet, selecting words for each letter that embody different aspects of speaking and presenting. We have made our way to the letter “E.”

Energy. We all know how important energy is; too much and you feel like a nervous wreck, speaking too fast and bouncing off the walls like a toddler with too little sleep and too much sugar. Too little energy and you can come across as sleepy, slow, b o r i n g. Managing your energy so it is just right is a little tricky, but once you learn how to use it properly, you will be able to handle yourself under all kinds of pressure. As a result, your energy works with you and gives you power. (One little tip; stop thinking about nervousness, and think instead about using your energy rather than letting it act on you.)

Engaging. Usually the second thing my clients say makes a great speaker is being engaging. (The first one is confident!) A great speaker doesn’t just talk at or even to the audience, instead they engage them in dialog. You really can’t be boring if you are truly engaging. The best speakers use stories, examples, metaphors, visuals, discussions, or activities—whatever it takes to bring content to life and life to the audience. They ask questions, listen intently and care what the audience thinks. Great speakers encourage their audiences to ask meaningful questions, and they answer honestly. They foster give and take in every aspect of their presentations. They turn every talk into a conversation. And guess what? You can do these things as well.

Eye contact. This is such an important delivery skill, and one we sometimes overlook or underestimate it. Think about it; when you are face to face, eye contact is the single most important way to connect with your audience. Trouble is, when you are focusing on your thoughts, your words, or your slides, you might forget to look at your audience. Or it might be distracting, so you look away. Take time today to monitor your eye contact, and see if you can make a slow, steady connection with each person you are speaking with. Better yet, ask a trusted colleague to observe you and give you feedback on your eye contact. Ideally, it will be slower than sweeping the audience, but shorter than a staring contest. Two to four seconds per person is realistic but takes plenty of practice to master.

How have your embodied these attributes in your speaking? What results or outcomes have you enjoyed?

What other words come to mind for the letter E? And how about upcoming letters? Submit your ideas and get extra credit!

What is a Bug List?

Stressed young business man having headache because of a bug

When problems are encountered during the testing phase of a product or application, they have to be noted so that the problem can be corrected or prevented before the next testing phase. These problems have to be noted within a form known as a List of Errors form or a Problem and Resolution form or an Incident form. For us right now, we’ll simply call it a Bug List. Any irregularities or anomalies noted within the Bug List will be passed to the development group, who will resolve the problem.

The Bug List should contain at least 5 columns. The column headings should be listed accordingly: ‘Date Bug Found’, ‘Description of Bug, ‘Resolution’, ‘Date Bug Closed ‘, and ‘Comments’. The tester will describe in extreme detail the exact steps that led up to the occurrence within the ‘Description of Bug ‘column. This part of the form is crucial for replicating an error. Without it, the developer will not be able to duplicate the error and hence correct it.

For finding bugs (problems), every test plan has to be extremely detailed and every test scenario listed. Yes, there will be times when not every case/scenario is noted. If the tester does create a unique case, this case should be noted within the bug list. This way, when the application/product goes into the next testing phase, this new test case will be added to the test plan, as well as tested.

When testing is completed, the list will be directed to the appropriate developer and Project manager involved. Every bug found should be corrected, but then there are various grades of bugs. There are quick fixes, such as spelling errors, simple fixes which involve minor programming, i.e., a value was to be added and wasn’t, medium sized fixes which take a few hours when a functionally will not work under certain conditions, serious ones which require rework, and red flag ones where the applications/product seizes to work. Depending on time constraints, the more serious ones (red) will be corrected first. Then when time allows the minor ones will finally be corrected.

Once the problem is corrected by the developer and the fix is inserted into the ‘Resolution’ column, the tester will be informed. The tester will then perform regression testing where the tester tries to recreate the error. Once the tester is satisfied that the issue is resolved, a date for closing the bug can be inserted within the ‘Date bug closed’ column, and any pertinent comments needed can be added to the ‘Comments’ column.

For more complicated testing, there are now programs that will perform automatic testing when needed for direct testing and for regression testing. These new applications are really helpful especially when repeated tests need to be done. To help you keep track of all the bugs, there are also programs out there now that will assist you in keeping track of all bugs. These tracking programs are very useful, especially when a Quality Assurance Manager needs to be on top of all Red flagged issues.

This part of the Testing phase, where time is spent on creating the Bug list, has to be taken into consideration when scheduling time within the project plan. The same goes for adding in time for correcting problems and regression testing. Without the project plan, we would not be aware of our time line or different events that have to occur from a product or applications initiation or start to its completion. But to get back to the Bug list, without it, we would not be able to communicate and keep track of all these problematic issues that need to be resolved.

D is for Dynamic

A young lady smiling and moving her hands

We have been exploring the qualities of great presenters, starting with A and on our way to Z. Each week we list one or several attributes of great presenters and communicators, and suggest some ways you can build that characteristic in your own speaking.

If you want to play along, suggest your own great words starting with that letter of the week. Better yet, help me out by suggesting a word for the next letter of the alphabet! And let me know how you are using these ideas to build your own habits and characteristics for great speaking.

Dynamic: having life, energy, passion about your topic. Nothing can replace this! If you are worried about remembering your lines, this can rob all your energy and leave you flat. Audiences today have very little tolerance for a speaker just reading the slides. Break away. Tell a story. Talk about the problem, or your solution, or your audience. Breathe life into your presentation. Ahhhh! Much better!

Daring: if everyone else just reads through the boring bullets, are you really going to do the same thing? You could, of course. But why not be a little bit daring? Hide some of your slides. Edit out some of the detail. Add in a few great graphics. Photos of the team or the customer’s plant. Hit the “B” key while presenting a get a black screen, turning the attention off the slides and onto you. Now that’s daring.

Distinctive. What is your unique presentation strength? What makes you special? If it is your expressive voice, play that up. If it is your ability to tell stories, weave them in. If you are really good at humor—and you might want to ask someone to validate this—sprinkle some in. If you are great at facilitating a lively discussion, feature that in your presentations. No one can be you, so find what makes you distinctively different, and run with it.

How have your embodied these attributes in your speaking? What results or outcomes have you enjoyed? What cautionary tales would you add to those willing to be daring, distinctive and dynamic?

What other words come to mind for the letter D?

Creating Test Plans

Coworkers in a Conference Room having a Meeting

Once the application/product has been created and before it goes live, a detailed quality check will be conducted. To perform this check and to ensure that all functionality/features/ attributes/ facets of the product perform as intended, a Test Plan is created and used to perform a detailed check on the application/product. A test plan can be created for prototypes, system and data migrations, system designs etc, but what will be posted here is a sample test plan for a simple field within a product. No matter what type of test plan is created, the logic and organization of the test plan created will be similar to what is noted.

To clarify the definition, Test Plans are needed to help the Quality Assurance (QA) tester conduct a series of tests in order to validate an application via functionality, task oriented or even mathematical or data tests.

To present the Test Plan, use an outline format so that a task can be noted and insert sub-tasks to further define the test. This format seems to be the easiest to follow, as Test plans are usually extremely detailed. As a simple example, if a numerical field is to be tested within an entry form, list this as a task. Then below it, list sub-items that need to be checked.

For example:

  • does the field accept the maximum length of numbers,
  • If more than the maximum length of characters is input:
    • does the field accept it,
    • does an error message occur; if yes, note in bug list
    • does it accept alpha or extraneous characters; if yes, note in bug list
    • does it accept decimals.
  • is the data saved when you go to the next screen and return (check previous screen as well)
  • check the database
    • is the data saved as entered.

All this may seem tedious, but those are the typse of scenarios that need to be tested. Every situation listed has to be tested step-by-step and verified. Every action that a user might perform has to be noted and checked. Along with verification, the test plan should also check to see if the application is logical or if the flow makes sense. The creator of the test plan needs to have placed them self in the mindset of the user and include different actions that a user might perform.

The beginning of the Test Plan, along with pertinent instructions, should include:

  • System requirements denoting the platform under which the program would and/or would not work, who can access the program, and what results should be expected. This precedent should also be verified.
  • A set of detailed systematic instructions as to how the application should work and what steps the tester can undertake to validate the authenticity of the program or to invalidate it. In other words, the tester needs to see if the program can be broken or fail or has faults in it; to invalidate it.

Test plans are lengthy, detailed, and have to be part of the team’s project plan. Test plans must consist of a series of test cases or scenarios which will aid in retracing steps whenever problems occur as well as for regression testing.

When problems are encountered, different resolutions should be tried and then listed. If no resolutions are listed, note them as irregularities or anomalies within a Bug List.

We will talk about a Bug List in the next post.

C is for Courage

Young man feeling courage and confident

We continue describing effective presentation skills by the alphabet.

C is for

Courage. It takes a certain amount of courage just to get up and speak. It takes even more to be authentic, or to take a risk in front of your peers. Tap in to your courage like the cowardly lion in the Wizard of Oz. if you have something to say, you have the power, and the courage to speak up.

Charisma. Charisma is “unearned charm that makes you attractive to others.” If you–like most of us–don’t have it naturally, compensate with real enthusiasm, passion for your subject matter, and interest in people. Go out of your way to listen well and make genuine connections with people. Don’t forget focused eye contact to charm and attract your audience. Think Bill Clinton.

Confidence. How you walk into a room or take the stage already says volumes about you. Stand tall but with ease. Breathe. Smile. Gesture when you speak. Learn how to project your voice and speak with rhythm and varied vocal inflections. Eliminate hesitancy and questions in your vocal sounds. Act as if you were supremely confident and tell yourself you are.

Curious. Nothing is worse than having a presenter ask a question they clearly don’t care about the answer to. Plan to learn something new in each presentation you give. Engage with your audience with a sense of curiosity. Share the knowledge you have and build an even deeper knowledge by adding what the audience knows.

How have you embodied these attributes to become a more effective presenter? What other words that describe effective presenters start with the letter C? Would love to hear from you!

Technical Writers = Business Analysts = Usability Expert

Analyzing a current business process

I am seeing a trend here, where TW=BA=UX. Multitalented Technical Writers are now becoming more involved within organizations. They must know the business as well as a Business Analysts, and they are also becoming our Usability Experts. They are a versatile, adaptable, resourceful group of writers, mainly because their function is in knowledge transfer. They have become so involved in the business processes that they are now our Knowledge Managers with sub-titles of Technical Writer, Business Analyst, and Usability Expert

Let’s first define a Technical Writer (TW), a Business Analyst (BA), and a Usability Expert (UX). Checkout this comparison chart:

Tasks required TW BA UX
Understand the business Writes about business models Analyses the business model Uses business models
Transfer knowledge Ability to communicate Ability to communicate Ability to communicate
Work across various functions/disciplines Gathers information Gathers information Gathers information
Information Architect Designs a user interface (UI) structure Designs a interface (UI) structure Designs a user interface (UI) structure
Governance of information Handles data or information Handles data or information Presentation of data or information

The TW translates the business terms and technical information into simple easy to understand terms and guidelines so that the project can be accomplished.

The BA translates business policies, strategies, or regulations into system requirements for a project and takes a course of action to ensure the completion of the project.

The UX translates business requirements into information retrieval by ensuring the right data is captured or presented through an defined process.

All three roles have to:

  • Analyze and document the current business processes to ensure that the content is understood by the project stakeholders.
  • Create and present process flows, information architecture, site maps and prototypes for complex applications.
  • Identify and document future business processes including opportunities for process improvements.
  • Understand the features, functions, and capabilities of applications or services or products in order to achieve high performance goals.
  • Gather business requirements using different requirements gathering techniques (e.g. interviews, surveys, meetings, etc.).
  • Analyze and document business requirements using specific modeling or case tools.
  • Partake in tracking changes to the project.
  • Work with the business stakeholders, i.e., graphic designers, web developers, business analysts and software engineers.
  • Translate business requirements into technical and functional specifications.
  • Collaborate with the technical resources or any subject matter expert to gather specific (data or design) information.
  • Conduct, coordinate, and perform user acceptance tests, user walk-through sessions, and other ways to test the designs as well as create test plans to ensure adherence to specifications.
  • Act as a liaison between the IT project team and the business stakeholders.
  • Translating client goals into user-centered designs.
  • Write user-friendly text for on-screen instructions, headings, button labels, link text and other matter that have an effect on a user’s experience .
  • Create guidelines and sharing best practices.​

The role of the technical writer is ever evolving and becoming more relevant every day.

B is for Brilliant

Man shows his thumbs up while smiling

We have begun to explore the qualities of great presenters, starting with A and going all the way to Z. In each post I will list one or several attributes of great presenters and communicators, and suggest some ways you can build that characteristic in your own speaking.

If you want to play along, suggest your own great words starting with the letter for that week. Better yet, help me out by suggesting a word for the next letter of the alphabet! And let me know how you are using these ideas to build your own habits and characteristics for great speaking.

B is for

Brilliant. Brilliance is original thought, fresh ideas, spoken clearly and uniquely. It is not canned, not wooden, not predictable. It does not rely on canned phrases or routines. Maybe you start with a compelling question, instead of starting with “I am happy to be here.” Maybe you draw on a flip chart instead of showing a slide. Maybe you get the whole room laughing instead of being bored to tears. That’s brilliant!

Beautiful. Beautiful slides and graphics, that is. We all know the dreaded bullet-pointed, over stuffed, predictable slides are just plain ugly. Clean them up. Simplify them. Add a few beautiful photos. If you don’t know how to do this, read Garr Reynold’s terrific book Presentation Zen. Or ask someone with a good eye to help you reinvent yours. There is just no excuse for ugly, boring slides and this is one area where you can succeed where so many speakers fail.

Be there now. This is a key concept often spoken by one of my favorite clients. To them it means to pay attention to customers, and in interactions with colleagues. It also has meaning for us as communicators. It means eliminating the little voice in your head that distracts you. Refusing to think about whether you will make a mistake or not. Not worrying about the outcome. Just being in the presentation, at the present moment.

Brief. At a recent conference, nearly every speaker said they wanted to have an interactive discussion with the audience. But they lectured nearly to the end of their presentation, then lamented not having enough time for questions or discussion. Today, presentations are shorter than ever. I recently heard of a company where most presentations are five minutes long! How brief can you be? Tighten it up, then tighten it up some more. Especially if you tend to “run on.”

What other “B” words come to mind when you think about great presenting? What other words would you like to hear more about starting with any letter?