Developed by Brian Hanley, Master's of Engineering degree candidate at Lehigh University

Developed by Brian Hanley, Master's of Engineering degree candidate at Lehigh University
Once a history major, I'm now making history developing innovative products to improve processes. I'm not a millionaire. I'm an expert at nothing. I'm simply here to share what I've learned.


When it comes to developing mobile apps, no design method is easier or more resource-efficient than paper-based prototyping. In Five Paper Prototyping Tips, Matthew Klee attributes the triumph of paper-based prototyping to its inexpensive and relatively uncomplicated nature. Because paper is particularly economical and easy to work with, Klee argues, developers can make major conceptual modifications throughout the design process. Upon receiving user feedback, for example, it becomes critical that developers can scrap early-stage mock-ups without suffering a crippling economic burden. Generally, developers, with their eyes keenly fixed on the bottom line, prefer scrapping paper to more expensive materials. Moreover, paper mock-ups tend to appear unpolished and unimposing; for that reason, users feel more comfortable criticizing paper than more costly materials. Klee, convinced by the aforementioned reasons, considers paper-based prototyping the single most economical way to incorporate direct customer feedback into any design.


In Paper Prototypes: Still Our Favorite, Tara Scanlon provides evidence to support Klee’s contention that paper-based prototypes are highly versatile and efficient. The central point of Scanlon’s article is that paper prototyping facilitates positive team interaction. Paper, Scanlon explains, is so effective because it is something that all members of the development team understand. As opposed to coding an interface, which, when done correctly, requires painstaking practice, there is nothing terribly intimidating about designing paper mock-ups. The development team can sit around one table with pupils fixated on one mock-up, exchanging one conversation at a time. More than any other method, Scanlon contends, paper-based prototyping levels the playing field and encourages all team members to pitch in.


In Looking Back on 16 Years of Paper Prototyping, Jared M. Spool also marvels at the power of paper. When it comes to getting results quickly and effectively, nothing, according to Spool—not even the advancement of technology—trumps paper-based prototyping. Paper is ideal for getting feedback about a design. It is neither demanding nor wasteful. Supporting the arguments provided by both Klee and Scanlon, Spool contends that paper mock-ups are the single most effective way to test the usability and navigation elements of any design.


Klee, Scanlon, and Spool’s insights run parallel to my personal experience with paper mock-ups. From paper, I prototyped three different applications for tablets and mobile devices (which I would later test with end users before creating a fourth (and final) design). The first design was a “Food Network Cooking Guide App” that incorporated recipes with live streams of available cooking shows. The second was an app that allowed sentimental social media users to “Frame-A-Text” that they deemed too valuable to delete. The third was a “Signature Identification App,” applicable especially in the realm of fine art collection and scholarship.






I found that creating clay mock-ups was convenient for the same reasons as creating paper ones. Clay is relatively cheap and easy to modify. However, it does require some time to fully dry. For that reason, I preferred working with paper.




Too often, I sought perfection in my prototypes. I wanted to design presentable mock-ups that my end users would appreciate, at least aesthetically. Upon reading Looking Back on 16 Years of Paper Prototyping, however, I was reminded of an important fact. Developers are concerned, not necessarily with the prototype’s appearance, but with its usability. Whether or not users “like” the prototype is, at the prototyping stage, irrelevant. What is imperative, Spool explains, is that users can use the mock-up.



In Prototype Testing, Marty Cagan describes the value of testing prototypes with real users. Usability testing, Cagan explains, allows developers to see if customers can figure out how to use specific prototypes. Desirability testing, on the other hand, assesses the actual usefulness of each prototype. Just because a shrewd customer can figure out one particular product does not mean that the product is commercially viable. Therefore, it is important to test prototypes for both usability and desirability before additional resources are squandered on unnecessary development.


When it came time to document user feedback, I relied on Cagan’s numerous recommendations. First, I defined the usability tasks I sought to test and the interview questions concerning desirability. My aim was to twofold: to observe untainted user impressions and to test prototypes that required no explanations, for they sufficed in themselves as explanations. I kindly asked that each user remain in “use mode” so that they could figure out each prototype firsthand. Gauging value, I then asked if each user would pay for the prototype. Lastly, I had each user assign a numerical score (1-10) to each prototype. This allowed me to track averages and assess which prototypes prompted more positive user feedback.


The feedback helped me enormously. I learned the answers to two important questions, both of which Ulrich and Eppinger discuss in Product Design and Development.  The first question, related to functionality, is quite simple—“will my product work?” The second question, concerning desirability, is equally straightforward—“how well does my product meet customer needs? For both my paper and clay mock-ups, all six designs seemed to work. But where customer needs were concerned, the prototypes, in most cases, proved obsolete. The “Signature Identification App,” for instance, neglected to captivate my users’ interests because my users were not art collectors. The problem was, I neglected to test the prototype with the niche customer base on which my product depended. By marginalizing art collectors from my user research, I failed to communicate with my target market altogether.


One might assume that the process of creating and re-creating iterations of the same mock-ups is an exercise in redundancy. But for me, because I prototyped different products and tested them all in stages, I felt prepared, informed, and educated on both the usability and desirability of each design.


Certainly, it is worth acknowledging that, where customer research is concerned, my sample size was extremely limited. However, at least now I knew what my ten potential customers looked for in a product. More so than anything else, a peer’s remark regarding the “Signature Identification App” resonated with me. Tony Bagdon said, “Very cool idea, Brian… but I personally wouldn’t buy the app.” That right there is the lesson I hope to remember and practice throughout my entrepreneurial career. It doesn’t matter how cool your ideas are, or how polished your prototypes look. What matters is that your customers can use your products; and more importantly, that your customers will pay to use them. Otherwise, all you have is quirky ideas and no means by which to pay the bills.