Testimonial – easily navigable, with understandable language and an accessible layout

I recently had the pleasure to work with Jason on a project for a new unit that I created. We had another writer work on a manual for my group, but the final product was far from what we needed.

I had a very brief conversation with Jason and he knew right away how to put together my document so that it was easily navigable, with understandable language and an accessible layout.

I learned a lot working with him and was so impressed with how quickly he was able to fix my document, which was almost 90 pages, but also how professionally he worked with me. The end product was better than I could have imagined and much more than I could have done myself. My team continues to use this document on a daily basis.

I highly recommend Jason for any writing project and look forward to the opportunity to work with him again.

—Erika Webster, Manager, Claims Business Support Unit, ICBC

Old Wine in New Bottles  — or — How to Write Effective Paragraphs

A document may be correct in every respect and perfectly formatted yet still be utterly incomprehensible to its readers. How is this possible? It comes down to the writing. If ideas don’t flow naturally from one to another, readers become confused and quickly bored. Sometimes the problem can’t be found within the sentences themselves, but on a bigger scale. Consider the following paragraph.

“The northern United States and Canada are places where herons live and breed. Spending the winter here has its advantages. Great Blue Herons live and breed in most of the northern United States. It’s an advantage for herons to avoid the dangers of migration. Herons head south when the cold weather arrives. The earliest herons to arrive on the breeding ground have an advantage. The Winters are relatively mild in Cape Cod.”

There’s basically nothing wrong with each individual sentence. Each is clear and concise, yet taken together they add up to very little. They fail to take into account how we put information together. We associate like with like; we make connections. If there are no connections, we either become bored or as often happens, we draw the wrong connection. Consider this old advertisement.

“We do not tear your clothing with machinery. We do it carefully by hand”

While the first sentence is clear. Even with the negation, there’s the strong verb “tear” promising what the seller doesn’t do. The second sentence is more ambiguous — it forces us to fill in the blanks (sometime causing hilarity). Exactly what is it that the advertiser promises to do carefully?

This is how our minds are wired. Whenever one sentence comes after another, readers need to see connection. The need is so great that if the connection is absent or unclear, the reader infers a connection where none was intended (as in the above example).

Sentences are joined by common ideas. If a reader is going to associate one idea with the next is succession, well then let’s give that reader the precise idea needed to draw the right conclusion.

A great way to do that is to structure your sentences so that each sentence progressively adds a new idea, which then becomes the topic of the next sentence. The technique is called old-new chaining. Start a sentence with a known concept. Then within the same sentence, introduce a new concept the reader doesn’t know, but which the reader is naturally going to make an association to the known concept. Once that connection is accomplished, the reader’s understanding is expanded and the unknown becomes the new known. Start the following sentence with that new known and use that new known to introduce another unknown concept. Continue until the topic is explained, thus ending the paragraph.

Here’s an example written with seeming effortlessness by a participant in a technical writing course I taught at BC Institute of Technology:

“This document provides a step-by-step guide for the novice wine-tasting party organizer. Most novice organizers are members of wine-tasting clubs. These clubs are usually formed by people who have been drinking wine together socially for some time. Club members have developed basic wine preferences—they know what they like, but not why. They want to acquire a descriptive wine vocabulary so that they can compare and discuss the attributes of different wines. They would also like to be able to recognize wines by taste. The purpose of the club is to provide a friendly, non-threatening setting where members can learn more about wine. With this in mind, club members take turns organizing wine-tasting parties.

Testimonial – Creating documentation to build upon

“Jason has done a great job structuring the documentation within Confluence and getting various pieces started for the teams to reference and build upon.”

—Matthew Rollo, Manager, Change Corporate Strategy, People & Culture, BCLC

Testimonial – Excellent at your craft

Jason, thanks for being a great technical writer. You were on many Annex Consulting Group contracts because you are excellent at your craft. I trust you will stay busy for many years to come.

—Stacey Cerniuk, President & CEO, Annex Consulting Group Inc.

Testimonial – Quick learner, easy to work with

I’m happy we had the chance to work together – and I agree, it worked out well – not least of all because you are a very quick learner and very easy to work with!

—Kim Lo, Senior Analyst, Underwriting Policy, ICBC

Testimonial – Depth in task-based documentation and structured authoring

Jason is a very experienced writer, with depth in task-based documentation and structured authoring. He is responsible, diligent, conscientious, and extremely easy to work with. I enjoyed working on his team very much and would welcome the chance to work with him again.

Jason was an important member of our team during a series of demanding and complicated releases of documentation related to regulatory changes to automobile insurance in BC. In the initial project, Product Reform, Jason joined the team responsible for converting reviewed Word documents into ICBC’s complicated DITA/XML toolset. To do this correctly (which Jason did) required mastery of information mapping and ICBC’s template structure.

For our second project, far less business preparation had been done, and the project itself suffered from a lack of business requirements and product definition. Jason took the bull by the horns and with intensive effort, managed to extract enough information from the SMEs to accomplish a successful release of a viable topic set.

Both projects required that “old” source co-exist with “go-live” source. Jason met the single-sourcing requirement using conditional profiles in DITA/XML.

—Lindsay Burrell, Procedures Analyst/Senior Technical Writer, ICBC

Testimonial – You did a fantastic job

You did a fantastic job communicating what the policy is, and distinguishing between “the program” and “facilities”.  It’s not exactly straightforward, but you totally nailed it.

—Kate, Senior Legal Counsel, ICBC





What’s your purpose?

What's your purpose?

What’s your purpose?

– or –

What’s the difference between a purpose and an objective?

Sometimes these terms seem synonymous, and often the term purpose is used solely to mean both, but the distinction between them in a document or training plan is key. The purpose is about the document and the objective is about the audience. In other words, “purpose” is what the document sets out to teach and “objective” is what the reader will be able to do as a result of that teaching.



“The purpose of this guide is to describe how to complete a customer claim.”

I once saw a purpose statement at the front of a guide that stated, “The purpose of this guide is to be a user manual.” The circular reasoning is obvious, and it’s easy to see how feature-focused this kind of planning is. The purpose is the story the document is telling; or put another way, it’s the point of this guide.



“As a result of reading this guide, the reader will be able to complete
a customer claim accurately to company standards.”

Writing an objective in technical writing is a thornier issue and unless you’re writing training materials, it’s something quite foreign. The reason for this is simply that the objective describes something about the consumer of the information. Often, technical writers are removed from their readers. Technical writers don’t have to stand up in front of a room of readers, but trainers do, so instructional designers (those who write training materials) are more familiar with writing objectives.

In a technical document, I’m one for a blended approach and stating both, even if it means that the objective is buried in a purpose statement.

Purpose + Objective = Purpose

The result is something like this:

“The purpose of this guide is to enable readers to complete
a customer claim accurately to company standards.”

Big whoop—I know—it’s not all that different, but by taking in both the document and its reader, the purpose statement becomes much more meaningful (it’s not filler at the beginning of a guide), and the reader can go back to the beginning and assess if that objective was fulfilled (or not).

Testimonial – I appreciate all you’ve done to contribute to our success.

Thanks for all your hard work converting topics from Word to Oxygen Jason. Everything published successfully for release 1.1 and I appreciate all you’ve done to contribute to our success.

—Brody Darough-Hardekopf, Senior Business Advisor, ICBC

Insurance Corporation of British Columbia (ICBC)

Role: Procedures Analyst (2018–present)

Need: To comply with new government-mandated changes to automobile insurance, ICBC needs to revise all of its policy and procedural material. Projects included Rate Affordability Action Plan (RAAP), Modernization of Passenger-Directed Transportation (MPDT – otherwise known as Car Sharing/Ride Hailing), Material Damage (new Collision and Glass Repair programs).


Working with business policy analysts and subject matter experts (auto insurance, healthcare, legal) to ensure readiness for province-wide rollout to ICBC’s internal departments and over 900 independent insurance brokers.

Tools used:

  • Darwin Information Typing Architecture (DITA)
  • Oxygen Authoring – XML editor
  • Information Mapping methodology
  • SharePoint
  • Jira
  • Confluence
  • Microsoft Office


  • hundreds of Oxygen Authoring reference, policy, procedure, and process topics
  • Conversation guides
  • many SharePoint adjuster strategy topics
  • Job aids
  • and more

Read testimonials about this position…