by Mark L. Levinson

When I receive a document from R&D, it’s easy to tell whether Dror wrote it or Liora did.  Dror is an allower, whereas Liora is an enabler.

The way Dror writes, the TiePlumb personal neckwear verticality solution allows you to straighten your necktie perfectly in less than ten seconds.  The parameter screen allows you to choose your degree of tolerance.  Everything is “allows,” or “permits,” or sometimes “lets.”  But none of those usages makes much sense.  To allow something, or permit it, or let it happen, means merely not to interfere.  Yes, the screen allows you to choose your degree of tolerance; but so do I.  So does Rover, my goldfish.  So does Microsoft Excel.  None of us hinders you or disapproves.

Liora, on the other hand, says that TiePlumb enables you to straighten your necktie.  The parameter screen enables you to choose your tolerance.  Better, but it reminds me of the Henny Youngman joke:  “Doctor, will I be able to play the piano after my operation?”  “Sure you will.”  “Funny, I couldn’t play it before.”  It takes a lot to enable you to do anything.  Many factors, not just the one last click of the mouse. 

So if not “allows” and not “enables,” then what?  I did a little work once on a set of books called the Yu-Can Learning Series.  Its trademark was a toucan.  The visual rhyme was unorthodox, and I think that the books are extinct, but the focus was on target.  Not “the software enables,” not “the software allows,” but “you can.”  With TiePlumb, you can quickly straighten your necktie.  With the parameter screen, you can choose your tolerance.  It’s everyday language, and it’s user-centric.  Is it tiresome to read a book full of you can, you can, you can?  I don’t think so.  I think that the mind eventually treats the you + can + verb construction as if it were all one word; just another verb tense, as it were.

The only trouble with the yucan — what makes it second best — is that it smacks of specificationese.  It sounds tentative, a little like those manuals that say “this product is designed to” or “this product is intended to.”  The product exists.  By now either (a) it works as designed and intended, so you should simply say what it does, or (b) it does not work as designed and intended, so you shouldn’t be selling it. 

What do you think when a manual says something like “After a moment, the updated details should appear”?  I think of a writer sitting there saying, “We know what should happen, but once the product is out there in the field, what happens is anyone’s guess.”

Show confidence.  Don’t weasel around.  Whenever possible, instead of talking about what the user can do or what the software should do, talk about what the user does and what the software does.  You use the parameter screen to choose your tolerance.  With TiePlumb, you need less than ten seconds to straighten your necktie. 

What if some klutz still takes fifteen or twenty seconds?  For that, your manual should start with a disclaimer.

Comments and questions are welcome:  

Do you benefit from elephant.org.il?

If you benefit please help out by becoming a member. For just 100 NIS your annual dues keep Elephant alive.