Database Reference
In-Depth Information
Effects on the Product Team
Perhaps even more significant than the users' reactions are the effects that paper prototyping has on
the product team's mindset and the ways in which they work together.
Minimizes the Invested Effort
The more effort you've put into creating something, the harder it is to accept that it needs to be
changed. Say that you're a developer who has spent 2 weeks creating a prototype based on the
requirements spec you got from Marketing. Upon seeing it in action, Marketing decides they want
something different. What's your reaction?
Oh my yes, your way is obviously better. No problem, I'll change it.
a.
b.
But I did it this way because ...
c.
Sure, I'd be happy to waste another 2 weeks of my life coding something else you don't want.
d.
You want changes? Step outside and I'll make some to your face.
Unless you're a saint or a psychopath, you probably answered b, maybe c on a really bad day. It's a
natural reaction to defend one's hard work to avoid the need to redo it. I've also heard, and I'll confess
to having done this myself, that a developer who agrees to revise the interface may quietly postpone
this effort under the (sometimes correct) assumption that in a couple of weeks Marketing will again ask
for something completely different.
Of Interest ... Excerpt from "The Iceberg Secret"
by Joel Spolsky
February 13, 2002
Available at
www.joelonsoftware.com
.
You know how an iceberg is 90% underwater? Well, most software is like that too— there's a pretty
user interface that takes about 10% of the work, and then 90% of the programming work is under the
covers. And if you take into account the fact that about half of your time is spent fixing bugs, the UI only
takes 5% of the work. And if you limit yourself to the
visual
part of the UI, the pixels, what you would
see in PowerPoint, now we're talking less than 1%.
That's not the secret. The secret is that
People Who Aren't Programmers Do Not Understand This.
There are some very, very important corollaries to the Iceberg Secret.
Important Corollary One
If you show a nonprogrammer a screen which has a user interface that is 90% worse, they will think
that the program is 90% worse.
I learned this lesson as a consultant, when I did a demo of a major web-based project for a client's
executive team. The project was almost 100% code complete. We were still waiting for the graphic
designer to choose fonts and colors and draw the cool 3-D tabs. In the meantime, we just used plain
fonts and black and white, there was a bunch of ugly wasted space on the screen, basically it didn't
look very good at all. But 100% of the functionality was there and was doing some pretty amazing stuff.
What happened during the demo? The clients spent the
entire meeting
griping about the graphical
appearance of the screen. They weren't even talking about the UI. Just the graphical appearance.
"It
just doesn't look slick,"
complained their project manager. That's all they could think about. We couldn't
get them to think about the actual functionality. Obviously fixing the graphic design took about one day.
It was almost as if they thought they had hired
painters.
Important Corollary Two
If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will
think the program is almost done.
Search WWH ::
Custom Search