Notes: reflection on readings for seminar 1

The central pillar of user-centred systems design is to involve
the users of a system to a high degree. Many times, especially
in government or enterprise projects, it is the case that a system
is designed in a very rigid fashion, with some experts giving
requirements and the development team then implementing these
requirements independently of the surrounding organization.

The article (Key Principles in User-Centred Systems Design) is basically a guide to how to avoid this class
of failures - involve the user! Do not only design with the user
in mind, but make them part of the process. It suggests three
things that from my own experience is most important when trying
to achieve this goal:
- have the end user participate in the design and development process. They have the domain knowledge you may lack
- make prototypes, early and often. Agile development with many iterations is a good combo.
- usability expertise is a thing, use it. Programmers and the population use computer systems differently.

But how does one do when involving users? Gathering data from users
to apply in the design process isn't easy. During prototyping and
iterating on the prototype, direct user feedback can be gathered
and used. In the planning phase, I've found interviews to be a good
way at identifying problems to tackle. During the MVK course, we've used
rather structured interviews when collecting requirements, which
has worked well.

Another of the main techniques for gathering data, using questionnaires,
is harder when trying to identify requirements, but is good when determining if a change introduced to a system is good. However,
questionnaires must be carefully designed not to introduce biases.
There are biases both in how we answer certain question (for example
on how it is worded, where in the questionnaire the question is), and
getting a good random sample - maybe a certain group refuse to answer
questionnaires in general, skewing the results.

Automatically observing the users when utilizing the system (indirect observation), is a common technique nowadays.
We attempt to describe how the system is used in terms of small, logable actions
taken by the user. There is a big potential for biases though, and mistakes arising from optimizing the wrong thing (can an increase in the use of a UI language selector result from both a good and a bad change?).

My question for the seminar is: how do we reduce biases in the different data gathering techniques?