Database Reference
In-Depth Information
let's estimate that they could answer 70% of their questions with a paper prototype that would take 3
days to develop, as opposed to taking a month (20 days) to make a working version. So the calculation
is as follows:
Paper 70% ÷ 3 days = 23
Working version: 100% ÷ 20 days = 5
It's easy to see why The MathWorks uses a lot of paper prototyping—it's almost a no-brainer for them
given that their software is highly conceptual and complex to build. Even though I made up these
estimates, you can see that the numbers would have to change a lot (for instance, building the working
version in 4 days instead of 20) to yield the opposite conclusion that they'd be better off building a
working version first.
Example 2
A complex information visualization interface. Say you're developing a Web site that displays real-time
display of U.S. stock market data. Blocks representing companies appear in varying shades of red and
green to reflect their current stock price. In this case, the paper prototype might not do a good job of
portraying the subtleties of the display and interaction—assume it would answer only 60% of the team's
questions. At the same time, this paper prototype might be time-consuming to develop because a
display that changes would need to show many variations. Assume there's a working prototype that
would need a week's worth of work to prepare for testing.
Paper 60% ÷ 4 days = 15
Working version: 100% ÷ 5 days = 20
In this case there may be a stronger argument for testing the working version, although the decision
could easily go the other way if the estimates are off—if the working version ends up taking 8 days
instead of 5, the team might have been better off testing with paper. The team might want to make the
decision by considering the factors I discuss in the
next chapter
(for example, the stability of the
software).
Example 3
An e-commerce site. Screens are being developed in Dreamweaver. Layout is important, so the team
wants to test using screen shots. It'll take a couple of days to mock up all the necessary pages and
print them out, but at that point it would only take 2 days more to link them and get the order form to
work. The team's pretty comfortable that either method would answer most of their main questions;
there are just a few aspects like rollover menus and some animation that won't work well in paper.
Paper 90% ÷ 2 days = 45
Working version 100% ÷ 4 days = 25
In this example the paper prototype wins at first glance, but given the small incremental amount of work
to make the mocked-up site work, there might not be much risk in going that route. This is a case
where probably neither decision is wrong—if no other factors argue for or against using paper, you
could even flip a coin!
I find that sometimes the efficiency ratio is an illuminating tool and other times it's useless. It also
ignores the benefits and drawbacks of each method (for example, paper prototypes allow for more
creativity, but they don't generate code). Your answer may be quite clear in regard to one technique
over the other and thus lend you confidence about the best way to proceed. But if the results aren't so
clear or you have a lot of uncertainty in your estimates, the efficiency ratio may not be a helpful tool for
you—feel free to ignore it. Just keep in mind that one definition of a good prototyping method is one
that provides sufficient value in return for the effort you put into it.
Search WWH ::
Custom Search