Seminar 2: Chapters 13, 15

HCI Seminar 2 - Reflections Document

Chapter 13:

This chapter introduces the framework DECIDE.

“Determine the goals, Explore the questions, Choose the evaluation methods, Identify the practical issues, Decide how to deal with the ethical issues, Evaluate, analyze, interpret, and present the data.”. The chapter investigates the meaning of each point in the framework. The framework is made to help create a proper evaluation of for an example a software product. The evaluation being HCI related, in other words it is an evaluation of the usability from a users perspective. Analysing a user’s behaviour can reveal problems in the design, which is important to handle as early as possible so it's not as expensive. An evaluation can be useful not only to find critical errors, it can also improve the user experience if the developers choose to develop their product according to the result.

The DECIDE tool is a good platform to start on when you have realised that an evaluation might be required or beneficial. I will probably go back to this section if or when we do an evaluation on our project.

Chapter 15:

This chapter entails on different evaluation methods. It is mostly based on heuristic models, which means that experts pretends to be the user and try to anticipate where the user might go wrong and also what might be frustrating to the user. The chapter discusses the accuracy in finding problems based on how many experts you employ. Different walkthrough options are also discussed, a walkthrough being how experts might approach a user interface. There is also a part that talks about analytical tools. Such as web tools for analyzing traffic data etc. How statistical data might be useful to create a good user experience for your website and to analyze if your marketing is working the way you think. Predictive models are also covered in this chapter, such as GOMS and KLM. Both designed to try and predict how time consuming a task is.

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

My own opinion: Regular evaluations at every step of the design process seem more beneficial than one large evaluation. Because programmers know that fixing the previous problems might cause new ones.