Comments on Integrating Prototyping Into Your Design Process

Mark Kraemer — Thu, 29 Oct 2009 14:32:24 GMT

I explained these three dimensions a bit more eloquently commenting on this story a few years ago:
http://boxesandarrows.com/view/real_wireframes

Fidelity for prototypes can be roughly measured by 3 attributes: visual detail, functional depth, and technical reuse. The obvious trade-offs are the more realistic any of these attributes becomes, the most cost there is involved. The effort for including visual detail on each page I think is discounted above when you consider the cost of maintaining that consistent style over multiple pages, unless you increase the technical reuse attribute as well (CSS) which in turn provides more cost.

I don’t think there’s a single silver bullet / best practice for how to prototype for every single project. One should consider who the prototype is for (investors? the client’s business analyst? end users in usability testing? your developers?) Each group will have different needs in each of the 3 attributes. Design your prototype to meet the needs of these interim users and you’ll find the right balance of cost/value for visual detail, functional depth, and technical reuse.

Mark Kraemer — Fri, 16 Oct 2009 01:54:12 GMT

Nice article. The graphic does a good job to comparing different prototyping styles.

When I discuss the same idea, I add another dimension of “Technical Reuse” to help with the argument of rework and throw-away code.

Take a look if you’re interested in the topic at the presentations posted here:
http://markup.thekraemers.com/2006/09/14/links-from-the-h…

Jonathan Baker-Bates — Tue, 29 Sep 2009 22:30:20 GMT

@uxdesign.com: Not sure what you mean – can you elaborate?

uxdesign .com — Sun, 27 Sep 2009 23:48:32 GMT

I’m happy to see that prototyping seems to be increasing. Yet I am still surprised, despite praise lavished on axure, protoshare and the like, at the dearth of sufficiently dynamic web application “prototyping” tools.

“Prototyping” a website takes little less time than creating one. Yet, even nearing 2010, there is rabid hunger for a good WEB APP prototyping tool that can mimic, if not actually provide, behavioral objects that are based on common js frameworks. As it is, creating even simple interactive prototypes is time consuming. This, I’d guess, is why you’re “prototyping isolated interactions” for testing?

Jonathan Baker-Bates — Sun, 27 Sep 2009 23:49:17 GMT

Just as an aside on this: Obviously, some types of interaction can be quite time-consuming to create to a level of fidelity that will get your initial design concepts across, particularity if you want to winnow down a number of variations on those designs. Over the last year or two, I’ve been surprised how the use of video can save a lot of fiddly work in this regard. So, when I want to get some feedback from colleagues about different approaches to a complicated interaction, I only work them up to the extent that I can then fake a smooth usage scenario in a screencast. I then send this out to colleagues (usually with some narration on the soundtrack as well as just the Boards Of Canada), who give me good feedback after watching it at their leisure. It takes a bit of practice to do (not least to get over hearing your voice stumble over your own words), but after a while it’s easy enough.

Nice article by the way.

Lauren Bopp — Fri, 07 Jan 2011 19:52:55 GMT

Thanks for the article, very thorough. Here at Oshyn we’re often brought on board as the development partner, so we don’t get the opportunity to work through building the UX via prototyping. However I think prototyping, or at least using a lot of the prototyping tools out there like Axure RP and Protoshare, can add a lot of value for the developers as well by more closely aligning written requirements with what the client expects the final experience to look and feel like. In fact, you inspired me to write my own blog post about it!

http://www.oshyn.com/_blog/General/post/Using_UI_Prototyp…

Richard Warzecha — Wed, 23 Sep 2009 22:42:07 GMT

Fred, great article. I really like how you emphasize finding the appropriate level of prototype fidelity for the goal or, as you say early in the article, “how you can use them to choose the most effective prototyping method for the questions you need answered.” That’s perfect.

You had me all geared up, then, to see you match up sample questions that need to be answered with the appropriate level of prototype fidelity. You started that with the Low Visual and Low Functional Fidelity prototype which you mentioned should help with questions like: “Does the system have all the features required to support the user’s goals?” or “Does the workflow make sense at a high level?”

Why not carry that same matching of questions to the other prototype levels? For instance, the Low Visual and High Functional Fidelity prototype level should be matched with questions like: “How do I get stakeholder buy-in to proposed UX design direction?” or “How do I include a functional example to the pile of spec docs I’m handing over to the development team?”

I think that’s all coherent, and helpful.

I also wonder at times how much your audience often dictates what kind of prototype you are best using, particularly when using it within internal settings. Some people just can deal with or accept some types of prototypes over others. This is neither good or bad, just the way it is sometimes.

Andrea Fidel — Wed, 23 Sep 2009 19:50:14 GMT

Fred,
Nice job on a very comprehensive post regarding the different levels of wireframing that should be incorporated into the design and development process. As mentioned, there are many methods and tools out there that can help accomplish these goals; it is all about finding the tool/method that is right for you/your company and the project at hand. Not every client needs a full-blown prototype, but some projects require extensive user testing. In your latest comment, you bring up a good point; just because you are seeking feedback from all the project stakeholders does not mean you need to listen to everyone. Additional feedback and perspectives can be quite valuable, but it can also be cumbersome and counterproductive, as you note. It is a good idea to take all the feedback into consideration, but also have a main decision maker who can give the final word.

This article is a great resource! (and +1 to Nicole’s comment.)

Cheers,
Andrea
@ProtoShare

Fred Beecher — Fri, 07 Jan 2011 19:39:40 GMT

Chris: You created your OWN prototyping tool? Wow, that is *very* impressive. And you’re right, tool agnosticism is really important. I’m not a great coder, so the HTML approach you take would be really difficult for me. I’m a huge Axure fan as it meets most of my needs when it comes to flexibility. It doesn’t have built-in commenting ability though, but we usually walk through our prototypes face-to-face with the client & collaborators, so it’s not hugely important for us.

Zack: What Nicole said. : )

Dariusz: I’ve seen the same sort of thing you have, large organizations adopting Axure & other tools to fix communication problems between BAs & developers. The problem with that is, though, that there’s a big user experience design shaped hole between those two groups that no tool can fix. I think, though, that adopting a tool might make that hole a little more obvious… even to people who aren’t accustomed to seeing it.

Nicole: That is a *killer* idea. How come it’s not an article on B&A yet? Or an IA Summit presentation? Hint hint. : )

Henry: Yeah, ForeUI’s “skinning” concept is really killer for iteratively upping both the visual & functional fidelity of your prototypes. I have to admit though… I’d like to see that functionality added to Axure. : )

Brian: Yeah, you’re right. The two things I use prototypes for are testing & communicating. We like to present our prototypes to stakeholders as a group as we did in the old flat wireframe days. Stakeholders get it much more quickly though when they see it moving around. One thing I’ve run into lately, though, is that going too quickly to prototyping within consensus driven organizations (where EVERYONE has to have their say) can lead to a lot of re-work. In that situation, I’d recommend getting EVERYONE together to talk about their concerns first and then document them. Then when you show them your prototype, you can speak to aspects of it that address the concerns they brought up.

Brian Cassidy — Wed, 23 Sep 2009 22:39:04 GMT

Great breakdown of different approaches of obtaining valuable feedback from users. One thing I might add, which you elude to is the quickness of the turnaround of this feedback back to the various stakeholders, as well as gaining agreement of what to do with the feedback. The first point is key to demonstrating the effectiveness of injecting user feedback back into the design process loop but the feedback needs to be reported quickly enough to be considered, especially in an agile methodology. The second point of “gaining agreement” is important to getting that commitment to the prototyping process. There’s nothing worse than building a prototype, recruiting users, conducting the test, creating a report, etc… only to hear, “well, we’ll have to take care of those problems in phase 2,” when we all know that phase 2 never happens.

Henry Mark — Wed, 23 Sep 2009 14:34:31 GMT

Good article Fred, I totally agree with the “multidimensional fidelity” concept. We’ve used almost all kinds of combinations, and as you mentioned, they match different requirements. We used to create prototypes for the same product but with different fidelity combinations, it double the workload but it worth it. Recently we discovered a prototyping tool named “ForeUI”, I think its design conception is quite close to the “multidimensional fidelity” concept: it makes prototype skinnable so that we can move in the visual fidelity axis freely; it can export prototype to static image or PDF, and also be able to export as DHTML (which is interactive), thus we can move in the functional fidelity axis as well. We like ForeUI very much since it save our time to create many prototypes for different fidelities.

Nicole Netland — Tue, 26 Jan 2010 16:08:50 GMT

Great post Fred. Too much of the time the decision on level of fidelity comes down to “what can we get done” without consideration for matching it to the intended goals.

Zack, has your company considered building up an online community of existing customers that can be engaged to provide feedback on concepts? They can be rewarded for their participation with discounts or other material rewards, but sometimes the idea of having an “inside voice” is reward enough.

Dariusz Grabka — Wed, 23 Sep 2009 20:21:54 GMT

Thanks for the article Fred. I agree very much that in organisations with waterfall methods (or remnants of waterfall methods), vetting ideas with prototypes of all levels of fidelity is very valuable.

In waterfall environments the cost of barking up the wrong design tree is extremely high, so the idea of iterating a few designs amongst the design and stakeholder teams typically receives warm feedback. This is especially true if the UX, BA, or design professional has the ability to crank out some functional options. This is where tools such as Axure, and other tools that facilitate “highly functional” prototypes, are very valuable.

One problem with waterfall structures is not that there’s no -desire- for user feedback, but that the viable opportunities for it tend to be limited to requirements gathering. Introducing new places to formally accept end-user feedback (such as a prototype vetting phase of design) may not be a hard sell for the organisation.

Thanks,
D$

Zack Perry — Wed, 23 Sep 2009 13:11:18 GMT

This is a great article. I work in an innovation department were we constantly are producing conceptual models that are low fidelity, low functionality. Once we start working through our design process we narrow these into either low fidelity paper wireframe prototypes or low fidelity interactive prototypes. The one thing we constantly struggle with is testing of these. We are inside of a large fortune 500 company so to actually talk to existing customers is a pain. Any advice on how to build a database of test users that we can call up for quick test of a function? And advice on how many users do you typically talk to around validating a function…..

Christopher Butler — Wed, 23 Sep 2009 22:36:55 GMT

Fred,

This was a great overview. I completely agree with you that the point to emphasize about prototyping is not the tool itself, but the way that prototyping allows the team to focus on particular decisions related to information architecture without being distracted by issues of visual design. We’ve been prototyping in this way, the “Low Visual and High Functional Fidelity” way, for almost a decade now. We created a proprietary ‘grayscreen’ prototyping tool that we use to quickly build clickable, HTML prototype sites. Each page can be assembled either with stock generic content, like formatted lists, images, etc., or can have custom HTML placed in the content area. We use the latter approach most, which at first glance seems pretty low-fi. However, I’ve found that the simple HTML approach keeps us (not the client) focused on the basics rather than getting caught up in an unnecessary focus on ‘elegance’ and styling. Also, having the page layouts and functionality created with HTML allows us to make quick changes on the fly while we meet with our clients, rather than having to conclude our reviews, make changes, and then reconvene at a later time. All in all, the “Low Visual and High Functional Fidelity” approach enables a faster and more efficient process.

There are some cases, though, in which a higher visual fidelity has been necessary. We usually won’t go beyond the “grayscreen” visual scheme, but we might get pretty specific with things like relative text sizes if the particular project might benefit. For example, in designing a business news site, we employed very specific type styles in the prototype so our designers could understand how the extremely dense news landing pages’ content was organized.

I wrote a blog post (http://www.newfangled.com/newfangleds_iterative_website_p…) back in April in response to watching a video of David Kelly, founder and CEO of IDEO Product Development, who said about prototyping that “You don’t find anything out until you start showing it to people.” One point that I emphasized was how important capturing feedback is. We have a commenting system built in that allows clients, project managers, designers and developers to contribute direction and feedback in context on a page by page basis. This is often essential for any one of our team members being able to properly interpret the prototype.

- Chris