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?

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!

tekom Euurope Roadshow logo

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.

Find and Replace widget in Flare's XML Editor

  • 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.

Button applies conditions in XML Editor

  • 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:

Word Count Report in Flare 10

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:

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:

Flare 10 Start Page

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:

Flare 10 slideshow example

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:

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

Top 4 reasons that make MadWorld 2014 unique

Four unique reasons make MadWorld 2014 possibly the best tech comm conference you can attend this year. (Disclosure: I’m a happy MadCap Flare user and will speak at MadWorld 2014.)

MadWorld 14 conference banner

MadCap’s second annual user conference takes place in the Hard Rock Hotel in San Diego, CA, on 13-15 April. It’s featuring not just MadCap’s technical authoring products, but tool-agnostic sessions on DITA, content strategy, professional development, and more. But I think you’ll get the most out of it if you are already using MadCap products or at least very close to doing so. If you are, here are my top 4 reasons that will make MadWorld uniquely useful.

1. Immediately applicable insights

Whether you are relatively new to MadCap or a veteran user, you can pick up helpful tips and relevant advice in sessions “Yeah, Flare Can Do That” and “Ride the Lightning (Talk)”. If you’re stumped for tactical or strategic decisions, you’ll find answers in “Going Solo: Best Practices for the Solo (Flare) Artist” and “We Built This City: Building a Scalable Architecture for a Flare Project”.

Because you know the tools and MadCap knows our tasks, MadWorld eliminates one of the most common complaints of professional conferences: Not quite relevant content. Instead, you can probably find an insight to apply back home in every session. No more “What happens in Vegas, stays in Vegas”! Plus, it’s San Diego.

2. Community networking and support

At MadWorld, you can plug in directly to MadCap’s dedicated and supportive community of users. Many of us folks who help each other on MadCap’s user forum or on LinkedIn will be there. Recently, regional user groups have sprung up in North America and even Europe as MadCap users realise the benefit of a more personal network.

You can hook up with other users to discover what they do with Flare and what ways they’ve found to tweak Flare. That includes the speakers who are regular users, too. Meet them over at MadCap’s blog where they share their expectations and their favorite three songs. I’m looking forward to meeting everyone and to share my experiences – and favorite songs!

3. Prime support included

MadWorld offers personal support from all the guys and gals we might otherwise just know from support emails. I’ve met MadCap staff at other conferences and found them incredibly helpful. They answered any question I threw at them. It felt like free, unlimited access to the proverbial soda fountain. MadWorld’s Hospitality Lounge by comparison is like an open door to the soda factory. I for one plan to bring a couple of crazy projects and indulge… 🙂

4. San Diego in the springtime

Yes, it’s been snowing and raining a lot and in unexpected places, too. But not in San Diego. Not for a looong time, as Jennifer from MadCap reminds us:

So I expect spring to be in full swing by the time we get there. Add to that the Hard Rock Hotel in the Gaslamp Quarter, the world-famous zoo and the beaches, and I start to sound like a tourist ad.

————————–

To sum up, I look forward to MadWorld, a conference with boot camp intensity and summer camp fun!

P.S. I will speak in the tool-agnostic track on cognitive foundations of tech comm:

  • You’d Better Recognize! Pattern Recognition For Technical Communicators, on Mon, 14 April, 11:05 am
  • Addicted to Meaning: Mental Models for Technical Communicators, on Tue, 15 April, 1:30 pm

And I’ll be on board for the round of lightning talks on Tuesday at 10:55.

Update, 10 March: techwhirl lists 5 Reasons to Attend MadWorld 2014, citing a total of 61 pieces of evidence!

Running lightning talks or Pecha Kucha

Lightning talks (or their siblings Pecha Kucha and Ignite talks) can be great fun. They’re basically presentation karaoke: You avoid death by PowerPoint – instead you get the occasional train wreck when the slides get away from the presenter. But usually, the giddiness of information overload in 5 to 7 minutes is very stimulating!

It just takes a little planning to make sure there’s room for the spontaneous energy to emerge. Here’s what makes lightning talks succeed, in my experience:

  • Stick to the timeframe. For example, every speaker gets exactly 5 minutes to show exactly 20 slides where each slide is automated and timed for exactly 15 seconds. (Pecha Kucha uses 20 seconds each.) Now, this sounds a bit counter-intuitive to squeeze hi-energy lightning talkers into a tight format, but scrupulously sticking to it is essential to keep up the energy for the audience. Speakers don’t get to control the slides – which is the imminent danger and spice of every lightning talk! 🙂
  • Figure in a bit of overhead time to explain the concept to the audience and to move from one speaker to the next. So for a 45-minute session, plan 6 talks or 7 at most.
  • Have an MC facilitate the session. He or she explains the format, hands over between speakers and leads the crowd in applause, cheering, jeering, whatever seems appropriate.
  • Curate the content, if necessary. Not every topic lends itself well to the restrictions of a lightning talk. Case studies and project stories of limited complexity usually work very well, as do Top 20 lists.
  • Go for lightning flashes of insight, not totall recall. In my experience, the audience can expect to remember 2 or 3 talks of 7 – and maybe 4 or 5 points that really struck them.
  • Lean on presenters. The one danger of a lightning talk buzzkill is speakers playing it too safe. Their slides look fine, but they only prepare one or two sentences per slide. They manage to deliver that sentence – and then wait 12 seconds for the slide to change. Sitting through that is quite lame for the last 15 slides… It’s difficult to avoid, but it’s more fun for everybody if speakers come with a tightly packed presentation – even if they stumble and then play catch up with the timer… Maybe encourage speakers to max out their topic and wring every last second from it, as if it was the last 5 minutes they ever had to share their enthusiasm.
  • Select a good sequence of talks. This is also a bit difficult to plan, but in general it works best to have speakers with less energy and slides with less “wow” go first and then work up to higher levels of energy and “wow”.
  • Demand the presos before hand. You need them to figure out the sequence and put them all on the same machine, so you can minimise the time between speakers. Some events publish the sequence before hand, others just announce it at the beginning of the session.
  • It’s not a contest. At least I don’t recall any lightning talk round scoring or voting for a winner. Instead, the Olympic sprit rules: “The important thing is not to win, but to take part”. They are more like a show-and-tell in school or like a sing-song round in a bar: Many people take turns, but everybody who contributes is cheered on, if only for valiant efforts.