A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I'd never read Joel's brief review or heard of the book before reading "frustrated system analyst's" thread below, but now that I have, what a revelation! I've already ordered Carolyn Snyder's book. Imagine my suprise when hearing that a veteran UI designer has been doing something for several years that has always felt right to me, yet is not accepted by most of the places I worked.
Even though Paper Prototyping isn't a canonical institution in the so-called Agile Methodologies, I think it fits right in - it lets people get things done more correctly (if you believe in gradations of correctness) and faster because you in effect are doing iterative implementations before writing any code. But nobody believes you can do a prototype unless you're typing code and as Joel says, if a prototype is doing all the work, it may as well BE the product. ARGH!
I know the theory of prototypes claim that they are supposed to be hollowed out shells of the real thing. But users/managers/whomeever don't REALLY understand (no matter how many times you tell them and how many times they claim they get it) and only complain about the features that aren't there yet. So you end up using extra effort putting in this extra stuff just to get them to shut up until you reach the point where the so-called prototype has 80% of the features of the finished product.
Anyway, enough of my ranting. Great thread and great review. Now to use this in practice...
Using paper to sketch out the interface (I can't use the word prototype it makes my teeth ache), means you can do it in front of them, you can do it with them and they can see how plastic and non threatening it can be.
They're also extremely easy to throw away.
Thursday, September 09, 2004
Hear hear! You can revise the design right in front of the client, and when the client inevitably tells you that's not what they want you've only wasted minutes rather than days or weeks.
I also find whiteboards make good prototyping tools too, particularly the ones that can print.
Thursday, September 09, 2004
Not only can you sketch out and revise the design in front of the client, but often you can (or must) involve the client in a *collaborative* design effort.
A few thoughts, as I think back to some recent projects:
1) I’ve found that the less familiar I am with the problem domain, the more I tend to rely on the “paper protoyping” approach as a design tool. For instance a project I managed not too long ago involved building a financial credit processing application, something I knew virtually nothing about. We got into a “paper prototyping mode” as a collaborative, interactive process with the client, using one of those whiteboards that can spit out a hardcopy, as Matthew already mentioned, and after about a week we had the beginnings of a rudimentary UI design that everyone seemed happy with. More importantly, we had mapped out the workflow to a previously vague and (by us) poorly understood problem domain. The approach was successful, but hardly innovative. In essence, I agree with you guys but I don’t quite see what all the fuss is about. UI design has to be done anyway; all we were doing was relying on it perhaps more than usual to shape the initial system design, and using it as a tool to do a Vulcan mind-meld with the client’s business process experts.
2) The fact that you’ve done (1) has no bearing on what development methodology you subsequently use, which might well be the sort of prototyping (I prefer to call it iterative development) that Joel seems to dislike. I just don’t get it about “...if a prototype is doing all the work, it may as well *be* the product...”. In many of the most successful projects I’ve worked on – including the one mentioned above – the prototype indeed *was* the embryonic product; that is, the process of iterative development was central to our development philosophy and methodology. This approach is pretty much essential in the all-too-common case where the client really doesn’t know what they want; at least, not to a sufficient level of specificity that would allow traditional waterfall design to be successful.
Thursday, September 09, 2004
This reminds me of the time I gave English classes to some managers at CVRD. They were implementing something called Total Quality Management. I had never heard of it. Well, we talked about it during classes and I read a bit about it. Hello common sense I thought. Same with paper prototyping. Last time I had my consulting site up I had a picture of a pencil.
I wonder if there are people who just don't have clue and just are not honest enough to admit it or assume everyone else is in the same boat. I dunno. Everywhere I've worked it's all verbal until the time it hits me (or worse they believe the mishmash in the word document has much meaning).
Monday, September 13, 2004
One of my students once said:
"Erasers are cheap"
Denim is a neat little app for web prototyping, but could be used for program prototyping as well.
Haven't tried it but it looks cool.
Essentially hyperlinked sketchpad.
In an ideal world there would be napkin to software scanner software (like OCR).
(Just a subtle hint for anyone who has nothing to do this evening!)
Wednesday, September 15, 2004
I like paper prototypes. We've sometimes built software with strings and magnets and stuff :-)
My problem is how you use paper prototyping for more interactive software. Our software is closer to Adobe Photoshop, Illustrator and Premiere than to webpages and dialog-based database applications.
You can mockup a big dialog box with paper easily.
But how can Adobe, for example, mockup how the layer-sets in Photoshop CS work together with the different tools in the toolbox?
Thursday, September 16, 2004
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz