This technique, building prototypes on paper and testing them with real users, is called low-fidelity prototyping or “lo-fi” for short. Value is not always gained in practice.
Paper prototyping is potentially a breakthrough idea for organizations that have never tried it, since it allows you to demonstrate the behavior of an interface very early in development, and test designs with real users. Lo-fi prototyping is a technique that can dramatically increase quality; it allows a team to try far more ideas than they could with high fidelity prototypes. To get a good idea, gets lots of ideas.
The problems with HI-FI.
· Hi-fi prototypes take too long to build and change: you can´t evaluate an international design until after it is built, but after building, changes to the design are difficult. Paper prototypes, on the other hand, are extremely fast to develop and the technique is very easy to learn.
· Reviewers and testers tend to condiment on “fit and finish” issues: with a slick software prototype, developers easily become obsessed with the prettiness power of a good tool, and spend their hours choosing colors instead of coming up with new ideas.
· Developers resist changes: they would be less hesitant to suggest redrawing a sketch that looks an hour to create.
· A prototype in software can set expectations that will be hard to change.
· A single bug in a hi-fi prototype can bring a test to a complete halt: even with the coolest of high-level tools, we all know how hard it can be to get all the bugs out of a program.
A Trojan Meme.
A meme is an idea, the mental equivalent of a gene, and selfish ones try to replicate themselves in as many minds as possible. Within days of designing an interface, they saw exactly how their work was perceived by people just like those who will eventually be using their product. Two important laws: “know your user” and “you aren´t your user”.
Lo-fi prototyping works because it effectively educates developers to have a concern for usability and formative evaluation, and because it maximizes the number of times you get to refine your design before you must commit to code.
Building a Lo-Fi prototype.
1. Assemble a kit:
o While, unlined, heavy paper that is bigger than letter size.
o Hundreds of 5-by-8-inch cards.
o Various adhesive.
o Various markers.
o Lots of sticky note pads.
o Acetate sheets.
2. Set a deadline.
o Obligate yourself so you are forced to take a preliminary crack at every important aspect of your problem.
3. Contract models, not illustrations.
o Make what you need to simulate menus dropping down, dialogs propping up, selection highlights and so forth.
Preparing for a test.
1. Select your users: you should do enough user and task analysis to understand he people who will b using your software, their educational and training background, knowledge of computers, their familiarity with the domain, typical tasks involved in their job, and so on.
The people testing your prototype are the same people who will be using the final product. You can often get by with, “surrogate users”, people who fit the same profile as your actual clients, but free from whatever association that prevents you from testing with the clients themselves.
2.Prepare test scenarios: write a set of scenarios, preferable drawn from task analyisis, describing the product during use in a typical work situation. Design your prototype to support a few of these scenarios.
3.Practice: conduct several dry runs before you test with people from outside your team.
Conducting a test.
· Greeter: welcomes users and tries to put them at ease.
· Facilitator: giving the user instructions, encouraging them to express his or her thoughts during the test, and making sure everything gets done on time.
·Computers: on team member acts as a computer.
·Observers: the rest of the team members quietly take notes.
Evaluating results.
Recommended changes to the design. Constructing the revised prototype becomes a process of taking each component, and following the recommendations that were stuck to it.
Try it.
Hix enter the first lo-fi exercise with skepticism. After trying it they invariably say something to the extent of “I can believe how much we learn”.
Paper prototyping is potentially a breakthrough idea for organizations that have never tried it, since it allows you to demonstrate the behavior of an interface very early in development, and test designs with real users. Lo-fi prototyping is a technique that can dramatically increase quality; it allows a team to try far more ideas than they could with high fidelity prototypes. To get a good idea, gets lots of ideas.
The problems with HI-FI.
· Hi-fi prototypes take too long to build and change: you can´t evaluate an international design until after it is built, but after building, changes to the design are difficult. Paper prototypes, on the other hand, are extremely fast to develop and the technique is very easy to learn.
· Reviewers and testers tend to condiment on “fit and finish” issues: with a slick software prototype, developers easily become obsessed with the prettiness power of a good tool, and spend their hours choosing colors instead of coming up with new ideas.
· Developers resist changes: they would be less hesitant to suggest redrawing a sketch that looks an hour to create.
· A prototype in software can set expectations that will be hard to change.
· A single bug in a hi-fi prototype can bring a test to a complete halt: even with the coolest of high-level tools, we all know how hard it can be to get all the bugs out of a program.
A Trojan Meme.
A meme is an idea, the mental equivalent of a gene, and selfish ones try to replicate themselves in as many minds as possible. Within days of designing an interface, they saw exactly how their work was perceived by people just like those who will eventually be using their product. Two important laws: “know your user” and “you aren´t your user”.
Lo-fi prototyping works because it effectively educates developers to have a concern for usability and formative evaluation, and because it maximizes the number of times you get to refine your design before you must commit to code.
Building a Lo-Fi prototype.
1. Assemble a kit:
o While, unlined, heavy paper that is bigger than letter size.
o Hundreds of 5-by-8-inch cards.
o Various adhesive.
o Various markers.
o Lots of sticky note pads.
o Acetate sheets.
2. Set a deadline.
o Obligate yourself so you are forced to take a preliminary crack at every important aspect of your problem.
3. Contract models, not illustrations.
o Make what you need to simulate menus dropping down, dialogs propping up, selection highlights and so forth.
Preparing for a test.
1. Select your users: you should do enough user and task analysis to understand he people who will b using your software, their educational and training background, knowledge of computers, their familiarity with the domain, typical tasks involved in their job, and so on.
The people testing your prototype are the same people who will be using the final product. You can often get by with, “surrogate users”, people who fit the same profile as your actual clients, but free from whatever association that prevents you from testing with the clients themselves.
2.Prepare test scenarios: write a set of scenarios, preferable drawn from task analyisis, describing the product during use in a typical work situation. Design your prototype to support a few of these scenarios.
3.Practice: conduct several dry runs before you test with people from outside your team.
Conducting a test.
· Greeter: welcomes users and tries to put them at ease.
· Facilitator: giving the user instructions, encouraging them to express his or her thoughts during the test, and making sure everything gets done on time.
·Computers: on team member acts as a computer.
·Observers: the rest of the team members quietly take notes.
Evaluating results.
Recommended changes to the design. Constructing the revised prototype becomes a process of taking each component, and following the recommendations that were stuck to it.
Try it.
Hix enter the first lo-fi exercise with skepticism. After trying it they invariably say something to the extent of “I can believe how much we learn”.
Inicio:
