Case studies and white papers are very effective marketing tools if you want to promote the benefits of your product or services. Case studies are the first most popular device used to promote the business. If you plan to write a case study, this article will give you a better understanding  about this type  of business writing.

What is a Case Study?

Case studies demonstrate how a business condition was identified, how you identified the main issues, and the summarized your  results.

How to write a Case Study

Case studies tend to be short – between 500-1000 words.

In general, aim for three to five pages, and use one image per page at most. Case studies adopt a soft-sell approach.

How to Structure your Case Study

There are three sections to a case study.

1. Problem
2. Implementation
3. Results

The ‘problem’ section has to have a punch. In other words, it has to signify something to the person who reads it, something that they are able to relate to.
Focus on how the topic impacts the reader.

Demonstrate how your product resolved the business problem. The more explicit the case study, the more successful it will be.

Highlight the Benefits

Answer: how the solution, or service, addresses an issue.

Be careful here, as the whole case study is built in the region of this single issue.

Don’t dilute the case study by addressing more than the single issue – stick to one area and show how you can resolve the issue in measurable and proven terms.

Reduce Barriers

Case study writers need to demonstrate how their solution improves the situation. For example, how does it improve a business process?

This is an excellent area to state how your product integrates into other applications. You must use your conclusion when compile the last case study document. Avoid make it too technical or using too much statistics.

Case Study – Sample Templates

Compose the statistics set out so that the person who reads be able to easily grasp them and then memorize them later on.

About the Author: www.outsourcingresearchwriting.com

How much time do you spend working every week? I don’t mean being in the office, but actually working. You have 37.5 hours every week, but how much is actually spent doing what you’re paid to do? When I say working I mean developing real outputs (e.g. content); this includes illustrations, diagrams, publishing etc – whatever goes into the final deliverable.

Christine, my former manager, kept a record of all the tasks she did during the week. Here’s a breakdown of how much time was actually spent writing.

• Technical Writing – 15 hours (includes all writing tasks, such as release notes, developing videos, converting material from Word to FrameMaker and screen capture work)

• Email – 12 hours (includes correspondence to programmers, team members, sales, customers, mgt)

• Project Management – 6 hours (includes status reports, scheduling, document distribution & include feedback etc)

• Timesheets – 45 min (including revisions that need to be made so we can bill the customer correctly and allocate resources to the correct ‘bucket’)

• Internal Meetings – 6 hours (Mon & Fri office meetings, Tech Publishing Thursday meeting & meetings with HR (assessments) and project coordination meetings with Development)

• Customer meetings – 4-10 hours (this includes conference calls, status reports, emergencies, monthly conf calls with global depts, and project handovers. Mostly status updates)

• Travel – 6 hours (i.e. to customer sites or downtown to our HQ)

Total – 43-49 hours (50+ if you add in the travel)

Does this surprise you?

Less than 15 hours (30% approx) was spent on documentation. The rest was sucked up with email and meetings. While there are ways to reduce time spent on these, other areas are outside her control.

5 Mandatory Tasks

She has to:

• Go to customer sites

• Submit Status Reports

• Attend conference calls

• Deliver updates

• Create documentation

There is no wiggle room there.

How about you?

How much time do you spend actually doing what you want to do? How do you stop others from wasting your time and pulling you away from your goals?

Do you use Posterous to update your site? I prefer to use Yahoo and Gmail to update the site rather than thru the Posterous site. Why? It’s easier to add images. You can add tags to your posts when you blog by email. Here’s how.
How to add tags to Posterous blog posts
1. Click in the subject of your email
2. Use the syntax ((tag: Startup, Business Plan, Template, Whatever)).
Your tags will be displayed when you post.
You can also go in and change the tags on the Posterous site.
More tips over here: http://ivanwalsh.posterous.com/

From Shakespeare, Graham Greene, JK Rowling to Colum McAndrew, Ellis Pratt, David Farbey. All have all one thing in common – great writing! As my career started in the Baker Street, London in the 90s, I’ve always carried fond memories of my time in England. Here are some UK based technical writers you might want to add to your Twitter list. By the way, do you notice any difference between UK and US tech writer blogs?

Colum McAndrew

Colum knows more about Robohelp than anyone I’ve ever met and I wouldn’t be surprised if Adobe ‘made him an offer he couldn’t refuse’, for example, as a product evangelist.“Technical Writer with a keen interest in all Adobe TCS products (especially RoboHelp) as well as technical communication trends..”

http://twitter.com/robocolumn & http://notcolin.wordpress.com/

Ellis Pratt

Ellis is Director of Cherryleaf Limited a technical communication company based in the United Kingdom. “We are the most copied technical communicators in the UK, with expertise in single sourcing and online Help. “ Ellis, has a nice dry, sense of humor, keeping  Twitter lists for Squirrels, MeerKats and Elephants.

http://twitter.com/ellispratt

David Farbey

David “writes technically, constitutionally incapable of ignoring typos.”

He is a technical communications and information design professional and has been active in this field since 1994. David is a Fellow of the Institute of Scientific and Technical Communicators, and a Member of the British Computer Society. He has presented at professional technical communications conferences in the UK, Europe, and the USA.

http://twitter.com/dfarb & http://www.farbey.co.uk

Gordon McLean.

Glasgow-based Gordon is a “Technical Information Manager with Sword Ciboodle”.

Gordon is a member of the Institute of Scientific and Technical Communicators (and contributor to the monthly newsletter), and a member of the Information Architecture Institute. You can find him on LinkedIn or the Content Wrangler Community, and to find out more about me just visit my other blog or hey, Google me. http://twitter.com/onemanwrites

Alistair Christie

Documentation Manager for a UK-based software company, since 2002. “A long time ago (it feels like it anyway) I used to work in the publishing business as an editorial project manager for an educational publisher in Oxford. I later worked as a freelance editor and then decided to combine my experience working on books with my hobbyist enthusiasm for software and try my hand as a technical writer – and I never looked back!”

http://twitter.com/itauthor & http://www.itauthor.com/about/

Other UK technical writers?

Do you know any other technical writers based in the UK. Let me know and I’ll update the list.

I’ve started to use my social networks, such as Facebook more strategically rather than adopting a ‘shotgun approach’. In other words, I try to leverage each site by seeing the opportunities it offers and then using these. Recently, I’ve started to shift away from Facebook and moved to LinkedIn.

What does LinkedIn offer that Facebook doesn’t? Here are five reasons to Leave Facebook and join LinkedIn instead.

1. Target Audience – the average age on Facebook is 20 something and female. It’s a great place to meet people, swap videos, and chat. But it’s not a business platform. LinkedIn’s average age is 41. Most everyone is a business professional trying to meet other business professionals. So, for me, this gives it a huge edge over Facebook.

2. Business Groups – LinkedIn is designed around business groups. You can join these and instantly connect with people with similar interest. On Facebook, there may be fan pages, but it’s often just that, fans! No real dialogue goes on.

3. Recommendations – you can build relationships with people on LinkedIn and once they know/trust/do business with you, will give you recommendations. Professional endorsements give you an element of credibility that you don’t get elsewhere. And while this can be abused (I recommend you if you recommend me) it does seem to work.

4. Integration with other platforms – you can connect to LinkedIn from multiple social media portals, such as BusinessWeek, AMEX Open Platform, and even from Facebook.

5. Knowledge Exchange – I’ve kept the best for last. The conversations I have on LinkedIn are with the best people in their fields. You can learn a huge amount just by listening. Ask questions and see what comes back. The quality is very high. And unlike other sites, the conversations rarely degenerate into slanging matches. You can also receive the comments by email every day or bundled into a single email every week.

I will highlight other business benefits in the coming weeks. These are the first that come to mind.

Your thoughts

What do you think of LinkedIn? How does it compare to other business sites you’ve used? What would you like to see changed in it? How could it be improved?

Q: I’m setting up a Technical Writing Dept. for a Financial Services company. What is the best style guide to start out with? We have no internal guidelines. This will need to be useful for both beginners and also more experienced tech writers

A: The benefit of adopting a style guide is that it puts guidelines in place to ensure consistency across all documents you deliver. While style guides don’t make poor writers better, they’re a step in the right direction if you want to improve the quality of your documentation!

IBM’s Handbook for Writers and Editors

How Style Guides Can Help Technical Writers

Style guides can improve the quality and presentation of documentation. They establish a layer of professionalism that may not have been there before. They also reduce arguments and loose cannons within the department, as the style guide becomes the acknowledged reference.

4 Points to Consider when Selecting a Style Guide

There are at least four points to consider when selecting a style guide..

1. The Reader

Consider who will read your documents and ask:

• What is their reading level?
• What is their expertise?
• What is their motivation to read your material?
• Where do they read, e.g. office, while commuting, at home?
• What style do they prefer, e.g. formal or informal?

If you have different groups of readers, explore which group requires the most attention, and which guide suits their needs the most.

2. The Publication

• If you re producing one publication for the same readership, your task should be easy. However, if you’re managing press releases, technical documents, web content and newsletters, one style guide may not meet all your needs… and using two could be confusing.
• Most Fortune 1000 companies (with a variety of publications and audiences) use an industry standard style guide as their basic guide and write exceptions for different divisions.
• For example, the Marketing Dept might use the standards in The Associated Press Stylebook and Libel Manual, but use The Chicago Manual of Style for other sections.

3. The Users

• Editors value style guides. Difficulties arise when untrained staff members have to use the style guide when producing web content, reports, documents, etc. They find manuals hard to use and often simply ignore them.
• To resolve this, (for the non-trained writing staff) prepare a style booklet based on your main guide. Determine the most important style points and write examples in real-work sentences. Keep the booklet short and easy to read.

4. Your Preference

• If you don’t have a preference, test it. Check the most important style questions in the guides you’re considering, and then edit an article using each guide. Look at the results and once you have selected your primary guide, keep the rest for reference as each have their specialist areas.
• Then examine the site’s purpose and outline the main sections (e.g. words people use to navigate) and the links within those heads. Test it before it goes online.
• You can do this by writing the heads and links on Post-IT sticky notes and put them on a chart. Show the chart to sample users. Ask them how to get from one section to another.

IBM’s Style Guide for Developing Quality Technical Information

IBM’s documentation experts have prepared the definitive guide to developing outstanding technical documentation for the web and print.

Extensive before-and-after examples, illustrations, and checklists, the authors show exactly how to create documentation that’s easy to find, understand, and use.

Developing Quality Technical Information

 

 

Table of Contents

Part 1. Easy to use

Chapter 2. Task orientation

• Write for the intended audience
• Present information from the user’s point of view
• Indicate a practical reason for information
• Focus on real tasks, not product functions
• Use headings that reveal the tasks
• Divide tasks into discrete subtasks
• Provide clear, step-by-step instructions

Chapter 3. Accuracy

• Write information only when you understand it, and then verify it
• Keep up with technical changes
• Maintain consistency of all information about a subject
• Use tools that automate checking for accuracy
• Check the accuracy of references to related information

Chapter 4. Completeness

• Cover all topics that support users’ tasks, and only those topics
• Cover each topic in just as much detail as users need
• Use patterns of information to ensure proper coverage
• Repeat information only when users will benefit from it

Part 2. Easy to understand
Chapter 5. Clarity

• Focus on the meaning
• Avoid ambiguity
• Keep elements short
• Write cohesively
• Present similar information in a similar way
• Use technical terms only if they are necessary and appropriate
• Define each term that is new to the intended audience

Chapter 6. Concreteness

• Choose examples that are appropriate for the audience and subject
• Use focused, realistic, accurate, up-to-date examples
• Make examples easy to find
• Make code examples easy to adapt
• Use scenarios to illustrate tasks and to provide overviews
• Set the context for examples and scenarios
• Relate unfamiliar information to familiar information
• Use general language appropriately

Chapter 7. Style

• Use correct grammar
• Use correct and consistent spelling
• Use consistent and appropriate punctuation
• Write with the appropriate tone
• Use an active style
• Use the appropriate mood
• Follow template designs and use boilerplate text
• Create and follow style guidelines

Part 3. Easy to find

Chapter 8. Organization

• Organize information into discrete topics by type
• Organize tasks by order of use
• Organize topics for quick retrieval
• Separate contextual information from other types of information
• Organize information consistently
• Provide an appropriate number of subentries for each branch
• Emphasize main points; subordinate secondary points
• Reveal how the pieces fit together

Chapter 9. Retrievability

• Facilitate navigation and search
• Provide a complete and consistent index
• Use an appropriate level of detail in the table of contents
• Provide helpful entry points
• Link appropriately
• Design helpful links
• Make linked-to information easy to find in the target topic

Chapter 10. Visual effectiveness

• Use graphics that are meaningful and appropriate
• Choose graphics that complement the text
• Use visual elements for emphasis
• Use visual elements logically and consistently
• Balance the number and placement of visual elements
• Use visual cues to help users find what they need
• Ensure that textual elements are legible
• Use color and shading discreetly and appropriately
• Ensure that all users can access the information

Part 4. Putting it all together

Chapter 11. Applying more than one quality characteristic

• Applying quality characteristics to task information
• Applying quality characteristics to conceptual information
• Applying quality characteristics to reference information
• Applying quality characteristics to information for an international audience
• Applying quality characteristics to information on the Web
• Revising technical information

Chapter 12. Reviewing, testing, & evaluating technical information

• Inspecting technical information
• Testing information for usability
• Testing technical information
• Editing and evaluating technical information
• Reviewing the visual elements

Other Style Guides For Technical Writing

I recommend the IBM style guide as I use it and believe it’s the best out there, especially for technical writers. But, for those starting out, maybe it’s too detailed.

Two other style guides are:

and

What style guide do you use?

Do you like speaking in public? It’s the last thing most of us want do. So I was surprised to read how Al Gore, an experienced public speaker, reached out to Nancy Duarte to improve his public-speaking skills. Here are a few tips for the next time you have to give a presentation.

The Science of Great Presentations

Nancy Duarte knows how to make killer presentations. She founded Duarte Design, Inc., a firm that helps everyone from Google to Al Gore master public speaking. You can read her book slide:ology: The Art and Science of Creating Great Presentations here. In an interview with Guy Kawasaki, she explained how to avoid the most common presentation pitfalls and how she helps her clients

How to Improve Your Presentations

When it comes to public-speaking, reach shows that:

1. You can always improve. If an accomplished US Senator can swallow his pride and sign up for lessons, then why not you?
2. It’s a number’s game. The more you practice, the better you get. This is one of the few things in life that’s guaranteed. Practice makes perfect. Is there anything you practiced (anything?) and became worse as a result?
3. Success in one area generates more success in others. The saying, “The rich get richer and the poor get poorer” applies here. If you become more successful in one area—any area—your development is echoed in other areas. Oddly enough, if you stop making efforts, instead of standing still, you slide backwards.

7 Steps to Captivating an Audience

Guy Kawasaki lists the key points:

1. Tailor you content to your audience.
2. Develop ideas first & your slides second. Use the PC when you have the idea ready.
3. Use non-digital sources for inspiration, such as objects, nature and hand sketches.
4. Make slides that the Audience can recall— not to help you remember the script.
5. Rehearse the presentation. Ask for feedback. How will the audience connect to the materials?
6. Refine, refine, refine.
7. Rehearse until you’ve NAILED it!

How Al Gore Got His Groove Back

Nancy Duarte says that they helped Al Gore with the visual story by “re-tapping into his passion and shaking the political persona was all his own work.”

Note — the success of his presentation style is that he had ‘internalized all the key messages’.

Gore delivered the presentation over 1,000 times so he was comfortable with the content and didn’t over rely on his slides.

How do you prepare for presentations? What’s the best tip you have on overcoming stage fright?

Maeve asks on LinkedIn how we can use Google Wave to write technical documents. Well, the first consideration is that Google Wave is not designed as a tech authoring tool but for collaboration and ‘almost’ real-time information exchange. Saying that, it does offer many benefits if you need to plan/coordinate/review documents in a networked environment. Here are some ideas.

Where Google Wave Can Help You Write Document

If you look at the lifecycle of a technical document, you can see that there are several phases where documents (and diagrams) get reviewed, approved, edited etc – nothing to do with the actual writing, but all related to getting the document over the finishing line.

Most of my work is spent on the web, coordinating projects, often in different time zones.

Google Wave helps me with the non-writing activities, such as planning, scheduling, reviews, brainstorming, sign-offs, usability testing, interface design, videos. Most project communications is done by email but why not do it with Google Wave instead? Why stick with email?

Let’s look at a few places in the document lifecycle where Google Wave might move things forward

1. Business Case – Getting the business case completed is one of the first things I do way before we start any writing. How do we justify the expense/resources involved in writing this document? Is there a real need for this material? Writing the business case s Google Wave or Email? Email is fine but slow. Everyone has to respond (one by one) until you get final consensus. With Google Wave you can all pitch in and do it in a single session. Or, you can start the discussion, save the wave, and then come back to it. Try doing this with Outlook.
2. Project Plan – we’ve started to use Google Wave when discussing resources, costs, and getting dates with Dev, HR, Testing Depts. Google Wave v Email v Intranet? I now use Google Docs to maintain the project plans (usually in Docs but also in spreadsheet format. It doesn’t always have to be in Excel.)
3. Information Development Plan – this is the ‘project plan’ for documentation deliverables, e.g. which documents are, what file format do we need, estimated page count, start/end dates, team, technical resources. Again, this can be run through with the team and the project manager is one or more waves. Think of the time this saves v endless emails back and forth.
4. Status Reports – you can link to the ‘active’ status report on the intranet/Google Docs and use Google Wave to provide more detailed information. For example, if risks are identified in the status report, other members of the wave can join in the conversation flow and explain the root cause, shedding further light when/where necessary.
5. SMEs – instead of holding several workshops (or conf calls) setup a wave, get everyone online and explore the subject matter. Upload charts, diagrams, videos and whatever gets this reviewed in one sitting.
6. Reviews – right now, most of these are done in Microsoft Word (and that’s fine up to a point). We’ve done some test runs with Google Wave and managed to get the docs reviewed, re-written, and signed off in, more or less, the same time as we’d do with Microsoft Word.

BUT, this was our first time using Google Wave. Once we get over the learning curve, we’ll be able to get the documents turned around faster.

Remember, you can add videos and graphics to the wave.

• “What do you think of this user interface?”
• “What’s wrong with the nav bar? I didn’t understand your email.”
• “How can we change the workflow of this process?”

You get the idea.

When you can present text, video and graphics at the same time, then you can change the way you manage projects.

It doesn’t always have to be email. Status reports don’t have to be in Word. Give Zoho a spin. Reviews don’t have to be in Microsoft Word. Use Google Docs and see how you can use track changes and version controls.

People making Google Waves

• How I came to love Google Wave http://www.chrisbrogan.com/how-i-came-to-love-google-wave/
• Why Google Wave Sucks, And Why You Will Use It Anyway http://www.techcrunch.com/2009/11/26/why-google-wave-sucks/
• Google Wave Add-on for Firefox 0.0.3 https://addons.mozilla.org/en-US/firefox/addon/14973

Robert Scoble put it this way: “This service is way overhyped and as people start to use it they will realize it brings the worst of email and IM together: unproductivity.”

While Google Wave is not meant for technical writing it, try and see where/how it can speed up the overall documentation lifecycle, especially those areas where you need to connect with many people.

Use Google Wave to centralize these communications.

Emails tend to create information silos. Snippets you have to cut/paste into other documents (e.g. reports) so they have real value.

How will you use Google Wave?

We’ve touched the tip of the iceberg here. Where do you think it adds most value? How do you plan to use it to save time and speed up internal processes? And. what’s the real problem in getting people to start using it?