Prototyping With PowerPoint


A couple of weeks ago when I talked about
The
Feature Bob Invented
, I mentioned that we use PowerPoint as an easy way to
prototype UI, especially in the early stages of design. A number of people have asked me
for more details, and so today I thought I’d go through it step-by-step.


We use PowerPoint as kind of a better version of
paper prototypes.
This technique has several advantages: prototypes can be made to feel somewhat interactive, because the content
is electronic it can be modified more easily than paper, and (best of all) the
usability participant uses the mouse and is on the computer, so it feels natural to them.


In my opinion, paper prototypes always suffer a little bit because of the
weirdness of asking people to pretend paper is the monitor and a pencil is the
mouse. (Although I guess with the advent of Tablet PC’s, this is becoming less
weird…)


Note: The following technique will only work for PowerPoint 2002 and above.
Previous versions did not include sufficient support for transparent AutoShapes.


The way we normally set up PowerPoint prototypes is this:

  • Put screenshots of all of the different UI states you want to test onto
    different slides.


  • If your UI is mostly popups on top of a static frame, you might consider
    putting that static frame into the slide master background; that way, you
    only need to put the UI which changes on each slide. (Click View,
    Master, Slide Master to access the slide masters.)

  • Next, you want to make sure PowerPoint doesn’t advance your slide show
    to the next slide whenever the user clicks. This is so you can simulate
    interactive click behavior within the prototype. Click Slide Transition on
    the Slide Show menu, turn off the setting to Advance Slide On Mouse Click,
    and then click the Apply All button to apply the setting to all slides.

Now, that your overall prototype is set up, it’s time to add interactivity. Let’s
say you have a button, and when
someone clicks on that button, you want it to simulate bringing up a menu. Easy
enough, assuming you have added slides containing pictures of both states
(pre-menu and while the menu is up.)

  • Using the Drawing toolbar at the bottom of the screen, draw a box over
    the hit target for the button. (You can use any other AutoShape you want, it
    doesn’t have to be a rectangle.)

  • Now, right-click the shape and click Format AutoShape on the context
    menu.

  • On the Colors and Lines tab, set the Transparency to 1% and remove the
    border entirely. This will make the shape virtually invisible, yet will
    still allow you to receive mouse clicks on it. (If you make it entirely
    transparent, PowerPoint doesn’t register mouse clicks on the shape.)

  • Now, right-click the shape again, and click Action Settings on the
    context menu. This is where you determine what should happen when the button
    is clicked.

  • Normally, I choose “Hyperlink to:” in the dialog and then choose to which
    slide it should navigate. You could also be fancier and have an external
    program launch, a sound played, or run a custom macro. If you wanted a snazzy
    rollover effect, the Mouse Over tab in this dialog would be the place to do
    that.

  • Repeat this process for each slide to which you want to add interactive
    behavior.

You’re good to go! We’ve found that this technique has yielded some very
useful prototypes with a minimum amount of work.

Comments (33)

  1. Tom Bradley says:

    We’ve done some similar stuff with interactive pdfs.  It’s true, this sort of technique does give a good feel for how a product will function.

    Trouble is, it basically just provides equivalent functionality to the next button, with the user moving though the application one screen at a time.  We’ve tried to be more ambitious with hyperlinking to differant parts of the document, but the whole thing gets very complicated, very quickly.

    I just wondered where you draw the line?  Do you attempt to make a prototype that provides the interactivity of a number of features, or do you concentrate on the flow of one linear task?

  2. We use PowerPoint as kind of a better version of paper prototypes. This technique has several advantages:…

  3. We use PowerPoint as kind of a better version of paper prototypes. This technique has several advantages:…

  4. The Buzz says:

    We use PowerPoint as kind of a better version of paper prototypes. This technique has several advantages:…

  5. Jensen Harris just posted a walkthrough of how Microsoft prototype using PowerPoint. It’s almost identical to the way I’ve been doing it, although I prefer to build the entire UI from shapes and images before creating a detailed picture

  6. Done exactly the same thing myself in the past – I’ve found that if you try and go above the standard linking behaviour then users sometimes get confused as to what actually has been implemented and what has not (sometimes a problem if using other forms of mock-ups)

    We also used UltraVNC to allow the developers to watch multiple user desktops from a different room as they interact with the mocked-up system.

    Like you said in the Bob entry – the scroll button still works (as do the keyboard shortcuts) – but it is an effective and a very cheap way to prototype…

  7. jensenh says:

    Tom,

    We definitely use this technique for non-linear prototypes (that the reason for the second half of the walkthrough.)  It can be complicated to keep straight in your mind once you have a large number of slides, but we’ve found it easier than the alternative.

  8. Dan McCarty says:

    We’ve used Visio pretty heavily for years for our software mock ups, which has led me to a few observations:

    – Visio is great for raw screenshots

    – PowerPoint is better for moving around with invisible buttons and "action settings."

    – (Visio 2K3 might be better than our 2K2: according to the upgrade matrix it lists better VBA support for automation)

    – People don’t really care about the mock ups until you’ve actually written the software.  (I call this the baby rule: no one cares about the baby until you’ve had the baby.)  At that point everyone and their brother is all too willing to chime in what they like and (in most cases) don’t like about it

    – Using a powerful mock up tool like Visio, you have to be careful to to make something look too good.  Coding that gradient-filled, shadowed button with a perfectly-scaled icon and anti-aliased text is a lot harder than the 30 seconds it takes to create it in Visio!

  9. Christian Hagel says:

    We have used both Visio and Powerpoint. Usually we make the screens in Visio and make them interactive in Powerpoint.

    Things are quicker and easier to get nice (not pretty) & precise in Visio than in Powerpoint. We create shapes for our designs and share them in our group and make heavy use of background pages in Visio.

    If I could change just one thing in Visio 2K3, it would be the way you copy between pages. In Powerpoint, when you copy a shaoe from slide a to b, it is inserted at precisely the same position. In Visio it is just inserted in the center of the page. Visio has other quirks for UI prototyping, but generally works well.

  10. Tim Briggs says:

    I’ll chime in as the researcher and consumer of Jensen’s prototypes. We ran a lot of them in the iterative design stages.

    As some have pointed out above, unless everything works, you do run into people clicking some elements that might not be hooked up yet. It really wasn’t that problematic though. First, these were very interactive—we didn’t see many instances of participants becoming less interactive as the session progressed. Enough of their clicks resulted in some feedback. Second, editing the prototype was simple enough that if we saw a bunch of people click without seeing feedback, we could very easily adjust the file on the fly. (In some cases, we even had participants turn off their monitor while we remotely made the change from the other side of the one-way glass.)

    That said, paper prototypes still have a place in our world in the really early concept phases. Before we’re worried about mechanisms and layout, there’s nothing quite like watching people shuffle paper and rewrite labels to better understand how they might approach a UI.

    A final little tip we ran across, applicable to any early prototyping medium. Because it can be hard to ‘see’ a click when there’s no feedback (e.g. not everything is hooked up), we used a screen recording application that put a little starburst around the cursor which could only be seen on playback. It helped us see some things we might have missed in the live session and didn’t disrupt the user.

  11. Renato Almeida says:

    Simple enough tips but yet very powerful. Powerful to the point to make me ask: how far can you take this prototype to the developers and not let anyone misinterpret draft ideas put into the powerpoint? In other words, how do you find the point of equilibrium between accuracy and simplicity in the Powerpoint presentation?

  12. Kingsley says:

    I’ve used this technique before. I wish it was easier to do hyperlinks within Powerpoint presentations though – I’m sure you must have felt the pain. I wonder if you made it easier or treated it as a fringe case.

  13. Juan Leal says:

    We also use Power Point prototyping in our company (www.idealista.com).

    Honestly, sometimes we feel we should change to another software, but things like the one you mencioned above make us forget the ppt interface problems and keep on going 🙂

    Thanks for your post.

    Juan

  14. For those using Visio for the screen prototypes, you can add hyperlinks to a Visio drawing to switch to other Visio drawings. So it is possible to get an interactive display of a UI in Visio. (Visio is one of Microsoft’s secret products)

  15. Today, I’d like to share a few notes on a processes we’re using when designing UI features on the CRM