Thinking About Prototyping - Paper Prototyping: The Fast and Easy Way to Define and Refine User Interfaces - page 50

vision of the product and how it serves its target user population.

For a developer, it's frustrating to implement something that wasn't quite what Marketing had in mind. I
call this the "Amelia Bedelia" problem after a funny series of children's topics about a well-meaning
maid who follows her employers' instructions literally, with predictably disastrous results. It's not so
funny when you've spent days or months developing the wrong thing. Interface specs—even with
screen shots—don't solve the Amelia Bedelia problem because they don't show the behavior of the
system and they also don't show you what people expect the interface to do (especially nontechnical
people because they have a harder time inferring functionality). But when you put a paper prototype in
front of someone and watch them use it, you'll quickly discover whether it meets their expectations. It's
a good idea to get Marketing (or whoever collected the requirements and wrote the early project
documents) involved in prototyping sessions and make sure they attend the usability tests. [ 1 ]

Opinion Wars

Every development team has its opinion wars—those endless meetings where arguments go round and
round about the best way for users to do something. Many opinions are based on assumptions, and
particularly nasty disagreements are often based on unspoken assumptions. Or sometimes there's
simply a lack of data—in the words of philosopher Bertrand Russell, "The most savage controversies
are those about matters as to which there is no good evidence either way."

I once stopped two developers who were on the verge of a fistfight over whether there should be an
Update button on a form. The interface in question was a client-server software application used by
customer service reps (CSRs) while on the phone with customers. This particular form showed the
customer record, including data such as address and telephone number.

Developer A: "There must be
an Update button!"

Developer B: "No Update button, you
idiot!"

Unspoken
assumption

Data integrity is paramount. If the
CSR accidentally types into a
field, customer data could be
overwritten and lost.

Speed of customer service is
paramount. If the CSR has to click an
Update button and the system is slow to
respond, the customer will get impatient.

Conclusion Make CSRs click an Update

button first if they need to make
changes.

Let CSRs make changes directly to the
customer record.