Seminar 2 Group Summary

Chapter 13:

DECIDE is a method of evaluation. Concordingly, each part of the method is explained in the chapter. We feel that our idea and design has gone more towards the “back-end” of the problem. We try to solve the problems and focus alot on how to it looks aesthetically.

Chapter 15:

We want to evaluate if a user will be able to actually do a payment via their smartphone. We’re currently doing a style of cognitive walkthrough where we focus on identifying specific problems of a user at a high level of detail.

Questions and discussions in the group

What makes an expert?

In conclusion, an expert can be defined by someone having education in the HCI field, if the project is dependant on HCI. A followup question can be how much experience is needed to be an expert? In theory, we are all experts by having used the SL access system for so many years. In reality, mayhaps an expert is someone who has evaluated the whole field of tickets and inspected all aspects of a system.

The question that lingers is which expert is needed for our project? There can be experts that know the programming code for the SL-Access system.

How important is it to follow these heuristics when developing a product?

Evidently, there are plenty of projects that do not use the guidelines / framework with their projects. After all, they are guidelines to serve.

How do you choose which model you use without hiring an expert?

You need to start looking at the practical issues. You can in theory follow DECIDE since they are not strictly ordered in a manner. “Identify the practical issues”.

Is it a good idea for the developer to do regular evaluations themselves and therefore save the company money by avoiding expert costs?

A company exists to gain profit. In theory every measure should be taken to save as much money as possible. It completely depends on the part that needs to be evaluated but the general opinion in the group seems that it’s completely impossible to know if an expert will be able to contribute with more valuable information and data. It’s also possible that a developer is “blind” and won’t see things that an outside observer will.

What are the risks of setting an ambiguous goal for an evaluation?

Well Hannes, you won’t get the proper results for the evaluation. If you don’t evaluate correctly you won’t necessarily get the correct information and data. There is also a chance that you may get information about other parts of the evaluation that you did not count on. It’s however a game of chance and probably not used by big companies that have alot of money invested in a product.

What are the factors that determines the scope of an evaluation?

Factors that needs to be reminded about are economy, target group, location, the scale of the evaluation. If a company does not have a good budget to spend on planning the evaluation, it will be hard to have good progress evaluating their product. The same goes for the target group - if you for example choose children as a target group you might not be able to apply the results to grown ups as well.

What is the most cost efficient way to do an evaluation?

One of the most efficient ways to save money is to limit the evaluation and the amount of experts. This however will risk the design project and may doom it purely because of a bad foundation. Not having all of the framework done and researched enough for the project will definitely be a cost-efficient way of doing it but ultimately result in failure. It’s a rocky road.