Tell me more ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.
up vote 4 down vote favorite
1

Let's say we have a web application that will have, more or less... hmm... 500 different pages. Some of them quite similar.

For the sake of user centred design, should I ask the design team to produce a high fidelity prototype of those 500 pages?!

If so, how to accomplish that on an acceptable workflow process? I mean, it is important, even for developers, to have a detailed application prototype, true, the more detailed, the better, but we can't say:

"Dear developers, please wait while I explore designers on a nonsense way so that hey can develop high fidelity prototypes so that I can then pass those to the user, and then back to designers for revision, and finally to you so that you can finally develop interactions (js) and look (css) on a user centred way".

Or can I ? :)

I mean: Is a high fidelity prototype based on ALL pages or some of them ? Is there a way (workflow) to make this without:

a) developers have a long wait until they can finally develop.

b) developers have to remake the code because of different proposes found during the process.

Please share :) I'm starting, I have a lot of questions... and hmmm. :) I'm a little lost while trying to see the big picture here.

share|improve this question
3  
Why are you making high-fidelity prototypes as opposed to paper prototypes or low-fidelity prototypes? – Robert Harvey Apr 10 '11 at 19:53
I'm not. But I intend to do it, because I believe the result will be more accurate when we use colour, shape, well hierarchical structure... things that don't normally co-exist on low-fi prototypes. – MEM Apr 10 '11 at 23:15
1  
OK. Just make sure you're prepared to create the application exactly as the high-fidelity prototypes specify. Otherwise your stakeholders will look at the final application and say, "This isn't what the prototypes looked like." Using low-fidelity prototypes allows room for change, because the stakeholders understand that the prototype is not representative of the final product, and will help them focus on function rather than form during the usability studies. – Robert Harvey Apr 10 '11 at 23:37
2  
High-fidelity prototypes don't necessarily lead to stakeholders who demand the final app works the same way as the prototype. I hear this a lot but I'm starting to believe the only reason this even happens is because of poor communication by the design/dev teams. Manage your expectations correctly and no client/stakeholder will be surprised by your final app differing in some ways from the prototypes. – Rahul♦ Apr 11 '11 at 1:05
It's worst then that.For my experience, they wouldn't even notice. And if they do, I tend to justify them. And if they refuse my justification I told them, ok, but we don't assume the risk. But we do it. (and they normally understand). So, Indeed. I do believe we have two issues here. Should we use high fidelity prototypes to test, instead of low ones? Of course! They are more accurate. Do we have do deal with client expectations in order for them to realize that you are testing usability and not with some minor details? Indeed as well. So we must do both. :) I can regret this, let's hope not. – MEM Apr 12 '11 at 5:07

2 Answers

up vote 5 down vote accepted

Find ways to group all of the individual UI scenarios into common use cases, and then develop mini-prototypes that represent each of these common use cases.

It wouldn't surprise me if that gets the prototyping down to 100 pages or less.

share|improve this answer
Indeed. :) I will have a look on that. – MEM Apr 10 '11 at 23:17
up vote 1 down vote

What do you intend to use the hifi prototype for? What do you intend to learn by testing it?

In my experience it is pretty sufficient to restrict hifi prototyping in large or highly complex projects to critical parts of all possible interaction flows. Critical in that sense would be mostly the ones where lower fidelity (either in the visual or in the functional dimension or in both) is not sufficient for communicating and/or testing a design. You might also want to try to identify VIPs – very important patterns ;-) – in your interface and build realistic but restricted use/test cases around those. (Remember that you need to do the same for usability testing anyway – tests that do not focus on measuring specific things are mostly useless).

In short: try to break your full-fledged hifi prototype into several smaller proof-of-concept prototypes with sufficient fidelity for each and extrapolate the insights gained from those.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.