Comics and Keynote: Testing UI Flow in Wireframes
A couple years ago I learned from Paul Hibbitts a way of using slideshow applications for testing the flow and completeness of a design. Typically, I use Apple’s Keynote for this, though PowerPoint or Impress can work as well.
The essence of the method is to put all screens and all their states into sequences that follow a task or scenario. Paging through that sequence, imagining or even pointing to screen elements as you go, brings missing pieces and potentially confusing points into focus, often with shocking speed.
I’ve used the technique in a number of projects since then, always with good results. But in describing it with others I could rarely put my finger on why it worked so well for spotting what was otherwise missed when just looking at the wireframes on their canvas.
Yesterday at lunch I was talking up this method once again, but this time I hit on what I think explains its effectiveness by drawing from Scott McCloud’s Understanding Comics.
I hope you’ve heard about Understanding Comics. If not, I can sum it up as a landmark exposition of the history of comics and the cognitive and perceptual mechanisms that give them their expressive power. In one of the early chapters, he talks about the space between adjacent frames and how important it is. When a reader’s eye moves from one frame to the next, the imagination is recruited to compute the meaning of the difference between frame one and frame two. The following frames from the book (excerpted from the publisher’s website) explain this effect with respect to the passage of time:
![]()
It also works with changes in spatial position and perspective. Our busy minds are very good at filling in the space between two things, and as designers with the entire model for a task or an entire application in our heads, we need to fill in those gaps as we work. The danger in looking at multiple wireframes at the same time while thinking about flow is that we can fill in the gaps between with our implicit understanding, and miss what won’t be obvious to people using the interface, working without the designer’s understanding.
Enter the presentation apps. By assembling a sequence of screens, one per slide, I can page through with full focus on one screen or state at a time. Pointing to the interface elements one would use to get to the next state and then advancing to the view of that next state doesn’t trigger that fill-in process that McCloud describes. And lo, the gaps reveal themselves.
Stepping it Up
This method is also good for presenting wireframes to clients and teammates. When taking that step, I spend the extra time to create clickable objects on top of certain interface elements, hyperlinked to the resulting slide so that the flow can be shown more interactively or explored without guidance.
In these cases, it can also be helpful to insert text slides that describe the scenario that the following slides address, as well as any notes that supplement the process. I keep that text on its own slides, completely isolating the interface wireframes so that there’s no unconscious interference in the simulation from the context of the design process.
Finally, a word on slide transitions: they really don’t belong in this use of a presentation app with one big exception: where they transition mimics the actual transition that occurs on the interface. My canonical example is when studying the flow of an iphone app design, where sliding transitions create a spatial organization model that places summaries on the “left” and details to the “right”. Otherwise, my advice is to forego the eye candy and let the slides do the talking.
Leave a Comment