Pre-seminar thoughts on the literature - 2

The paper from Jan Gulliksen et al. gives a lot of feedback on a whole project with a focus on UCSD: User Centered Systems Design. UCSD principles give an approach to any project related to user-centered development, and thus it is relevant to build upon those and get inspired in our project for DH2620. The paper explains also how some raw UCSD principles as mapped in the Appendix (UCSD Poster) have somewhat failed in their application to the project. The ISO 9241 parts on Ergonomics given in the literature enlighten those very concepts. Here are some main good practices we ought to take into consideration during our project for DH2620 which I summarized under three categories: Iterative design and prototyping, Evaluation by user-measurements and Simplicity.

Iterative design and prototyping

The process of design should be cyclic rather that linear. There should be as many cycles as it appears to be necessary. The cycle should include the production of prototypes at the earliest possible stage. This enables the developers to get live feedback and a better feeling about user needs. Some techniques use collaborative design, where users have hands on the product’s prototype and not only give feedback but are able to make suggestions to designers.

An iteration can be a major designing shift as well as a thirty minutes workout.

Designers should carry several prototype ideas and implement them, to avoid converging on a dysfunctional idea or missing some key element that could significantly improve the whole. (see the analogy with local maxima as opposed to the best possible design, in Kristina Höök’s lecture on Interaction Design Methods – slide 7). Also, those parallel designs are born out of the only creativity phase of a cycle which is the brainstorming.

Cyclic process of user-centered systems design, Jan Gulliksen et al. (2003) 
Key principles for user-centred systems design , Behaviour & Information Technology 

Evaluation by user-measurements

The Part 11 on Guidance on usability of ISO9241-11:1998, despite being 16 years old, presents some interesting definitions about how to handle the ‘Evaluate’ phase in the cycle depicted above. It proposes to do this evaluation through 3 criteria which are:

• Effectiveness
• Efficiency
• Satisfaction

Calculating those parameters seem very hard to evaluate with accuracy and relevance, but the paper explains that effectiveness can be the ratio of success in achieving a given goal (provided we produced a list of activities that one should perform using the product), efficiency relates this effectiveness rate with the quantity of efforts put in the action to achieve the given goal, and satisfaction quantifies the discomfort. Further details are available on this paper where I gathered relevant quotations directly taken from the course literature.

Simplicity

Make it simple.

The use of the formal UML language for use cases, albeit having the advantage of being widespread, is too abstract to be presented to users or even stakeholders. We can keep the idea that a simple mapping helps everyone understand the using processes. I have previously used yEd Graphics as a simple mapping tool that could be an alternative to using UML in our project.

On the same subject, using agile development methods might distract one from focusing on the user-centric priority, to the benefit of efficient implementation. Even though I don’t think we need to implement agile methods for our project, we can keep in mind that usability is of a paramount importance while perfect coding isn’t.

However, a usable design does not mean that it should be rendered as easy to use as possible at any price. Some other factors come into play such as perceptual and emotional aspects, user experience, satisfaction or suppression of monotony.

Question: The paper mentions the importance of a user-centered design process throughout the project. The number of iterations seems to be crucial, but we might not be able to go to the museum each time. Can we take people/children without the museum context but with a mission that would simulate the context?

Question: When setting up a design in a project team, should there be someone dedicated to the task of forcing the group to go through several process cycles before launching up the final product? How do we balance the feeling that we are in the good direction and the necessity of a sufficient quantity of feedback from the users?