Duration: 31m | 16 MB
Recorded: April, 2010
[ Subscribe to our podcast via
←This link will launch the iTunes application.]
[ Subscribe with other podcast applications.]
[ Transcript Available ]
Podcast: Play in new window
| Download (Duration: 31:04 — 16.0MB)
Prototyping is an iterative process. You generate design concepts. You test them. You discover what works, what needs improving, and opportunities for new ideas. Then repeat. Prototyping your design will get your team and your stakeholders to talk about it. They’ll use it, touch it, walk through it at a point in time when you can make changes inexpensively.
Last year, Todd Zaki Warfel, a recognized leader in the design-research and usability fields, joined us for a UIE Virtual Seminar: A Practitioner’s Guide to Prototyping. In it, Todd explores his Eight Guiding Principles for prototyping. These principles are the foundation for more effective prototyping, regardless of the method and tool your team uses. Also, Todd’s principles are sure to test and improve your design whether you’re a seasoned prototyper or just getting your feet wet.
Todd is a Pied Piper in the user experience design world. We’ve seen it! At conferences, everyone wants to catch up with him to see what he’s doing and what he’s thinking about. He’s loaded with charisma! Oh, and he’s a pretty good designer, too. He thinks about this technique a lot, so we’re thrilled to have Todd’s UIE Virtual Seminar as part of our UIE User Experience Training Library.
Here’s an excerpt from the podcast.
“…For us, we actually use the prototypes as our specification, for the most part. Now, there are some things that you’re not going to see or that maybe won’t be self-evident in the prototypes. Some of the business rules or back-end functionality may not really be clear in the prototype.
What we found, and this is actually one of the reasons why we turned to prototyping and away from an older, traditional method of wire frames with written specification documents. What we found is that, since the prototype, basically, is show and tell and allows you to see the story as well as tell the story and actually play around with the systems, it’s much more tangible. When we do prototyping, we find that actually, any specifications that have to be written are dramatically reduced.
So, for example, in my book there is a case study from a gentleman over in the UK and their old, traditional system was: do some wire frames, write a 200-page specification document and deliver it out to the development team. And they shifted over to using more of a prototyping model. And for similar systems that they used to have to write a 200-page spec document, they found themselves delivering the designs, with specifications, about three times as fast and that the specifications went down to 20 pages instead of 200.
And so they’re essentially using the prototype as the bulk of the specification and then writing some supplemental documentation to describe things that aren’t self-evident, like back-end business rules and maybe some technology-type stuff. And we’ve done a very similar approach.
So, a lot of times, what we’ll do is prototype out maybe a core flow, plus maybe some error sessions and maybe some success screens and that type of a thing. But, we won’t typically prototype out every single scenario. We’ll kind of do the 80-20 rule. So, here’s 80 percent of it prototyped out. You can pretty much see how it works. And then any additional, supplemental information that may not be self-evident in the prototype, we’ll either write some documentation, or in a lot of cases actually, our clients just take the prototype and then their internal team basically writes that spec…”
If you thought that was interesting, you’ll also hear Todd address these questions:
If you’re prototyping only some of the functionality, how do you talk about the rest of the functionality that isn’t in the prototype such that the team knows how to fill in the gaps?
How are you able to do usability testing when the prototypes are not refined, or they’re missing pieces?
We often talk about how prototyping lets you reduce risks, but does it give you an opportunity to actually take risks?
Do the prototypes have to be made with the same technology that you’re going to use in your production system, or are there actually advantages to doing them in something completely different?
If you have any questions or thoughts on prototyping, please feel free to share them in the comments section below.
This entry was posted
on
Friday, January 7th, 2011
at
2:28 pm
and is filed under
Design Deliverables, Design Documentation, Design Process, Podcasts, prototyping, SpoolCast, UIE Virtual Seminar
. 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.
Tweet