Category: Sales & Marketing

How do you measure whether or not a document is communicating what it should? How do you define good documentation? – I define it as being applicable, usable, and error free. Documentation has to be written for the target audience as everyone has different roles and responsibilities. The following questions can be asked via feedback or during review time to ensure that all written material accomplishes its goal.

Feedback

Feedback can be gotten through comments, check points, or star ratings. Preprinted questions can sent out electronically or be attached to the back of each document. Some questions to ask are:

• Did you read it in detail
  • If no, what did you skip
• Were the Table of Contents, Appendix, and examples helpful?
• Was it easy to read and comprehend?
• Was the flow of the document consistent?
• Was the layout of the document suitable for reading?
• Were the activities suitable and helpful?
• How long did you spend on each portion of the document?
• Was it complete and understandable?
• Was the time spent worth it?
• Were you able to use the documents and did not make any mistakes while applying the knowledge?
• Would you refer this document to others – recommendations?
• Would you like to add something to the document?
• How often should this document be reviewed?
• Who is using this and where?
• What was missing-what else should be captured?
• Were you able to learn from this?
• Should there be more breaks or white space?
• Was the format of the document suitable?

Depending on the type of document written, focus the questions on the audience reading it. For example:

For trainers, coaches, mentors, instructors ask:

• Were there enough exercises, separations, directories, and appendixes?
• Did it contain accurate and precise content?
• Did it help to prepare the staff and/or learners?
• Did it reinforce learned knowledge

For a global organization, ask:

• Did the document capture and relay the objective of the organization?
• Was the correct knowledge transferred?
• Was the language used suitable, appropriate and understandable?
• Was the usage of the document easier than meeting face-to-face?
• Was the translation software able to phrase local terminology suitably?

For an IT department or technical personnel, examine the following:

• For Project managers, developers, and stakeholders,ask:
  • Were the requirements, and specifications complete enough?
  • Were there enough designs, illustrations, samples or were there too many?
  • Did it provide the appropriate critical security information?
  • Were the designs, cases, and purpose of the document accurate and reliable?
  • Was it organized well?
  • Were there enough business cases?
  • Was there enough data and information for marketing for sales engagement?
• For the QA department ask:
  • Were there enough scenarios to aid the testers?
  • Were documented requirements and specifications met?
  • Was there enough data for testing?
  • Was enough information given to access data and equipment for testing?

After collecting all the feedback, keep a running chart of the responses- keeping track over time will show you the worthiness of a document.

If you have had experience with measuring the quality of a document please leave a comment.

I know, I know, everyone else in your organization creates bullet pointed slides, complete with facts and numbers, or long lists of actions, reasons or steps. So why shouldn’t you? Well, one reason is that most of us will end up reading each bullet. Good, bad or indifferent, if it is on the slide we tend to read it. Another reason is that these lists of words and numbers are not visually appealing or memorable. They are easily snoozed through or forgotten.

We know better, yet we so often fall into the same-old bullet-point trap. Even if your organization does not encourage creative approaches, here are some strategies that might just encourage you to do better without getting too radical.

1. Declutter. Take out sentences, unnecessary words, headlines that repeat the title of your project over and over and details you probably won’t need. Group things. Use more slides, allow more white space. Ahhh, feels better already.
2. Increase color and graphics. Use SmartArt to create content that looks more like a graphic than just words. On the left is a simple example that would take you less than five minutes to create, and adds relationship information that bullet points would not.
3. Get rid of clip art. That smiley face? That silly stick figure? Out they go. The exception: your hand-drawn diagram, if it really tells the story. Create a screen capture or a scan and include that. Unlike clip art, we haven’t seen that a million times.
4. Add photos. Pictures you take yourself are best, like pictures of your team or your shop floor. Pictures your organization has the rights to (like your product) are terrific. Be sure whatever you use is royalty-free and that you have the rights to use it. Even Creative Commons pictures need to be studied carefully and attributed correctly to be sure you are using them legally. And do be sure the picture is there for a good reason, not just as decoration.
5. Get rid of templates and dark backgrounds. Unless your organization insists you use their corporate template (in which case, go for it,) consider using a simple white background without fancy fonts or treatments. Use a simple color palette of black, white, navy, or gray. This is a perfect canvas for easily-read content and for colorful graphics or photos. Use one or two at the most common fonts, preferably sans serif ones like Arial or Tahoma. (I really like Arial Black for headlines.)

Today, take a look at the slides for your next presentation. What can you take out? What could you add in that would add color, life and emotion? Be the maverick in your organization who dares to do better in creating and delivering visuals that actually add value to your presentations.

Please let me know what you think, what you have tried, and how better slides are perceived in your organization.

Wireframes allow developers, designers, trainers, managers, marketers, etc. to communicate and transfer knowledge to different types of audiences through the use of diagrams, images, models illustrations, or drawings. They exist in the form of screen shot, diagramming, and modeling applications. A few of these features are already included within existing applications. These suites of tools provide the ability to translate concepts into functional requirements, prototypes, and eventually real models or products. Another important capability is the facility to present easily understandable views of processes and procedures.

They are extremely useful in helping to avoid misinterpretations of deliverables in a global market by providing:

• a view of, e.g., user interfaces, procedures, and schemas (for interactions, work flows, and relationships),
• the ability for early design decision making , and
• a means for translating complex ideas into simpler concepts or thoughts .

Many of these tools are accessible on the web for free. Here are some tips for choosing a wireframe:

• Make sure that the application does what you need it to do and functions in a way that is easiest for you to use. For example, can it easily help to develop use cases, testing scenarios, flow diagrams, site maps, functional specifications, charts, processes, prototypes, etc.?
• Can it create a view of the information architecture and aid in organizing data into categories, visual frameworks, and models?
• Does it fit within your system platforms (web-based or desk-top application)?
• Can saves be performed in various formats and are they shareable?
• Check out the options. Is it suitable for you – can it help with online static content as well as dynamic content?
• Check out ease of use. Does it provide, e.g., ease of navigation, drag and drop, preformatted styles and templates for flow charts, org charts, and diagrams.
• Is it interactive; can it create a simulation or can comments be added? Does it allow for online learning, presentations, storyboards, and mockups to explore a wide variety of design options using different formats?
• Are objects reusable?
• Is it flexible enough for use on mobile devices?
• The most expensive may not be the best application. Check out licensing agreements and costs before purchasing. Make sure you have the correct number of licenses for the number of machines or platforms that is needed for the present and the future.

In the end, when deciding on a wireframe tool, think of the above questions as well as:

• Can it help to provide information and knowledge to help meet business goals?
• Can it aid in training and marketing for understanding the product?
• Can it help in presenting departmental, software, or functional processes?
• Can it help to meet the company goals and provide the desired outcome?

Wireframes aid the technical writer in creating a structured framework for communication. It is the skeleton of a product or process and is a great aid to get technical writers through the first stages of development. You might say it’s an outline and provides a background from which to begin building.

Please leave a comment if you have used or find that wireframes are indeed useful.

What does zone have to do with presentations skills? Mihaly Csikszentmihalyi, psychologist and author of Flow and Finding Flow, says that when we are in a state of flow, we are completely immersed in our task and at peak performance. We feel sufficiently challenged but confident in our skills or ability to do the task.

Being in the presentation zone is similar. It is a state of focused awareness with a distinctive lack of self-consciousness. I first heard this described by a colleague who told me when she was training a class she just opened her mouth and content started coming out. She said she “didn’t know where it was coming from.” Of course it was coming from a deep well of experience and knowledge, and because she was “in the zone,” the content was able to pour out unhindered by self-consciousness or inhibition.

When this happens to you, you will notice you are completely in the moment. It is almost as though you are one with your audience. You are totally aware of what you are doing and saying, and you are aware of your audience and how they are responding and reacting. Your words tend to flow smoothly, your face and voice are expressive, and you move and gesture instinctively and easily. It feels good, and if you have the underlying skills and knowledge, you may well be at peak performance.

How do you get into the zone?

Deepen your subject knowledge. Don’t have it? Become an expert. Research, dig deeper, and discuss it with experts. Read even more. Think about related content. Talk about it at every opportunity. Now, narrow down your presentation. Create a clear, concise message about your content. Tie every fact, story and detail to that message. Don’t add anything more. The reason for the deep knowledge is to build your confidence and credibility, and so you can answer questions that come up.

Ace your rehearsal. Rehearse early and often, and not only in your head. Every time you look at your slides, start talking through them out loud. Speak your entire presentation out loud at your desk or in your car, record and listen to it. Get a pilot audience to listen to it. Talk about it over lunch with colleagues.

Prepare for questions. Jot down every question you think you might be asked. Do you know the answers to each one? If not, do some more research for the answers. Have your pilot audience ask you questions, tough ones. Practice your answers. Make cue cards and drill yourself. Keep at it until you are confident you could answer just about any question that comes up.

Walk away. Clear your mind a while. If you start feeling anxious, take a break do something pleasurable and relaxing. Take a walk. Go out for lunch. Play with your children. Listen to music. If you are not fully prepared, you will be refreshed and more ready to tackle preparation. If you are fully prepared, try to stay in a relaxed state, knowing you will be better off with a clear mind.

Take care of your physical self. Eat well. Sleep well. Allow enough time to arrive at your presentation location without stress. Set up your presentation and check your equipment. Meet and greet your audience as they arrive. Focus on them, not on your presentation.

Keep your focus on the audience, not yourself. Remind yourself it is all about them, that you are in service to the audience, there to help them with the content you are going to share. Focus on the idea, the action or the change you are advocating and why it is good and important.

Take your time. Walk to the front with confidence. Look at the audience a moment. Smile. Now begin.

Forgive mistakes. If you make a mistake, let it go immediately. Put it out of your mind by focusing on the next slide or the next point you will be making. If you carry it with you, even a tiny mistake can impact the rest of your presentation, and maybe the next one.

If you have ever been in the zone during your presentation, you know how great it feels. Prepare, rehearse, and ready yourself with the goal of getting and staying in the zone. You will be at your best, your most audience-focused and most confident. What could be better?

Author Gail Zack Anderson, founder of Applause, Inc. is a Twin Cities-based consultant who provides coaching and workshops for effective presentations, facilitation skills for trainers and subject matter experts, and positive communication skills for everyone. She can be reached at info@applauseinc.net.

Web site: www.applauseinc.net

Blog: www.managementhelp.org/blogs

twitter: @ApplauseInc

I was reading about Agile and Scrum methodologies for project management when I came upon the term ‘User Story’. As an introduction, Agile is a methodology used for software development projects. It provides more control than just stepping through the analysis, design developing, testing, and implementing stages of a project as a whole. The Agile methodology breaks down each stage into subsets so that there is more communication, collaboration, feedback and discussion as each stage is completed. The Scrum methodology (a subset of Agile) is where each piece of a project is worked on as individual tasks for more accuracy and control.

A User Story (a further subset of the above methodologies) is a single sentence that describes a particular task that needs to be done. This need will define a particular project. As an example, suppose a manager is having trouble finding certain information on an employee. The manager may write the following sentence: ‘as a manager, I would like to find employees with have not taken any sick days so that they can be given an award.’ That sentence or User Story is then brain-stormed to understand what the manager is requesting and to discuss details as to how to accomplish the task. All subsequent ideas and solutions are noted and prioritized. The brain-storming sessions will also discuss items such as requirements, functionality, time, cost, tools, resources, due date, testing, etc., but not all in one meeting; each item is done separately and documented.

A User Story is not a Requirements Specification. The Requirements Specification is much more detailed and is basically an agreement which ensures that the client and the project managers are all on the same page. As a whole, it describes the project and outlines the client’s requirements and expectations up front.

In comparison, a User Story is brief and describes what the user wants in one sentence. If a User Story is long or needs to be broken down further (e.g., as a manager, I would like to find employees who have not taken any sick nor personal days so that they can be given an award), then it is known as an ‘epic’. The ‘epic’ will then be broken down into simpler sentences for clarity (e.g. as a manager, I would like to find employees who have not taken any sick days so that …. And as a manager, I would like to find employees who have not taken any personal days so that …). In other words, a ‘to do list’ is created. This list is known as a ‘product backlog’ and will be prioritized and managed by a product/project manager or technical writer. During various stages of the development, more User Stories (‘to do lists’) will be created either by the user, developer, or manager.

Are User Stories useful? Some say yes as it drives or communicates what a client wants and sets the stage for accomplishing individual tasks to complete a project, but others say that without the Requirements, Functional, or Technical Specifications, it is difficult to see how the finished product can be completed. No matter which methodologies are applied or what form of documentation is created, the written material should be able to explain in a concise and clear manner what was requested, how to accomplish it, and be focused on getting what the customer needs and that is what is important.