TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> I think the best examples of technical documentation I have ever seen are
> the instructions that come w/ modern-day Lego kits. They are entirely
> pictorial, the "chunking" of pieces-per-pictograph is brilliant, the
> sequencing (build this 'subsystem,' then that one, then join them
together)
> is topnotch. They are localised for any market, as they use no text
(except
> arabic numerals to show the sequence of ops--that might be a problem in
some
> markets).
I was thinking the exact same thing when I was assembling my Lego Mindstorms
droid a few weeks ago. Very clear and straightforward, and you can easily
flip back and forth to see how the part you're working on fits into the
greater whole. When I first got the Expert Builder Lego (now Lego Technics)
auto chassis when I was a young'un, I was able to get a good understanding
of how rack-and-pinion steering, gear shifting, and pistons worked.
Wind Day notes:
> I also like the instructions for IKEA furniture, for the same reasons.
I disagree on that score, but then I've had to assemble a lot of Ikea
furniture in the last year :) As I discovered when assembling my computer
desk (and bookshelf, and CD rack, and...) there are often pieces that are
very similar, save for little discrepancies. It's too easy to accidentally
put dowel A into board B when it was supposed to go in board C. That
ambiguity isn't limited to us lay people, either; when I had to get a split
board replaced, I was initially given the wrong board which was, again,
identical save for two holes. The employee and I both made the mistake, and
so did the person I returned it to afterward.
It's a classic case of how a little cooperation between the devs and
documentation could have solved the problem. All that would have been
required is a little sticker with an identifying letter on each piece, or
perhaps written onto the rough edge.
Mark Baker adds:
> The only problem with calling this "best documentation" is that it does
not
> solve a particularly hard problem. It just shows how to fit pieces
together.
> Sure, pictures work fine for this. Ikea's documentation generally works
well
> for the same reason. But there are no concepts to be mastered here. There
> are no conditions to assess. No interactions with an external environment
to
> manage. Not even any tools required. Physical assembly of well designed
> components just isn't much of a challenge to do or to document.
Of course it's not a hard problem; I don't think that's entirely the point.
The trick is to look at the particular problems that were faced and
overcome. Both Lego and Ikea products are geared toward people who could be
speaking any language, so the docs need to be clear few or no words; in the
case of Lego, the user could be eight years old, so specialized knowledge is
right out. And yet millions of kids (and nominal adults like me) can create
X-wing fighters, helicopters, and rope and pulley systems right out of the
box. The docs do their job clearly and efficiently, and borrowing from
their methodology where appropriate is, I think, a worthwhile task.
