You are here: Resources --> 2000 --> Measure twice, cut once
Vous êtes ici : Ressources --> 2000 --> Measure twice, cut once
by Geoff Hart
Previously published, in a different form, as: Hart, G.J. 2000. Measure twice, cut once. Computerworld Canada, Nov. 17:21.
We’ve all heard the carpenter’s adage “measure twice, cut once”: acting without planning can be expensive, and because of the potential cost of poorly thought-out actions, we should not only plan, but plan twice. The person who builds a boat in their basement and discovers they can’t get it out the basement door isn’t an urban legend; it happened to someone in my neighborhood when I was a teen. Then there were some friends who, supervising the construction of their new home, arrived one day to find the builders scratching their heads in consternation; the single-piece bath and shower unit had just arrived, the day after the bathroom tiles had finished drying and the door had been hung.
Similar disaster stories abound, so when we plan projects, we naturally go into excruciating detail, trying to account for every detail and every possible contingency. The longer the project lasts, the harder we strive for a sense of security by extending those contingencies into the future, knowing full well that the future never quite turns out the way we expect. At least by planning, we reason, we show that we’ve acted responsibly: we’ve measured twice, cut once.
So why do our plans so rarely include time at the beginning of a project to talk to our customers and find out what they want? Why is there never time at the end of the project to confirm that we’ve actually created what those customers want?
Inertia and complacency, for a start. Unless we’re creating the latest dotcom phenom, we’re probably developing something for a captive audience whose needs we think we already know. There may be some justice to that, since they keep buying and using our product; that suggests we’re doing something right, and if it ain’t broke, whyever would we try to fix it? Well for one thing, our expectations often grow in a radically different direction from those of our audience. Does anyone still use or remember Visicalc? Probably not; Microsoft Excel stole the market from Dan Bricklin and Bob Frankston so long ago that for the younger generation, it’s hard to imagine life before Excel. Then there’s that little matter of operating systems; MS-DOS relegated CP/M to a historical curiosity, and the Windows juggernaut has left the Mac OS clinging desperately to survival.
Not understanding how to talk to our audience completes the answer. For one thing, we fear that they’ll tell us something we really don’t want to hear. For another, real people aren’t nearly so well-defined and predictable as the software algorithms we’re so comfortable with. The corporate financial analyst who condemns Microsoft for letting their programmers include a hidden pinball machine and a flight simulator in Microsoft Office has little in common with the 20-something gen-X novelist toasting the rebellious spirits who created these “Easter eggs”—yet both use Office productively. How do we reconcile the needs of such different people, let alone the rest of the audience?
We do it by relaxing and recognizing that the users of our products are, after all, just people, and that they all have similar goals in using our software, even if their nonfundamental, very subjective preferences differ widely. But the only way we’re ever going to discover those goals is to ask. Yes, there’s a whole science of analyzing audiences and another whole science of usability testing, but the fact is, you don’t have to be a scientist to perform useful research. As usability guru Jakob Nielsen observes, zero user interviews provides zero data, and even a limited amount of feedback is better than none. So start talking to your audience while you begin your planning, and again when you near the completion of your plan.
In short, measure them twice.
©2004–2008 Geoffrey Hart. All rights reserved