Workshop Title
Fake It Till You Make It: Rapid Prototyping Using Flash

Presenter
Philip Fierlinger (Xero)

This was one of the most fun presentations of the conference, mostly it addressed a task that I want to like, but find to be a pain: mocking up interfaces. Usually I just do this on paper, and don’t iterate much. Fierlinger showed off how he could effortlessly and visually throw together UIs in Flash. He’d do dozens of iterations a day, sometimes in the middle of user testing. It struck me as incredibly agile.

Interestingly, Fierlinger was barely using Flash at all: He was basically using it as a drawing tool with a timeline. The sweet spot he settled on between interaction and static mockups are what he calls “screenflows.” These are scripted interactions where the viewer is guided through the interaction. These are useful for testing the expectations of users, as requirements documentation for engineering, and as the first pass of a testing plan.

Click through to see the full notes on how he came to this process and all the places in the development cycles that it pays dividends.

Fake it Til you Make it: Prototyping in Flash

Inspired by seeing the Apple team prototyping the Quicktime in Director in the early 90′s. Did his first Director prototype for Groove Merchant, which landed his first big client, the Beastie Boys. Total prototyping time, including learning Director? Two weeks.

Now, of course, the software is even better. This talk will review a bunch of techniques out there and then he’ll go over the best workflow and techniques, in his experience.

Other Methods

• Paper Prototyping: Quick and dirty, but not quick enough and plenty dirty. It’s out of context, which makes paper prototypes difficult to evaluate (by users or even yourself.) Agreed.
• Wireframes: Can’t show interactivity, flow. Have too many blind spots. Create the worst type of production blueprints. You get a black-and-white document with a ton of footnotes. Function terribly as a requirements document, ultimately, because no one will read them. More of a problem in a large-org workflow than at Instructables.
• HTML Prototypes: Require significant effort expertise, too fussy, requires all this code wrangling. The worst part is that you’re now supposed to throw it away, but it looks like code that you can use. So you end up starting with this hack as production code. Agreed.

The Solution,

In Fierlinger’s opinion, it’s Flash:

• Like paper: draw it. Sketch out ideas quickly in low-fi or high-fi
• Like HTML: Code it up, if you want, add interaction and experience the flow. Minimal code required to move between “scenes.”
• Prototype anything: Drag-drop, sound, animation, video.
• Easy to edit: Re-usable objects, timeline, layers.
• Easy to share: Compatible in all browsers

Examples

1. Lo-Fi: Hierarchy, Words are UI, Flow
2. Hi-Fi: Refine Hierarchy, Emotional connection, Branding
3. Fully functional: Refine interactivity, “Real World” conditions. Necessary for novel UIs or experiences

Tori Amos: Fierlinger shows a site map that links to low-fi page prototypes. Columns, images, basic layout blocked. Page structure and information hierarchy established. You get a sense immediately what parts of the design might be missing or extraneous. Only takes a few hours.

Bed and Breakfast example: Higher-fidelity. Tabs changing via AJAX modeled. “God help you trying to do this with a bunch of footnotes on a wireframe.” Fierlinger shows us the prototype within FLash. There are just a dozen keyframes to model almost the whole site. Movies within the top structure can have their own timelines, allowing reuse.

TurnTable: Very interactive prototype. Color, sound, animations. Working prototype that actually modeled the flash application that ran on mobile devices. Challenge: with prototypes of this fidelity, users can easily run down ratholes, since the UI seems so complete. They can’t tell if what they’re seeing is an error in the prototype or an error in the design. One way around this (used here) is to have a scripted run-through of the functionality for more naive users.

Comcast: First shows wireframes with a mess of callouts. This was fine for the designers, but the exec team needed to be wowed aesthetically. So, a high-fi prototype is created. Again, the challenge is having the client understand what parts of the prototype to focus on. Again, a scripted demo was developed. This time with a mocked up mouse pointer that demos all the interactions on-screen.

Another approach to the scripted demo is the screencast; an actual video file with narration that shows the key interactions. These were then shipped along with the ample-rope-to-hang-yourself prototypes.

Summary of the problems:

• Illusion of many options, but shallow and incomplete
• Need to know what works
• Critical Path is all that matters, but giving the users acces means that there’s combinatorial effort to build and update the prototypes

The Best Solution: Screenflows

Focus on the critical path. It’s a slideshow simulation of someone using your site or app. It shows every step (all clicks and data entry) necessary to complete a task. You can Preview the experience – See and feel how everything flows together.

Fierlinger shows Xero, an accounting system. To start, the whole bucket was way too large. He shows a mockup of just one interaction. Just prototyping to get an idea of how different tasks might be accomplished. He could churn through 5-10 of these a day.

Another example of Reconciling Bank Transactions. This was a non-standard two-column UI (like a matching game; matches get taken off the pile.) The Flash prototype is, indeed, very good at conveying the basic idea and working out design issues.

Hundreds of iterations later (a week or two), the mockups all have real tabular data that the devs can use to create a test enviroment for QA.

When you get to visual design (you should avoid this like the plague early on; it distracts from all the discussions over functionality.) When you do, though, you’re often working with existing site elements. When you’re at this stage, Flash is awesome because you can just run Flash prototypes right on top of site screenshots. Flash has good tools built in to rip up bitmaps to make little interactive elements.

Fierlinger now shows some insanely detailed demos where forms are doing calculations and validation. His point is that it’s possible to go this far in Flash when absolutely necessary, and it’s still pretty lightweight.

User Testing

These screenflows are actually great for lightweight user testing. Fierlinger gives anecdotes where an expensive features (unconventional transaction reconciliation) would never have been built if the user testing didn’t show such a huge difference in usability.

Here it is, nuts and bolts. Basically, screenflows allow you to measure user expectations and how well your interactions match those expectations.

Start with a task: “You need to ____”

Now, Ask:

1. Where are you?
2. What will you do?
3. What will happen?
4. What happened?

Because Flash is so quick, they often revise the prototypes to correct for big issues even between testers.

How it Fits into the Production Cycle

Xero releases major features every 3-6 weeks. The Flash prototyping becomes the specification, so the documentation ends up being taken care of.

Fierlinger initially spent three weeks just using Post-it Notes to figure out the scope and elements of the product architecture. This Post-it board ended up becoming the beginnings of the database architecture.

Now, it’s live with thousands of paying customers. Now they rely on both customer feedback and user testing. They do the value/effort analysis that Instructables does all the time to prioritize features.

1. Whiteboard solutions: Identify root problem. Workflow, inputs, etc. 80/20 rule: no edge cases allowed.
2. Prototypes: Design, Evaluate, Iterate. Hundreds of iterations, for some features. Design the ultimate solution, then scale it back.

“If you’re using words to describe it, no one’s going to read it and everyone’s going to get it wrong.”

The prototype is the first test plan for QA and also the basis for generating user help documentation.

Now, use the prototypes to promote. Put them on your blog, create videos. Videos are great for showing you where the holes are in your offering. If you can’t screenflow your product in a few minutes, you know you’re missing something.

Related Posts:

• Analytics 2.0 (April, 2007)
• iPhone Accessibility (September, 2009)
• Empirical Design Using Analytics (April, 2007)
• Wireframe as Marketing (April, 2009)
• “A Group is its Own Worst Enemy” (November, 2008)

This entry was posted on Tuesday, April 14th, 2009 at 5:53 pm and is filed under coding, infoviz, instructables, technology. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.