A content strategy focused on making content easy to reuse and reducing the cost of localization — for a diagnostic device designed to save lives.
Background A patient lies on a table with a catheter threaded from her thigh to an artery near her heart. The diagnosis will determine whether a surgeon needs to open her chest...
Boston Scientific's intravascular untrasound catheter poses an unusual learning challenge for the technicians and cardiologists who use it. It's a highly specialized diagnostic device they need to use only infrequently — namely, when a cardiologist needs to confirm the diagnosis of a serious vascular condition. Both cardiologist and technician need to be confident that they know how to use the device correctly. They depend in part on the trainers who train them, the tech support reps who help them troubleshoot problems, and the field service reps who keep the device working. Everyone ultimately depends on the learning materials.
  Unfortunately, the existing materials were a hodge-podge of stuff no one had much good to say about.
  Boston Scientific needed a comprehensive strategy for its learning materials. They were smart, dedicated people who collectively understood how the device was used, what its unique value was, and what the obstacles were to learning it. The problem was that everyone individually saw only part of the problem — and one facet of the solution.
The Project Interviewed users (American and Japanese) and created user profiles. Assessed cultural differences. Created user profiles. I interviewed nearly twenty users — cardiologists, operators, and trainers, as well as field service, technical support, and sales reps — all of whom had overlapping needs for learning the intravascular ultrasound system (IVUS).
  Making the problem even more interesting was that the device is used worldwide in very different healthcare environments. I interviewed users in both the U.S. and Japan to assess cultural differences in those two key markets.
  From those interviews, I distilled in-depth profiles of the six target user groups.
  (Excerpt: operator persona, PDF, 125k; notice that the profile in front is followed by 11 pages of direct quotes from the interview subjects.)
  Analyzed tasks. Created workflows and user scenarios. I also analyzed the user interface of the IVUS device based on the use cases the engineers had developed. The engineers, as is fairly typical, treated the use cases as if they were all equal. There was no sense of which ones were essential from the users' perspective — from the engineers' viewpoint they all had to work equally well.
  So during my interviews, I asked each user what they saw as their most important tasks. I was then able to create detailed workflows that focused on the primary scenarios and included paths to the less important tasks.
  (Excerpt: workflow for a diagnostic run, PDF, 100k)
  Summarized findings. Proposed centralizing and reusing content. Three things were clear from the user interviews and the use-case analysis:
Each user group's primary tasks were different. Sometimes the differences were only
slight (for example, for operators and cardiologists). Sometimes they were
substantial (for operators and field service reps).
The formats each group preferred and needed also varied.
Yet the content the various groups needed overlapped considerably.
  Clearly, Boston Scientific's existing approach — each organization maintaining its own materials for its own audience — was inefficient. The strategy needed to be based on reusable content that could be generated in different formats.
  Analyzed, inventoried, and assessed content. Generated a comprehensive outline. I next built a relational database to organize, structure, and analyze the content — without regard to its final format.
  I identified the topics a user needed to understand and complete each task. I inventoried the content that was included in the existing learning materials. I assessed the existing content to determine the topics that were covered, information that was missing, and information that needed to be deleted.
  I subdivided topics into individual content elements. I categorized every element by the function it served in addressing a topic. For example, the most common functions were:
Background information needed to understand a feature
Prerequisites before a user started a task
Steps to complete a task
Troubleshooting if something went wrong
  I gave every content element an ID. I used the database to generate a comprehensive outline of all the content that needed to be created.
  (Excerpt from the content outline, PDF, 75k)
  Developed a reuse strategy. Analyzed the content lifecycle. Generated a content reuse map. The next step was to figure out what content each group of users needed and what format the content should take. I'd asked each interview subject how useful they found specific formats — quick guides, online help systems, interactive tutorials, videos, and so on — and why.
  From their answers, I created a list of the formats each user group preferred (for example, operators wanted a printed quick guide; nobody wanted videos). In the database, I tagged each content element by who needed it and what format they wanted it in.
  I also analyzed the content lifecycle — who generated information and when, and how often it was likely to change.
  From that information, I was able to use the database to generate a content reuse map that defined which content items each group of users needed and what format the content took. I made sure content that changed often was in a format that was easy to maintain.
  Helped define the technology solution. Finally, I worked with the technology team to:
Prototype key pages and develop content specifications
Map out the components of a system to generate content in different formats from a
single-source content repository (information development roadmap, PDF, 250k)
Export the content metadata in my database in a form that could be used to
populate the content repository