Awesome, awesome, awesome. Well presented, well structured, and the kind of thing that makes you think “shit… why don’t I do this all the time”, because it’s so fast and simple to do, but so so effective because of that simplicity. I highly recommend to any NZ designers out there to get along to the next one.
Today we presented to a client and I showed a Flash prototype instead of a boring old static set of wireframes. In a few words - it went extremely amazingly well.
Alexa Andrzejewski from Adaptive Path is an advocate of doing prototypes using Flash. She’s written a tutorial on Boxes and Arrows and also gave a workshop (here’s an in-depth PDF tutorial from that workshop).
Woot!
Alexa is a proponent of Flash prototyping for many of the same reasons as me. Her tutorials have a lot to offer - they provide a good intro to Flash and help explain some of the fundamental concepts that make Flash special.
Alexa’s method of Flash prototyping shares some common characteristics with my screenflow method of prototyping, but unfortunately she makes them overly complicated by making them interactive and she still relies on conventional specs.
Huh?!
For me, the prototype is the spec. If you feel the need to write specs then you should really demonstrate the functionality in the prototype. Very few people read specs and when they do everyone has a different interpretation. A huge reason for making prototypes is to eliminate the confusion and ambiguity of written specs!!
In addition, her prototypes are limited to a single, linear path like my screenflows (which is a very good thing), but oddly she makes them ’interactive’ with clickable buttons and links. Her prototypes require you to click on specific items to progress to the next screen. That makes her prototypes harder to use, harder to build and harder to edit, yet it offers no design advantages over screenflows.
A better way
I definitely recommend checking out her tutorials, but I strongly believe that my screenflow method is much easier, a better way to generate design ideas and a better way to share those ideas.
A new prototyping tool called Balsamiq Mockups was recently launched. Have a look at this demo video…
…and then have a play with it. It’s built in Flash and borrows some core concepts from the Flash authoring tool. It’s primarily a library of common UI elements that are easy to combine and mockup a screen layout. The hand-drawn look of the widgets is useful to convey the purpose of a mockup - it’s a work in progress, not a finished design.
Unfortunately, you can only build static pages. There’s no way (at this point, that I could see) to build a simulation of a web site or application - moving thru different screens and different states. So as a prototyping tool it’s actually very limited.
This tool might be helpful to mockup a single screen, but building web sites and apps isn’t about screens, it’s about experiences.
Last night’s workshop went really well. There was a nice mix of people with design, development and business backgrounds. I’m impressed that everyone wanted to stay around an extra hour and would have stayed even longer if I kept going!
I showed a wide range of examples to demonstrate the variety of different ways to build and share Flash prototypes. Then we jumped into Flash, learning the essential tools (drawing, timeline, layers) and built some simple prototypes on the spot.
Someone asked about a good book for learning Flash and I highly recommend the Flash Visual Quickstart guides by Peachpit. It’s by far the best guide to learning the basics, explained in a really simple but comprehensive way.
I’m sharing my course notes here. This will make most sense to the people who attended, but it could be useful even if you didn’t go.
Why prototyping
Fast, cheap way to create, evaluate and improve design solutions
Involve and share with clients, investors, users, developers
A prototype should speak for itself - be the specs doc
Can even use as production-ready design
QA reference
Why Flash
Paper prototyping
Great for sketching ideas
Lacks accurate scale and context: on-screen is important for context
Not so good for evaluating complex interfaces
Terrible for sharing
Wireframes (printed docs)
Relies on words - words are the worst way to create and explain design solutions
Impossible to follow the flow - leaves too many gaps
Everyone interprets differently
Can’t test with users
HTML prototypes
Too much effort, too real
HTML + CSS needs to be well formed to be functional
Less agile. Less opportunity to explore ideas.
It feels finished. It’s not supposed to.
Too much time & effort invested in the build, so it becomes your code base and design template by default
Flash
Like paper - Draw it, sketch out ideas very quickly. Lofi, hifi.
Like HTML - Code it up. Interact with it. Experience the flow.
Can prototype anything: drag-drop, sound, animation, video.
Easy to edit. Re-usable objects, timeline, layers.
PIXAR Our prototype exists in the same medium as our final product. This allows us to judge it by the same standards that the final film will be judged.
I think this is an important lesson for a User Experience Designer to understand - paper prototypes and ethnographic research are great, but if you’re trying to build a prototype that you want use as a blueprint, it should exist in the same medium as the final product.
AP At Adaptive Path, we’ve been moving towards this approach ourselves. As the experiences we design get necessarily more complex, it’s not sufficient to design them as static sketches, and hand them off to others to implement. We’ve been creating richer and richer prototypes, not as an end-product of design, but as a step in design exploration. If you’re going to design for experience, you’ve got to understand what it means to physically engage with your design as quickly as possible, and be prepared to change those designs as need be.
PIXAR We know we’ll fail a lot; if you don’t fail you’re not doing anything new. We’d much rather fail with a bunch of sketches that we did (relatively) quickly and cheaply, than once we’ve modeled, rigged, shaded, animated, and lit the film.
This gets to the heart of why I create rapid prototypes in Flash. Rapid prototyping is the best way to explore and test ideas without investing major resources or becoming too committed to a particular solution.
Flash, in my experience, is the best tool because it can perfectly simulate the final experience, unlike paper prototypes or even wireframes. It’s also much easier, faster and less distracting to produce than HTML prototypes. HTML prototypes may provide a more accurate representation of the final product, but that’s exactly the problem - they require nearly the same level of effort as building the final product - you end up focusing far too much time and effort building it, instead of exploring a broader range of options.
Flash lets you combine the agility of sketching on paper (it’s a drawing tool) with the technical precision of delivering an on-screen experience (it’s a scriptable piece of software).
Back in 2000, I designed and built a Flash prototype for a wireless handheld concept based on a new technology called 802.11 (Wifi wasn’t branded yet). There are a lot of really powerful ideas in that demo that have just come to fruition with the iPhone 3G - specifically location-based social networking and media sharing over handheld devices.
A lot of those ideas can be seen in action on the video below which shows the new Last.fm player for the iPhone. It sports a UI that’s not so dis-similar to the one I created.
While there’s a fairly long lag time between concept and reality in this case, it’s pretty exciting that the concept can be convincingly demonstrated before the technology has even arrived.
