Below are links to websites that describe the different methods.
Requirements/ functions meeting /GUI design
Claims-analysis (- use search for an example of claims analysis)
4. Pluralistic walkthroughs:
5. User testing ("lab")
6. Field experiment (Close co-operation with WP8 and WP3 - "evaluation of the practices").
Task force on usability also provided templates to enable easier note taking and reporting. The templates should be adapted in order to fit better to the laboratory kind of usability testing.
Step 1: Organising and creating the test plan
One should be familiar with the product/tool/service that is going to be tested. Therefore, it is important to get to know the product/tool/service. It is also essential to think about what issues need testing, as well as why test them. After this step, it is easier to sketch the test plan and how the process will be conducted.
We would move “Step 5” in second position here. The entry point shall be the description of a scenario, split into small pieces (elementary tasks with precise objectives). Then it is easier to insert test cases in this “roadmap” and follow the different steps below for each test case that is “inserted” in the script.
Step 2: Setting the goals of the test
One should have a clear idea of the goal of the test. In order to do so, it is imperative to list and define the goals of the test and the type of data that is expected from the test. The aforementioned list and definitions of goals influence the choice of the method(s) employed.
Examples of some general goals are:
Step 6: Choosing the method of testing
What method is chosen depends on the data that is wanted, what is the phase (e.g. actual use surroundings are possible), what are the recourses, and availability of end-users. (Sample of test methods can be found below).
Step 7: Piloting the test
The test itself has to be tested with a small group of end users. The same persons should not be used in the actual test. Most often some miss thinking is found in the pilot test, e.g., video cameras not in the right place, the task description is not good, the data that is gotten is not the right kind of data.
Step 8: Knowing the tool/product/service
It is imperative that people who are planning the test know the tool/service/product, its features and functions and envisioned use.
Step 9: Writing the report
The data of the test has to be analysed after which a report of the test has to be written. It is also good to evaluate and prioritise the findings with respect to which ones are “severe” and have to be corrected as soon as possible and which ones are not so problematic. A brief list of what should be in the report (for more detailed description see the template in the appendix 5): a description of the user interface, a short description of the task (story) that was used, a description of the test group, an explanation of the test method(s) used, the reasons why that particular method was chosen should be presented, the results of the test and finally the conclusions of the test.
(Sinkkonen I, Kuoppala H, Parkkinen J, Vastamäki R. 2002).
Sinkkonen I, Kuoppala H, Parkkinen J and Vastamäki R. (2002). Käytettävyyden psykologia. Edita: Publishing Oy/IT Press.