Fog Creek Software
Discussion Board




Prototyping with PowerPoint

I understand that some of the times you need to demonstrate functionality, the code HAS to work. It can't just be smoke and mirrors. In those cases, this unbelievably rock solid prototyping tool doesn't cut the mustard.

But nine times out of ten, when you want to demonstrate look and feel, when you want to hash out desired functionality (this menu choice takes me where? what does the dialog box look like? can i drill down here, or here?), when you want to solicit as much feedback as possible and implement every feature request in a matter of hours, then you've got to take a look at PowerPoint.

A few things you might not know: you can associate a hyperlink with any object (either through a click, or a mouseover). Hyperlinks can point to any slide in a presentation. You can set the presentation to advance slides ONLY when you've clicked on a hyperlink.

So. Draw your screens. Paste an image of the browser onto the master slide, and draw text boxes. Create a slide for every screen in your app. Need to change the design? No problem. You haven't coded anything, after all. In fact, why not prototype 2 or 3 interfaces now, since you won't be wasting any time trying to get the thing to actually work.

And because you haven't invested any time or energy into getting your "throwaway" app up and running, there's absolutely no chance you'll be tempted to use your prototpe as the foundation for the production app. Even better, you've just created a visual blueprint for the development team.

Most people, even when I tell them they're looking at a PowerPoint presentation, still have a hard time believing they're not looking at a functional application. Since I've been doing this, I've never had a demo crash on me, and I've even allowed clients to run the demo themselves.

Anybody else ever done this? If you're interesed in seeing how robust (and convincing) a PowerPoint prototype can be, send me an e-mail.

Robert K. Brown
Sunday, January 27, 2002


My former VP used to do this, and it was a Very Good Thing (tm).

It's a lot of work, sure, and Powerpoint it's not too smart regarding to linking pages, but he managed to create a complete mockup of the website. He printed it out and pinned it on his office walls.

From a business point of view, it was good because management has something to expect for. They knew how the final product should be, and keep them away from expecting too much.

From a technical point of view, it was good because we (the tech grunts) were able to provide feedback in early stages of design. Also, served as blueprints of the complete site, and it was helpful to have an estimate idea of current progress.

Also, it keep our VP busy, so he didn't bothered us with stupid meetings every five minutes :-)

Leonardo Herrera
Monday, January 28, 2002

Just curious ... if you're developing a website, why don't you prototype in HTML?  If an app, why not prototype in the language you intend to program in?  Simply stub out the functionality that will take time to implement ... this way your time isn't spent writing 100% throwaway code ...

Alyosha`
Monday, January 28, 2002

As we carry such exercises, we tried both ways:

- using Powerpoint
- using Dreamweaver and HTML

You could do it with DW if you stick to using 'layers' that you can move around and so on. If you start doing HTML with stylesheets and so on, the customer will focus on graphical issues and not functional ones.

In Powerpoint, it is clear that is is a kind of model and the customer will live with it when you use things like 'pages are blue', 'informations blocks are cyan' and 'actionable items are orange'.

Something efficient was combining the two:

- the powerpoint outlining the logic of the site
- the HTML prototype showing 'real' screens

When having the two views, you can either focus on presentation or logic but you know which one you are adressing in a workshop.

Phil
Monday, January 28, 2002

I prototype compiled GUIs in Visio.  The older versions were lacking, but 2002 is actually a usable product.  They have stencils for most OCX controls.  Don't know if it supports the hyperlinking you described though.

Brandon Knowle
Monday, January 28, 2002

This should make joel happy -- i've actually started prototyping my web applications in citydesk!

Matt Christensen
Monday, January 28, 2002

I can echo the point about using a web browser to demonstrate a web based system. We did this for a JAVA/JSP/EJB system, our prototype was HTML/JavaScript. By doing this we were able to demonstrate data validation mechanisms and control flows (which were not trivial).

Jonathan Naylor
Monday, January 28, 2002

This is PowerPoint unlike anything you've probably ever seen before. Just using that word conjures up all kinds of images: white text on a blue background, a few bullet points describing content with a tiny screenshot (or worse, clip art) because you need to break up the monotony of the text with an image now and then.

If you can't imagine ever the poor third cousin off the Office suite to protoype your applications, do yourself a favor and check out the sample below.

Save time in your projects for coding the application itself, not the demo or prototype you're using to get funding or acceptance.

You might be surprised at how much functionality you can demonstrate without writing any code. And how much easier it is (and how much more willing you are) to completely redesign a system ("Navigation should be based on product lines, instead of stores. That's not a problem, is it?") if you haven't set anything in stone yet.

Keep an open mind:

http://www.users.qwest.net/~brownrobert2

Robert K. Brown
Tuesday, January 29, 2002

"Why not prototype in the language you intend to program in?"

A couple of reasons - the target language doesn't always lend itself to making a prototype and you spend a long time coding something that stands a good chance of being thrown away.

Secondly (and mainly) - when presented a 'working' prototype, most pointy-haired bosses (and users) will assume that they'll have a finished program in a week or two (after all, the hard part is done, right?).

Also, if features do change when getting user feedback, they will be easier to implement in the final product rather then having to hack up the prototype (already begin application) to support it.

Jeff Pleimling
Tuesday, January 29, 2002

Of course, that assumes that your users are not SO clueless that they want you to ship the PowerPoint version.

Mike Gunderloy
Tuesday, January 29, 2002

Face it, most users this clueless know the capabilities of PowerPoint better then any developer ever will...

Jeff Pleimling
Tuesday, January 29, 2002

There is also the assumption by those that see polished prototypes that the step from that to shipping product is merely a matter of doing it.

Which is true, but 'doing it' is an almost infinitely divisible unit of work involving computer minutes, an almost infinitely extendable unit of time.

Simon Lucy
Wednesday, January 30, 2002

I've done it - mocking up 'functional' walk-throughs of proposed systems (or systems part-way developed) in Powerpoint.

It works best for apps while will be used from MS Windows clients - because that's Powerpoint's native look and feel, after all

In fact, if you have a script for what functionality is to be shown in the demo, then it makes an excellent way to  'demo' the app to influential users of the upcoming app. 

One particular reason for these situations is that the 'app' is *very* robust, (Powerpoint's been in live use for a long, long time in many, many places).  And if it does fall over for some reason, then it's *not* your app that's just crashed under the nose of the divisional Director - you can blame it on Powerpoint.

Gordon Love
Tuesday, February 12, 2002

*  Recent Topics

*  Fog Creek Home