Rate and improve tech comm with the Net Promoter Score

You can use the Net Promoter Score to rate and improve technical communication – but it works best on the scale of corporate content for which the score was designed. Here’s why and how.

The Net Promoter Score (NPS)

The Net Promoter Score measures customer loyalty and satisfaction with a company or offering.  It boils down difficult issues with perceived quality to a simple question:

How likely are you to recommend our company/product/service to your friends and colleagues?

Usually, the answers are ranked on a scale from 1 (highly unlikely) to 10 (very likely). You distinguish the percentage of respondents in three groups:

1	2	3	4	5	6	7	8	9	10
Detractors						Passives		Promoters

• Detractors are people who replied with 6 or lower.
• Passives are people who rated your offer as 7 or 8.
• Promoters are people who answered 9 or 10.

The NPS is the percentage of promoters minus the percentage of detractors: If 20% of your customers are promoters who really like your offering (and answered 9 or 10) and 30% don’t think too highly of it (and answered 6 or lower), then your NPS is 20-30 = -10. Generally, an NPS  above zero, indicating more promoters than detractors, is considered a good thing…

NPS for tech comm?

So how can we apply that score to tech comm? Are customers loyal to a help system? Are they likely to recommend it to friends or colleagues? Probably not in isolation of the described product.

There don’t seem to be a lot of ideas “out there” that connect NPS to documentation, but one article by JoAnn Hackos does: Influencing the Bottom Line: Using Information Architecture to Effect Business Success.

The key to turning the NPS into a useful tool for documentation is to take the scope from the NPS, not from the documentation! Hackos shows how we can relate the NPS to corporate and product content as a whole. This includes tech comm, but also marketing and sales content. This is what drives the customer experience which the NPS reflects. And it takes improvements in the corporate-wide content and its information architecture to increase the NPS.

Hackos describes a company which found that content contributed to the low NPS:

… senior management became advocates for significantly improving content quality. That meant changing the relationship between the technical authors and the product developers, requiring that information architects establish close relationships with customer support and training, and redefining the type of content that would be delivered to customers in the future.

– Sometimes, tech comm can adopt management tools to their purpose and scope, but with the NPS it seems most feasible to plug in to the corporate use of the tool.

Does this make sense? Can tech comm benefit from NPS and improvement initiatives? Or is that a hare-brained idea, and we should really stick to key performance indicators suitable for tech comm?

Advertisement

Tech comm conferences too far, too costly?

European tech writers who don’t have the time or the money to attend a tech comm conference can still get a lot of knowledge and networking by attending the tekom Europe Roadshow – right in their backyard, comparatively speaking!

The tekom Europe Roadshow puts on one-day events which are easier to get to from many places around Europe and waaay cheaper than full conferences. They bring together professionals from the region for presentations, discussions and networking.

Find the roadshow event nearest to you:

• Paris, France: Monday, September 8
• Ghent, Belgium: Wednesday, September 10
• Eindhoven, Netherlands: Friday, September 12
• Copenhagen, Denmark: Tuesday, September 16
• Warsaw, Poland: Thursday, September 18
• Istanbul, Turkey: Monday, September 22
• Bucharest, Romania: Wednesday, September 24
• Vienna, Austria: Friday, September 26

This year’s topic is:

TechComm Workflow & Media Production
Integrate Intelligent Media Production in Your TechComm Workflow

But even if that is not your professional focus, it might still be worth going for the contacts.

For more information, visit the event web site.

(Full disclosure: I have spoken at an early precursor of the tekom roadshow and think it’s a brilliant format, but I’m not involved with this event series.)

Why a content spec saves you time and money

A content specification will save you troubles, time, and money, especially when you’re not the lone writer on a documentation project. It will ensure that you offer your users consistent and holistic documentation across a team of writers.

A content specification is a list of all topics to be created which ideally maps planned topics to requirements and/or designs to ensure comprehensive and complete documentation. It usually comes in a table with one row per topic, listing:

• Topic heading and/or file name
• Topic type (concept, task, reference, or whatever else you may use)
• Topic owner
• Writer (in case writers may be different from topic owners)
• Reviewers (for example, subject-matter experts)
• Date ready for review or for post-review editing (depending on your workflow)
• Mapped deliverables (where the topic appears, for example, a certain user manual, the online help, etc.)
• Time estimate (how long will it take to write the topic, optionally, including review)
• Documentation task type, to help you estimate time:
  • Create new topic
  • Major rewrite of existing topic
  • Minor fix or addition to existing topic

Without it, you risk delivering a bunch of topics with gaps in some places and overlaps in others. You can still string them together, but no overview topic can convey a coherent content experience, if you didn’t plan for it and bake it into the topics and their structure.

So a content spec is a blueprint of your documentation project, just as you would create one before you start building a house – or design any kind of experience.

Yet content specs often elicit negative reactions…

“Oh, but we’ve managed without one so far…”

Many tech writers I know are very competent, and a few are lucky to boot. Considering all their projects with more than, say, 50 topics which didn’t use a content spec, I’d bet half of them are incoherent (“organically grown” is an oft-used euphemism).

The cost doesn’t stop at poor user experience. Such examples are also more difficult and more expensive to maintain, especially if you have overlapping topics and don’t remember to update both of them…

“Bah, reality eats specs for lunch…”

To an extent, yes. But on the whole, reality is an orderly patron. In my experience, the final documentation reflect the approved content spec in up to 80% of the topics. An average 10% of the topics get added during the writing, where concepts or prerequisite and auxiliary procedures are found missing. Another 10% of the topics get reorganized because the initial content spec misunderstood something, or because content simply makes more sense somewhere else.

“Even if, we’ll fix it later…”

Yes, you can. But once again it’s very expensive. Remember that the list of topics is only one result of the content spec. Their structure is another. Finding that a structure by workflows is inferior to a structure by, say, instrument, requires not just re-ordering topics, but re-writing a lot of them.

You can avoid this by drawing up a complete content spec before you write a single topic and getting it signed off by the key stakeholders, so they know rather well what documentation they will get. The 20% deviations mentioned above are usually justifiable, if they conceivably improve the deliverables.

– Given that content specs are a big help in creating and maintaining efficient and effective user documentation, I strongly recommend using them. If you have any experience with or without content specs, I’d love to hear it.

What’s new in MadCap Flare 10, the nitty gritty

Flare 10, the annual major release of MadCap’s flagship Help Authoring Tool, includes several major enhancements that make Flare easier and faster to newcomers and editors of marketing content. And many smaller enhancements target the hardcore techcomm heavy users. The well-balanced improvements testify that MadCap listens to many of its users.

Today, I’ll focus on the enhancements that I enjoy most – many of them are smaller improvements for heavy-duty tech comm users with large projects and many topics. (An earlier post covered the more obvious strategic enhancements.)

• Improved build times are probably the most crucial enhancement for us. We have some crazy large projects, and we’re happy to see that build times for web help and PDF alike decreased on average by 10 to 30%. Apparently, Flare 10′s re-engineered build process causes more read/write operations. That means a fast hard-disk drive with, say, 7200 RPM or a solid state disk help you to really benefit from the improvements. (If you don’t know your RPM speed, find your HDD model ID in Windows’ Device Manager, search the web for that ID and you’ll find the RPM speed as well.)
• Robustness is improved with a Crash Reporting System. Given our large projects, Flare could be really slow at times and occasionally crash. I don’t recall ever losing any data, but it was still unnerving to see Flare disappear suddenly. I like that Flare 10 has better exception handling and captures a lot of run-time errors with an error dialogue.
• Customised project export allows you to tailor the content you share with other writers, translators or MadCap support. You can export projects not just as a whole, but also by selecting a target, a set of conditions or even file tag settings. For example, you can select a target and export that (along with the target’s conditions applied) to your translator. I use file tags to track topic status and translation language – and I like that I can export complete, stand-alone projects which contain only the relevant topics.
• Customised review packages benefit from the same restrictions, and we can select a target or apply conditions to collect only relevant topics. Oh, and topics in a review package now automatically bring along the snippets the link to which is a nice, intuitive touch.
• A Find and Replace widget in the XML Editor lets me find expressions in the active topic much faster.

• Drag-and-drop for conditions and variables makes it easier to select these elements which are now listed individually in the Project Organizer window and drop them into topics where I need them.
• Apply conditions in the XML Editor. I have several “dimensions” of conditions, such as print vs. online and version A vs. B. And sometimes, I lose track whether I have all scenarios covered. This new feature makes it easier and faster to see when I have content missing for “print + version B”, for example.

• File navigation improvements benefits especially users who have a lot of topics and a lot of topic reuse.
• Find and Replace in Files has been revamped to offer more options for tailored results. You can now search:
  • In the whole project which now includes files in the Project Organizer.
  • In any given folder.
  • In files by name, for example, you can search *.flsnp for all snippet files or t*.* for all task files, if you adhere to such a file convention.
  • For whole words which omits partial matches in longer words.

  You can now also save search results in a CSV file which is helpful if you need to work on results over a longer time.
  Note that Replace All has become less transparent! Previously, this function would open all files with matches, apply the replace, mark them with the “edited” asterisk and save them. In Flare 10, Replace in All Files will silently replace matches in all files currently not open. This is much faster, but there’s no asterisk, no undo, and you don’t even see the replace.

• Word count reports per topic and project. Many of my topics get translated, and our translators need to know how much I’ll send their way. With the new word count reports, I can give them an indicative estimate a few days before I finalise my work and send it off. The Report Editor in Flare 10 now has a Content Files > File Word Count report that counts each file in the Content Explorer, whether it’s an actual topic or a snippet or a template:

There’s also the Project > Statistics report which counts all words in a project – which is especially useful in connection with the customised project export mentioned above.

• Locate in TOC has gotten better. This function finds the selected topic in a table of contents. I use this a lot as I switch back and forth between the back-end topic structure in the Content Explorer window and the users’ view in the table of contents. I can now right-click a topic in the Content Explorer and go straight to Locate in TOC without going through the XML Editor or the Link Viewer. This makes my navigation even faster.
• File preview data at the bottom of the File List, Project Organizer and Content Explorer windows shows details of the selected file. First are the file name, which is redundant, and file type, which I usually know, so that is not very useful yet. The second column shows Date modified which can be helpful. But with long-ish file names, I never see the second column in the narrow, docked windows. So this is a good idea with questionable results. I’m also worried that it will slow down navigation in folders with lots of files, but I have no proof for this.
• Searching in source code now gives faster access to the topic in the XML Editor thanks to an added button.

For more information, consult these MadCap resources:

• The product web page
• The 8-minute video where Deadheads can try to spot a favorite piece of Grateful Dead stage banter in one of the sample screens…
• The 300+ page What’s New Guide in PDF
• The list of customer-reported issues that were addressed, from MadCap’s knowledge base
• The Flare 10 system requirements from MadCap’s knowledge base

What do you think are the most impressive enhancements in Flare 10? And where have they come up short?

What’s new in MadCap Flare 10, the hip parts

Flare 10, the annual major release of MadCap’s flagship Help Authoring Tool, includes several major enhancements that make Flare easier and faster to newcomers and editors of marketing content. And many smaller enhancements target the hardcore techcomm heavy users. The well-balanced improvements testify that MadCap listens to many of its users.

Today, I’ll focus on the more obvious strategic enhancements. A second post covers the enhancements that I enjoy most – many of them are smaller improvements for heavy-duty tech comm users with large projects and many topics.

Out with the geek

Many major changes aim to make Flare more attractive and easier. For the longest time, Flare carried the reputation (some say: stigma) of a steep learning curve. Flare 10 goes a long way towards flattening that curve to help you get going faster. In a way, it means Flare has been de-geekified – and I’m sad to say that the nicely geeky propeller hat logo went into hiding as well.

• The new Start Page offers new output templates as soon as you open Flare to get you started:

The new templates mainly support the recent trend of merging technical and marketing communications. They offer formats such as product brochures from 3- to 6-fold layouts and slideshows. I rarely create new projects from scratch, so this isn’t for me. I mainly need the Start Page to re-open previous projects which I can still do.

• Support of desktop publishing is probably better than ever, thanks to the improved page layout editor and the new support of Open Type fonts. Encroaching on desktop publishing products such as InDesign by rival Adobe, Flare has some strong arguments with its ability to reuse content in tech and mar comm. Since I don’t use DTP products and don’t create mar comm, I cannot judge how convincing Flare ultimately is in this arena.

In with the hip

Two enhancements in online output benefit tech comm and mar comm alike.

• Slideshows present a gallery with horizontal page-by-page navigation as opposed to vertical scrolling:

Slideshow pages can show images, videos, workflow stages, etc., along with descriptive captions and auto-play support. Thumbnails or bullets aid navigation. I really like the slideshows and expect to use them mainly to illustrate or guide users through multi-step workflows. I can also imagine drilling down from a process overview to the individual stages on slideshow pages.

• Responsive HTML 5 output ensures that output resizes automatically to fit mobile and tablet devices, see above. We had entertained the idea of creating separate EPUB targets for tablets, but the flexible responsive HTML5 output is of course much more convenient. It’s another good reason for us to move to HTML5 soon.

For more information, consult these MadCap resources:

• The product web page
• The 8-minute video where Deadheads can try to spot a favorite piece of Grateful Dead stage banter in one of the sample screens…
• The 300+ page What’s New Guide in PDF
• The list of customer-reported issues that were addressed, from MadCap’s knowledge base
• The Flare 10 system requirements from MadCap’s knowledge base

What do you think are the most impressive enhancements in Flare 10? And where have they come up short?