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