Fog Creek Software
Discussion Board




Paper prototyping - drawing tools

I have started doing paper prototyping. It works very well, as I can show the developers exactly what I want.

I have found the SmartDraw from http://www.smartdraw.com to be extremely useful.

I can draw mock user interfaces FASTER than I can do it on paper, with a pencil!

It has a software library which contains drawings of checkboxes, combo boxes, etc. However, I don't use that - I just use the basic features.

The drawings don't look exactly like program UI, but that's the point - it's a prototype, not an UI.

I also like the fact that I can easily insert a SmartDraw picture into a Word document.

My question is: Which is the best tool for drawing mock user interfaces?

SmartDraw is faster than pen-and-paper once you spend about one hour learning it, but I would like to know if there is a tool which is even faster or better.

Thanks!

Manager in Germany
Tuesday, June 15, 2004

I've thought about giving SmartDraw a try although we have and use Visio (though it is a bit of a pain)... do you know if SmartDraw can be used to easily create printable forms?

<sarcasm read="optional"> Personally, I recommend using a whiteboard and discouraging people from taking any notes... that way, when you deliver a UI that's [very] different from the mock-up, you can 'innocently' just say, "Here it is, exactly what we whiteboarded".  Any questions can be met with "Hey, don't you trust me??" or "What, you don't remember??" or some other off-putting comment. </sarcasm>

More seriously... if you've found SmartDraw to be "extremely useful", be happy to have it and don't be disappointed if nobody recommends something "better".  Anyway, "best" is often a subjective thing....

Should be working
Tuesday, June 15, 2004

Are you nuts? :)

I don't like the whiteboard approach especially for this reason.

I like to have a clear document which I can keep.

Manager in Germany
Tuesday, June 15, 2004

The most effective approach toward GUI development I have used depends on printing out exact screen-shots of exactly what each screen is going to look like.

This lets the user sign-off on exactly what they are going to get, and un-ambiguously indicate changes.

One of the risks of this approach is the 'thrashing' that goes on -- user 1 likes screen A one way, user 2 likes it a different way, etc.  However, this approach is the cheapest and most direct way to resolve the 'thrashing'.

Another risk of this approach is sheer volume.  A moderately sized project will have around 200 to 300 screens.  That's a lot of pages to have to print, review, walk-through, and explain. 

Still, I have found resolving ambiguity early and often to be the best way to control requirements creep.  By 'control' I mean identify when it is happening, ask the customer for more dollars to implement it, and get sign-off should the customer not be willing to pay for it.

AllanL5
Tuesday, June 15, 2004

Have you taken a look at DENIM?

http://guir.berkeley.edu/projects/denim/

Interaction Architect
Tuesday, June 15, 2004

AllanL, you forgot the other danger.  If the user sees a mockup that looks real, then they think you're done.

Joel wrote about that once, and my experience tends to agree.  It doesn't matter if you tell them that these are just fake pictures, they will still think you are basically finished with the app and will expect in a week or two.

Steve Barbour
Tuesday, June 15, 2004

"They'll think you're done..." -- very good point.  It is necessary to balance this perception with the desire to remove ambiguity.

With that point, doing a 'paper sketch' version as the original poster suggested has even more merit.  It's less likely to be confused with the actual product.

AllanL5
Tuesday, June 15, 2004

Just took a quick peek at DEMIN. It looks really slick.  Easy, and intuitive to use. Produces essentially "sketched-looking" hyperlinked pages. 

So, it's easy to use, functions sort of like a real web page, but doesn't look like a finished product.

Free download.


Have you taken a look at DENIM?

http://guir.berkeley.edu/projects/denim/

Mr. Analogy
Tuesday, June 15, 2004

Creating screen shots is a great idea.

The trick is to use some tool that RAPIDLY Lets you make those screens.

(I am going to look into that tool the OP poster mentioned)

While a few people commented about dangers of showing clients the screen shots, what about the developers?

One great solution is to use those screen drawing tools, but ALWAYS show paper screen shots to the client, and never use a computer (fax it. don’t email screen shots). This goes a long way, as the screens on paper don’t look quite real anyway (keep them black and white).

In other words, if you are making a functional spec, then having screen shots can REALLY be nice for initial design work, and will speed up things immensely for the developers that now have a great base to work with.

I just got a spec from a possible client on Friday, and it included all screen shots (he mentioned the tool used to make the screen shots. and I did not write it down. darn. I will ask him/them again as to what tool).

The application is quite small (only 25 screens shots in the original so far. I expect this to increase. but the basic design is only 25 screens). However, the client has mentioned that already 200+ hours have been spent on this spec, and NOT one line of code has been written. So, good time has been spent gathering requirements, and a basic design has now been speced out.

My guess is that coding time will be LESS then what it has taken to make the design doc. (I am guessing about 90 to 100 hours)

I predict a rather good success for this project due to the above ground work.

As I see more and more questions about screen shots and tools to make the design documents, then it does seem indeed that our industry is maturing, and people are sick and tired of projects that fail.

As one does a better design job, with the very productive software environments we have today, coding time is now less then design, and requirements gathering time.

Good specs, and having the project scoped out well before you start coding is the best thing one can do.  This actually does happen in the real world!


Albert D. Kallal
Edmonton, Alberta Canada
kallal@msn.com
http://www.attcanada.net/~kallal.msn

Albert D. Kallal
Tuesday, June 15, 2004

Paper prototype should really mean paper, not a word doc. The idea is that users who see a bunch of hand drawn stuff are much more willing to offer suggestions and ideas than those who see a polished document.

Personally, I use powerpoint, which is easy enough to draw with, but no one in their right mind associates with completed designs or code.

MilesArcher
Tuesday, June 15, 2004

Oh good, SmartDraw's installer defaults to c:\smartdraw. How professional!

Fred
Tuesday, June 15, 2004

So with the problem of customers looking at prototypes developed in Smartdraw/VB/Delphi/V.Studio and thinking the job is nearly finished, is there a market for a utility that can take a VB/Delphi/V.Studio prototype form and convert it into a bitmap that looks hand drawn?

Ian H.
Wednesday, June 16, 2004

>> is there a market for a utility that can take a VB/Delphi/V.Studio prototype form and convert it into a bitmap that looks hand drawn?

Seems like it :)

Tony Edgecombe
Wednesday, June 16, 2004

There's already such a program.

It's called photoshop.  I never thought of using the filters that way before though.

I just tryed it, and it's not bad.  Looks like the smudge stick filter offers a good balance.  I tryed the photocopy filter, but I like to see the colors myself.

Steve Barbour
Wednesday, June 16, 2004

*  Recent Topics

*  Fog Creek Home