Objectives
- To have a viable testable prototype.
- To plan an evaluation that would help improve your design.
These two go together because the prototype is developed to support a specific evaluation. It's not just an unthoughtful attempt to implement the entire system in way too little time! You choose what to make available in interactive form so that you can test interaction with it. What to do
Prototyping
Once you have adjusted your physical design based on user feedback,
you may construct a testable prototype. A prototype is anything that
users can actually interact with to test your design. You will need
to make some choices. What do you think you need to test the most? The visual design? The navigation? The interaction design for particularly critical or frequent use cases or scenarios? Then decide what kind of prototype will support this testing. Will it be a horizontal or vertical prototype?
Low or high fidelity? Tell us which you chose and why.
There are many methods for protoyping. I suggest you consider one
of these three:
Web-based, Multimedia or Hypermedia mockup (a good general choice): A tool such
as Director or Dreamweaver is used to construct an interface. You
can make a "scenario machine," which implements enough
functionality to enable enactment of one scenario (a vertical prototype);
or you can design all screens of the system and enable navigation
through them to test navigation (a horizontal prototype, based
on UCD's content model); or you can do a combination of these.
Software implementation (only attempt in larger groups and if you have at least one skilled programmer) : Implement just enough
of the system to test some aspect of it, using a rapid prototyping
tool that enables quick construction of a GUI. Be wary of getting
into more than you have time for.
Paper prototype (best for single-person projects where you don't have strong programming or development skills): Make a paper interface along with precise rules for how that interface behaves based on user actions. The paper can be manipulated to reflect user actions. For example, if a user pushes a paper button, you can quickly reconfigure the paper to show what the screen would look like after the button push. You must have clear specifications of how the prototype is updated in response to user actions.
The prototype should be taken far enough to be testable by users.
Evaluation Plan
All groups are required to do user testing as
described in Chapter 14 and the lecture of April 18th (you will need to read ahead).
Consider the following in your planning of user testing, and include a description of how you will address these:
- Usability specifications: what measurable usability objectives
are you trying to achieve?
- Population: how do you obtain representative users?
- Task Script: what task(s) will you have them do, and why were
those tasks chosen?
- Roles: if there is more than one of you, what role will you
each take on in the testing? (timekeeper, recorder of errors and
task times, taking notes on critical events, watching the video
camera, directing the user)
- Informed consent: write a consent form and have the user sign
it.
- Data gathering forms: these should make it easy to quickly note
task completion times, errors, comments, critical events.
- Analysis of results: your analysis should summarize the quantitative
and qualitattive data, identify the usability problems found,
and prioritize them
Multiple-person groups (as well as individuals who want to strive
for "A" quality work) should additionally do one or more of the
following:
Heuristic (expert) review: Normally the expert would be
someone other than you, but for the sake of learning we'll let
you do it! You may use any of the methods we discussed (heuristic,
cognitive walkthrough, "studied ignorance"). Each member
of the group should conduct an independent review and compare
their results (the comparison may be done in a follow-up session,
or interleaved as in pluralistic review). But you must do this much more rigorously than I saw most groups doing it in the class excercise.
Analytic evaluation: Use a predictive model
such as described in your textbook or a UCD model (the classroom
lecture will be April 18th). Ask me for a copy of the relevant
chapter from the UCD textbook.
In either case, write these up as if you were writing a report for a client who designed the software. I recmmend that you do the heuristic review or analytic evaluation first, and then use this to help identify what to test in usability testing (i.e., do mediated evaluation).
What to turn in
- An overview that says what you are trying to find out about your design and how the prototype and the evaluation plans are both designed to meet these needs.
- A page that gives us access to your prototype, if possible. (For software, specify installation instructions.)
- An outline of your evaluation plans, with links to
detail pages (e.g., evaluation instruments, forms) as needed.
Due 4/18 and revisions by 4/21
We will discuss your plans in class 4/18, and give you advice
for improving the evaluation plans. The lecture will also be on evaluation. The revisions
should be recorded by 4/21 so I can comment that weekend and you
have the next week to conduct the evaluation.
Pau |