måndag 23 februari 2015

Prototyping and evaluation


Prototyping

A prototype is generally like a model of the final product. It can for example be a scale model of a building or simply a paper based model of a computer application or program. It is meant to serve as a preview of the final product and should try to attract investors or people who might be interested in the product. It is also an effective way for designers to get new ideas and can also help the designers to choose between different design alternatives. A prototype should be designed so that it concerns key issues.

There are two different types of prototypes, Low-Fidelty Prototyping and High-Fidelty Prototyping.

Low-Fidelty Prototyping.
  • Doesn't look very much alike the final product
  • Simple, cheap & easy to produce and modify
  • Should encourage exploration and modification
  • Storyboarding, Sketching, Using index cards & Wizard of OZ (for software based prototypes) are examples of Low-Fidelty Prototyping.
High-Fidelty Prototyping.
  • Looks more like the final product
  • Good for selling ideas and for testing technical stuff
  • Usually fully interactive
  • More expensive and time consuming to develop

DECIDE.

DECIDE is a framework that is meant to help with evaluation.
The term DECIDE can be summarized to these points;

  • 1. Determine the goals - Who wants it and why?
  • 2. Explore the questions - Find out the questions you want answered in the evaluation
  • 3. Choose the evaluation methods - Choose the form of evaluation
  • 4. Identify the practical issues - What can be done and what can't?
  • 5. Decide how to deal with the ethical issues - Respect the people taking part of the evaluation
  • 6. Evaluate, analyze, interpret, and present the data. - How should the collected data be used in the best way?
Measurement of tasks

When users test the product the main focus of the data can be listed as;
  • Time to complete a task.
  • Time to complete a task after a specified time away from the product.
  • Number and type of errors per task.
  • Number of errors per unit of time.
  • Number of navigations to outside help (online help or manuals).
  • Number of users making a particular error.
  • Number of users completing a task successfully.
These are then analyzed to help develop the product in a good way.

QUESTION FOR THE SEMINAR:

How much time and effort should be put into prototyping to make it efficient?




Inga kommentarer:

Skicka en kommentar