Posted on

How to Write Error Messages: Faster, Stronger, Better


Blame the cat, TV, or the neighbors if you want. The thing is: stuff happens. When it does, you need some way to fix it, pronto. Aren’t  I right?

This is where error messages can save you bacon.

No one thinks of writing an error message guide until it’s too late.

So, I’m telling you now, grasshopper: Get cracking on that Error Message Guide before it happens.

Why oh why do I need an Error Message Guide?

Here’s the skinny…

These guidelines will help you write error messages that are easy to update and useful for customers.

If you think about it, error messages are the first line of customer support. If written poorly, error messages increase technical support costs. They also frustrate customers, lose sales, and reflects poorly on your software, app, or website.

Errors are a fact of life in software development.

Every site has 404 errors.

Every software has bugs, known issues, and glitches.

Once we accept that, we can begin to help customers use our software, and help them get around the issues they encounter. If you think of it like that, the issue isn’t the error message it is our attitude to creating error messages.

Ok, let’s assume that we want to create really helpful error message, you know, the type we’d like to see if we got lost on a website, using an app, or trying to fill a form on an application.

What’s the purpose of an error message?

A well-written error message tells you, the user, the following:

  • What has happened
  • Why has it occurred
  • How it impacts you and
  • What you, the user, can do to prevent it happening again?

The error message must include enough information to solve the problem.

What is an error message?

An error message describes a problem that stop a user or system from completing a task.

What types of error messages are there?

There are four main types:

  • Errors
  • Confirmations
  • Warnings
  • Notifications.

If a message has different audiences, create separate text for users, administrators, and developers.

Why do we use the word error in error messages?

Isn’t part of the problem the word error? It’s assumed the user made the error. If you think about it, the problem is often the software, for example, it wasn’t designed to accommodate unexpected behavior.

If we see it like this, the error is on the side of the developers. If that’s the case, you don’t want to blame the user just because they entered 05122020 instead of 12052020 when entering a date. I tend to use 0512 whereas maybe you use 1205. Good software anticipates this and, where necessary, provides the direction the user needs.

Error Message Guidelines

Error messages should address the following, though not in this order:

  • Be constructive: tell me what needs to be done!
  • Be as specific and precise as possible.
  • Educate. We only read tech docs as a last resort. Knowing this, write error messages that educate and teach the user how to use the application. Nice examples always help.
  • Indicate that something has gone wrong, but then help the user understand what to do next.
  • Offer different levels of messages, some for beginners, others for advanced.
  • Provide direction. Instead of saying, “none in stock,” tell them how to find out when it’s back in stock. Is there some page, app, or contact number that can help them with this?
  • Save as much as the user’s work as possible. For example, allow users to correct errors instead of having to start from scratch.
  • Use a positive tone: avoid condemnation.
  • Use consistent grammar, terminology, and abbreviations.
  • Use consistent visual formats and placement.
  • Use terminology your audience will understand.
  • Use Plain English – plain in the sense that it is concise, accurate, and avoid any unnecessary words.
  • Use user-centered phrasing.

Error Message Mistakes To Avoid

Try to avoid the following:

  • Blame. Maybe the user did the wrong thing, for example, entered text into a field meant for numbers, so technically it is their fault. However, instead of saying this is wrong, bad, or illegal, state that this field only takes numbers and encourage them to try again.
  • Cryptic numbers. Error message 724 for example means nothing to the user. The developer may know what this means but she should refine the error messages to help the user, not her own team or others debugging the application.
  • Generic ‘catch-all’ messages. Determine the cause of the error and create an appropriate error message.
  • Jargon. What does syntax error mean?
  • Jokes.
  • Negative phrasing, such as wrong, bad, invalid, and illegal.
  • Red to indicate an error. Red looks terrible. It sends a warning that something is very wrong. Avoid where possible. There is an exception though. If the user is about to do something that could have DRASTIC consequences, then consider using red, for example, if they are about to format their hard disk and lose all data. Let them know this immediately and make it so obvious they can’t miss the warning sign.
  • Slang or abbreviations.
  • The word error in the title bar.
  • Anthropomorphize. Do not imply that the software has feelings or thoughts.
  • Terms that may be offensive in certain cultures.

How To Improve Error Messages

Ask yourself: how can I help the user solve their problem as painlessly as possibly?

One problem with most error messages is that while they indicate that an error has occurred, they don’t mention what steps the user should take to a) avoid this happening again and b) resolve the current issue.

  • Rewrite temporary error messages written during testing. Examples of these might refer to null pointer errors or issues with the class, objects, or interfaces in the code. None of this should be displayed to users when the product is finally released.
  • Many error message leave the user in a type of limbo unsure what caused the issue and, for example, how to recover data they may have lost if the system crashed.
  • If possible, create links to FAQ pages where users can learn more, download the necessary patches, or contact support.
  • Get the technical writer to write and enhance the messages. If you’ve no tech writers on your team, assign them to the person with the best writing skills.

How to Write Error Messages

  • Create a spreadsheet, for example, using Google Spreadsheets so you can share it online.
  • Add columns for the error message and the root cause.
  • Give each error a number so you can track them.
  • Establish an error message quality-control team.
  • Find best practices. Share with the team.
  • Create simple to follow writing guidelines for the error messages. Share examples.
  • Include error and information messages in the design phase.
  • Place the messages under source control.
  • Review messages during the development lifecycle.
  • Attempt to eliminate the need for messages.
  • Carry out acceptance tests.
  • Review and revise messages periodically.

Best Practices

You don’t need to use all of these all of the time, but they’re nice to refer to:

  • Avoid the word “bad”. Use more descriptive terms to tell the user what is wrong. For example, avoid messages such as “Bad size”. Instead, tell the user what criteria to use when specifying a size.
  • Avoid the word “please”. It can be interpreted to mean that a required action is optional.
  • Avoid UPPERCASE text and exclamation points.
  • Explain the solution to the problem. If it has more than one step, link to a Help page the explains the task in detail.
  • Insert descriptors before a term to clarify the meaning of the sentence. For example, “Specify ID when Detect is set to No.” should be changed to “Specify the ID parameter if the Detect option is set to No.”
  • State the problem in plain English. Explain what caused the problem. Use complete sentences.
  • Use active voice if possible.
  • Use passive voice to describe the error condition.
  • Use the Cancel button to stop an operation and close the message box.
  • Use the Close button to close a message box.
  • Use the Details button to provide more information about the root cause.
  • Use the Help button to provide more information about the solution.
  • Use the present tense to describe the conditions that caused the problem.
  • Write critical errors to an event log.
  • Write separate error messages for each known issue.

Microsoft’s Guidelines for Error Messages

When you write messages, follow these guidelines:

  • Avoid vague wording. Give specific names and locations of the objects involved.
  • Avoid “please.” It can be interpreted to mean that a required action is optional.
  • Do not refer to implementation details that are invisible to the user. For example, do not refer to the names of functions or objects in the program.
  • Avoid phrasing that will seem silly to the user, such as “unexpected error.”
  • Avoid using placeholder variables in the middle of a message. They are very hard to localize.


The name of the object file conflicts with that of another program in the project. File name: %s

Works did not find a match for this term.


You have named the object file with the name of another program in the project. File name: %s

The term you typed does not appear in this Works file.

Source: Manual of Style for Technical Publications

Example of IBM Software Error Messages

The following is an example of how IBM writes error messages. Notice the words and phrasing as well as how the alert categories are explained.

Error Message

There is no value specified for the User ID.


You must specify a value for the user ID.

Alert Category

Similar events are grouped in categories. The alert category is in the following format:

Severity – device component

Severity is one of the following severity levels:

  • Critical: A key component in the server is no longer functioning.
  • Warning: The event might progress to a critical level.
  • System: The event is the result of a system error or a configuration change.

Sample Oracle Error Messages

The following is an example of how Oracle writes error messages.

Notice the format of the error message:

  • ORA-00058 – error number for tracking
  • DB_BLOCK_SIZE must be string to mount this database (not string) – description of error message
  • Cause: what caused the error to occur
  • Potential reasons: note the use of the word potential in the following example.
  • Action: what steps need to be taken

For example:

Cause: The value of the DB_BLOCK_SIZE initialization parameter used to start this database does not match the value used when that database was created.

Potential reasons for this mismatch are:

  • Mounting the wrong database
  • Using the wrong initialization parameter file
  • The value of the db_block_size parameter was changed

Action: For one of the above causes, either:

Mount the correct database

Use the correct initialization parameter file

Correct the value of the DB_BLOCK_SIZE parameter

Sample Microsoft Windows Error Messages

The following is an example of error messages for Microsoft Windows XP:

When you try to install a program that uses the Windows Installer in Microsoft Windows XP, the program does not install, and you may receive an error message that is similar to one of the following error messages:

  • The Windows Installer service could not be accessed. Contact your support personnel to verify that the Windows Installer service is properly registered.
  • The Windows Installer service failed to start. Contact your support personnel.

Internal Error

This issue may occur when the Windows Installer files are missing or damaged.

To resolve this issue, use one or more of the following methods in the order that they are listed.

It then describes three different methods to resolve the issue.

Method 1: Reregister the Windows Installer

  • Quit all Windows programs.
  • Click Start, click Run, type msiexec /unregister in the Open box, and then click OK.
  • Click Start, click Run, type msiexec /regserver in the Open box, and then click OK.
  • Restart your computer.

Method 2: Remove the Windows Installer files

  • Quit all Windows programs.
  • Click Start, click Run, type msiexec /unregister in the Open box, and then click OK.
  • In Windows Explorer, rename the following files in the %systemroot%\System32 folder:
    • Msi.dll
    • Msihnd.dll
    • Msiexec.exe

Note: If you cannot rename these files, try to rename the files at a command prompt. To start a command prompt, click Start, click Run, type cmd in the Open box, and then click OK.

  • Restart Windows XP.

Method 3: Restart Windows XP in Safe Mode

  • Restart Windows XP in Safe Mode, and then retry Method 1 and Method 2 in the order that they are listed.

Finally, it provides more information about how to restart Windows XP in Safe Mode, by suggesting you read the following article number to view the article in the Microsoft Knowledge Base: 316434 How to perform advanced clean-boot troubleshooting in Windows XP

Sample Google Chrome Errors Messages and Warnings

The following is an example of error messages from Google Chrome. Note the tone, language, and phrasing.

You might see an error message when a download fails.

It will show up on the download bar at the bottom of your browser screen or in the download page that opens.

Note the use of the phrase ‘show up’ instead of display or appear. Likewise, the use of download in lowercase instead of uppercase.

If something you’re about to download could cause problems, Chrome also warns you.

Common warnings for harmful or unwanted programs

Certain downloads can cause viruses, leak your private data, change your browser and computer settings, or add unwanted extensions or toolbars to your browser.

Chrome warns you of potential issues:

Malicious download warning: You tried downloading malware.

Uncommon download warning: You tried downloading an unfamiliar and potentially dangerous piece of software. You should only download programs from sites you trust.

Unwanted software download warning: You tried downloading a deceptive piece of software. This program, disguised as a helpful download, may actually make unexpected changes to your computer.

Virus detected: Antivirus software detected a virus. Your downloaded file may have a virus and, as a result, the file you attempted to download was removed by the Windows Attachment Manager.

In the above example, note the direct ‘you’ phrasing, the relaxed tone, and the use of may and might to suggest the root cause.

This combination of tone, phrasing, and conciseness is encouraging to the reader as it avoids blame.

You feel whoever write this Help page is on your side.

PS: Get your error message template here.

Posted on 10 Comments

5 Ways To Differentiate Yourself as a Technical Writer


Feeling ignored? What’s that? No pay respects the hard work you do as a tech writer.

Sad, isn’t it? Very sad…

Ever wonder why?

Ever wonder what you need to do about it? Hmmm?

Tom Peters says, “the value of services will continue to fall” and that the only way to survive is to differentiate yourself from the competition.

Is this true?

How do you as a technical writer make yourself stand out from the crowd? If you don’t, what impact could this have on your career?

How to Differentiate Yourself as a Technical Writer

Here are five suggestions to do this:

  1. Video Blogging – use your Camtasia skills to create videos that show how products work. Cisco is doing a great job in this area. They gave flip cameras to the IT people and encouraged them to make short, snappy videos that show how to use their hardware, networks, and systems. Which would you prefer? To read 20 pages or watch a 3 minute video?
  2. Screencasting Training – now that you know how to make the videos, why not use this to teach others to do this same. Position yourself as a screen-casting expert, setup the blog, get involved, and show others how this works. FWIW there is a very active video marketing group on LinkedIn ( that you may want to join.
  3. Web-based Training – if you’ve spent years writing guides, you must have developed an in-depth knowledge of 2 or 3 fields. See which of these are most in demand (Google searches and forums will be a starting point) and then develop training modules that you can present online. does a great job in offering training over the web. Sign up with them and see how it works.
  4. Social Media Writing – you know how to write, right? Well, most people don’t. As Social Media continues to explode leverage your writing skills and show (“the benefit o f communicating well on Facebook is…”) others how to get their message across on these Social Network.
  5. Business English – the upside of all these jobs getting shipped to India, China, Brazil is that their Management teams want to do more business in the west. How can you help them write better reports, communicate more clearly, protect them from being misunderstood – you get the idea!

These are just five ways you can stand out from the crowd and position yourself as a specialist. My suggestion is to look at who is doing this right, e.g. Debbie Weil, and study them diligently. Then develop an action plan and start getting the rewards you deserve.

What other careers can you think of? Is it possible to differentiate yourself as a Technical Writer? How would you do it?

PS: Tom Peters is here: Thriving on Chaos: Handbook for a Management Revolution

Posted on 5 Comments

How I Set Priorities: Get Things Done

Ross Kimbarovsky asks: “How do you decide what to do next? Should you write a blog post? Answer emails in your inbox? Make several sales calls? Spend time on Twitter? Or should you call a team meeting to discuss a customer problem?

Ross adds that successful people are successful in part “because they are good at setting priorities. And while there are many different ways to set priorities, I wanted to share how I set my own priorities.”

Getting Things Done – How I Set Priorities from Ross Kimbarovsky on Vimeo.

Getting Things Done: How I Set Priorities

For me, it’s all about planning. And planning, by extension, is decision-making.

  1. Start the night before. At the end of the day, I review what I’ve done. It takes only 5 min. What did I forget to do? This goes to the top of next day’s schedule.
  2. I get up around 5.30 am to get a head start and beat the kids getting up.
  3. I ignore the emails for 1 hour. Nothing is that urgent.
  4. I plan my day – what is critical goes first, then what I need to do and the rest can wait
  5. When all of this is done, I check emails, watch cats doing ninja tricks and what not
  6. I have a super quick review at 11.45 before lunch
  7. I have a super quick review at 2.45 to make sure I’m still on track.

All this is done on my pad. Writing it down seems to make it more permanent. I like to cross things off when I’ve conquered a task!

Small rewards as we go along. Nothing fancy.

Closing my inbox during the work day was/is the biggest way to save time. And, of course, turn off the phone.

How do you organize your day?

Posted on

Technical Writing Projects: How to Create Doc Plan

How long will it take to write those documents? How many writers will you need to get it completed? How much will it cost? What’s the delay?


Any of this sound familiar? If you’re new to managing a tech doc dept, you’ll need to find ways to estimate the amount of time, effort, cost, and contingencies that need to be factored into your projects.

  1. Specifications – are the specifications complete? Identify who can confirm if the specifications are complete, signed off, and whether they are likely to change. Working on incomplete specifications is like trying to document a moving target.
  2. Style Guide and Reformatting – what amount of your time will be spent updating the content to align with your style guide, if you have one? This has to be considered if you plan to peer review or update text from another colleague. Re-writing text to align with guidelines and standards is very time-consuming.
  3. Writing – the actual writing may only take 20-30% of your time. The rest is consumed in gathering information, communication with team leads, getting clarifications, and other tasks related to the subject matter.
  4. Peer Review – ideally, everything you write should be reviewed by another team member. If not, get a business analyst or developer to check the accuracy of your material.
  5. Content Delivery – it’s not unusual for writers to write in, for example, MS Word and then copy/paste it into wikis, RoboHelp, or FrameMaker. Why? Two reasons: One, because it may be necessary to deliver the same content as a PDF, on a wiki, or Online. Two, because there may not be a simple way to export the content from one authoring tool to the next, eg FrameMaker to RoboHelp, without tinkering with styles, formats, layout and so on. Many writers prefer to write the raw text in Word and then format in their respective authoring tools. Choose whatever approach is most productive.
  6. Document Impacts – when you update a piece of content, is there an impact of other documents, for example, other installation guides or releases? Does conditional text need to be applied for specific releases?
  7. Access to working software – sometimes you have to get started without having working software in front of you. While this is far from ideal, it’s not unusual to have to write with the understanding that the GUI may change, for example, new fields may be added, and to allow for these in your estimates. However, this stopping and starting will eat up your time as you’ll need to check each release if and where they are new changes and document these.
  8. Access to developers and subject matter experts – while you may be able to understand some parts of the software, for example, how the GUI works, if you need to document aspects of the system that occur ‘under the hood’, such as Java classes, servers, databases etc, you may need to clarify things with the developers or domain experts. Factor this into your workload as getting demos, answers to questions, and reviews all need to be considered. If these people are not in the same office, allow for scheduling meetings and the extra time this may take.

Remember, there is a risk if you start to document too early in the development process, and the specifications and requirements change due to changes in the budget, timelines and scheduling, your estimates will be affected. Allow for this when preparing estimates and give yourself some bandwidth for known unknowns.

Posted on 2 Comments

12 Steps To Getting Started as a Consultant

Most people think it’s difficult start a career as a business consultant. I used to think the same in my early 20s when I started in IT. In retrospect, I should have made more efforts to establish myself as a consultant earlier; the benefits certainly outweigh the downsides. As luck would have it, I was forced into a consultancy role when I lost my 9-5 job. Time to learn to hustling and bring in business. Harvard Business Review refers to it as The Hustle Strategy. More on that later. Continue reading 12 Steps To Getting Started as a Consultant

Posted on

How Technical Writers Can Move Further Up The Food Chain

Do you feel loved? Many technical writers feel unloved. They feel they don’t get the respect they deserve. I hear this on LinkedIn and Facebook: “people don’t respect the work I do.” Well, if that’s the case, here are a few ways to get more respect and move into a more rewarding career. Continue reading How Technical Writers Can Move Further Up The Food Chain

Posted on 12 Comments

Who Makes More Money – Technical Writers with Language or Technical Skills?

Which of these would you hire to join your Technical Writing Dept? Someone with great writing skills but little technical knowledge or, for example, a Computer Science graduate with deep technical knowledge but average writing skills?  We’ve been talking about this on LinkedIn and here are some thoughts.

Why Writing Skills Are More Important

  • Technical writing is about writing.  Words are the foundation upon which the rest is built.
  • If you don’t have the writing skills, then regardless of how well you know the application, you can’t explain how it works.
  • Your ability to drill down and describe complex functions may be beyond your grasp.
  • To resolve this involves arranging sessions & workshops with developers, IT architects etc, all of which cost time/money.
  • If writing skills were not necessary, programmers could write the user guides! Ever see a well-written user guide from a 22 year old Java developer? There are exceptions but…
  • Technical writing is about communication. Technical writers are trained to interview people and extract the relevant information.  Of course, listening skills are not exclusive to technical writers but many (that I know) feel they grasp the importance of this more than others.
  • Writing skills give you the tools to communicate – and to help/teach others to communicate.

FYI – One of the trends I see in Tech Comms, is the changing role of the Technical Writer / Technical Communicator into an educator, facilitator, and becoming the central point of contact for technical information distribution (i.e. technical information coordination).

The counter argument is as follows.

Why Technical Skills Are More Important

  • Technical knowledge is the starting point. You need to know how the system works, otherwise all the writing skills in the world may be of little use. If you don’t know what it actually does, what can you begin to write?
  • Most ‘non-technical’ technical writers (e.g. graduates with English degrees) waste/take up developers’ time asking questions about how the application works, instead of actually generating content. While there is some leeway here with new technologies, developers have their own deadlines and can’t be expected stop coding to explain the innards to the application.
  • Those with technical skills can hit the ground running – it’s the responsibility of the Technical Editor to refine the text.
  • Those with technical skills know which questions to ask. As they understand the application/industry/codebase they can ask the hard questions that ‘non technical’ writers would not see in the first place.

Which would you hire?

If you were running a technical writing dept, which type of person would you hire?

A technical writer with strong technical skills, but prone to the occasional typo, or someone with perfect grammar, sound writing skills, but low on technical knowledge?

PS – you can connect with me on LinkedIn here –

Posted on 3 Comments

How Advertising in User Guides Could Work

Putting advertising in user guides may seem rather flaky at first, but it could work. Here’s why. One of my ‘pet projects’ is to connect the lines between Sales and Technical Documentation. To me, they both serve the same purpose. Serve the customer. While they both start at different points, the end goal is the same. Unfortunately, these two departments rarely work together. Let’s take a look at how we can fix this. Continue reading How Advertising in User Guides Could Work

Posted on 15 Comments

User Guide vs User Manual – which is right?

Let’s say you’re setting up a new Tech Docs Dept.

You need to create new guidelines, style guides and naming conventions.

Should you call the user ‘documents’ User Guides or User Manuals?

Which one is right?

I was asked this question by a colleague in India who is setting up a Technical Publishing Dept in Bangalore.  He wants to go with user guide—me too, actually.

  1. When I worked in the UK, it was (mostly) referred to as a User Manual.
  2. Whereas in the US, it was a User Guide. I think the Americans (and me!) like things to be short and to the point. Guide is just that little bit quicker to write, especially when you’re creating MS  Word templates.

Saying that, there is no right and wrong, but I did a little fact finding first.

What Google says about User Guides

I searched Google and came up with these results.

  • 15,600,000 for “user guide”
  • 10,700,000 for “user manual”
  • 5,210,000 for “user’s guide”

What surprised me here was that User’s Guide was so widely used. I’ve always found this a bit annoying. I just don’t like apostrophes, I guess.

Top 5 Most Popular User Guides

A quick check on the most popular user guides showed the following. Not what I expected.

IBM Technical Documents

Next, I checked IBM and Microsoft  to see what term they used.

  • 15,324 for user guide
  • 1,047 for user manual

So, they prefer user guide. Though, you’d think they’d make this mandatory. Of course, it’s not easy when you have offices in every corner of the world, so let’s cut them some slack.

Microsoft prefers User Guides too

The folks are Redmond were more consistent with

  • 1.8 million for User Guides and only
  • 73k for User Manuals

And, to be fair, many of the user manuals were actually guides when I checked. Someone check that search engine!

Is Apple different?

Yes, of course.

Apple prefers the term User’s Guide. Like I said, I never bought into this. I prefer short, snappy titles. We don’t call them System Administrator’s Guide, do we?

Well, of course, some do.

Things to consider when naming your documents

  • Avoid obscure or unique terms for your documents. Use industry standard terminology.
  • Ask your target audience what they expect.
  • Create a Style Guide or adopt one, e.g. the Microsoft or IBM style guide.
  • Develop a naming convention, e.g. a structure approach so that all documents are named, filed, and indexed correctly.
  • Develop a numbering convention. Show people how to number documents, for example, when to go from 1.1  to 1.2 and when to go from 1.2 to 2.0.
  • Be consistent.
  • Be patient when they get it wrong.

My career really began to take off when I saw myself as an ‘enabler’ rather than a writer. My identity of who I was changed from a guy who cranked out docs to someone who helps others get their projects done.

People want to learn, do your best to help them get there.

What do you think? What’s the most practical way to name documents and setup a new Technical Writing Dept?

Posted on

How to Write a Target Audience Questionnaire

Creating a training plan? Before you do this, you need to step a step back and work out what your colleagues need to learn. Continue reading How to Write a Target Audience Questionnaire

Posted on 8 Comments

How To Write Technical Documents Faster

What to know how to type faster and get those documents out the door quicker? Most people don’t know what the AutoCorrect feature in Word really does.

Most people think it’s there to correct the odd typo and clean up your document AFTER you have written it.

That’s true but…

I use to correct the document AS I WRITE and to enter longs strings of text automatically.

Why bother?

When I write user guides, for example. I use a similar structure for the intro, bullet lists and instructions.

Instead of writing, ‘follow these steps’, I type onto the page in Word the letters fts.

Word then automatically writes, follow these steps: on the page.

Do you see how useful this can be?

You can also use it to o automatically detect and correct typos, misspelled words, and incorrect capitalization. It’s very powerful when you look into it and has saved me 100s of hours of manual typing.

Another example?

When I type ar1, AutoCorrect replaces it with “Annual Report.”

Or if you type ‘Teh Executrie summary states’ with a space, AutoCorrect replaces what you have typed with “The Executive Summary states.”

You can also use AutoCorrect to insert symbols, such as copyright symbols.

Note: Text included in hyperlinks is not automatically corrected.

So, how can I do this?

To autocorrect your Word Documents, follow these steps:

1.a In Word 2003, click Tools, AutoCorrect Options.

1.b In Word 2007, click Start, Word Options, Proofing and then the AutoCorrect Options.

2. In the Replace box, type a word or phrase that you often mistype or misspell – for example, type Micorsoft.

3. In the With box, type the correct spelling of the word – for example, type Microsoft.

4. Click Add.

Add a few more! Go on!

Spend 15 min here and add in shortcuts for words, sentence and strings (e.g. Please follow these steps: etc) you use regularly.

What other tips do you know to write documents faster?

Posted on

How to Study Technical Writing Online

Irish TeahouseThe University of Limerick, Ireland offers an excellent online course for those who want to study technical writing at home.

This university has a pretty amazing campus, specializes in the Arts and provides a conveyor belt of freshly-minted technical writers to Microsoft, Google and IBM in Ireland. It’s one of the few universities in Europe with a specialist degree in Technical Communications. Continue reading How to Study Technical Writing Online