Introduction - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 15

Author Background
It's probably already clear that I am a practitioner, not an academic. I gained much of my experience in
hard-to-use interfaces because I spent the first decade of my career creating them, first as a software
engineer and then as a project manager. (The building controls company where I worked was full of
well-meaning people, but this was back in the 1980s, when most people, including me, knew nothing
about usability.) Although my software skills have fallen by the wayside, I still have some clear
memories of the pressures and challenges involved in product development. I remain sympathetic
toward development teams, especially knowing that technology certainly hasn't gotten any simpler.
In addition to my computer science background, I also (for reasons still not entirely clear to me) picked
up an MBA along the way, which gave me a tentative grasp of business concepts. [ 3 ] Working at a
small consulting firm (User Interface Engineering) for 6 years gave me a very practical, whack-upside-
the-head grounding in sales, marketing, and finance. Like the difference between profit and cash
flow—profit looks nice on paper, but cash flow is where your paycheck comes from. So I approach
usability from a business perspective, trying first to understand the importance of the product to the
company and to its users, then looking for ways to identify and manage the risks. After all, if an
otherwise good company makes too many mistakes and goes out of business, everyone loses. Paper
prototyping fits perfectly into that mind-set because it lets you make (and fix) most of your mistakes
before the product goes out the door.
I am not a researcher or scientist, and I don't even consider myself an expert in HCI; it's a big field, and
I'm sitting in a small corner of it. There are many good papers and articles about paper prototyping, but
for the most part I've confined the references to their own section at the end of the topic. I mention
some of the especially interesting ones along the way, however. Although this topic discusses many
topics for which there is HCI research, this topic isn't about the research— it's about what real product
teams do. Scientific studies are a fine thing; the experience of practitioners is equally important but less
often published. So I've made an effort to include many real-life examples, anecdotes, quotes, and
case studies from my clients and peers—material you won't find anywhere else, because although
many of these people know enough about paper prototyping to write their own topics, they don't have
the time.
[ 3 ] And also confused me because I no longer was sure which Dilbert character to identify with;
sometimes I feel sympathy for the pointy-haired boss.