Using Rapid Contextual Design at Reykjavik University

Marta Kristín Lárusdóttir Computer Science Department

Reykjavik University Ofanleiti 2, 103 Reykjavik, Iceland

+354 599 6200 marta@ru.is

ABSTRACT In this paper, I describe how the methods of Rapid Contextual Design [2] were used in an elective course given on User Centered Design in Computer Science at Reykjavik University. The students used contextual interviews, affinity diagrams, data walk, visioning, paper prototypes and paper prototype interviews in a software project where the aim was to co-operate with real users when analyzing, designing and evaluating their systems. The students were instructed to use paper and pencil while using all these methods. The students’ main conclusion in the end was that working with the users using these methods and “old fashioned” tools encouraged creative thinking and gave surprisingly good results especially with regard to the time used.

Keywords Contextual design, contextual interviews, affinity diagrams, data walk, visioning, paper prototypes, user evaluation.

1. INTRODUCTION An elective course on User Centered Design (UCD) was given in School of Computer Science in Reykjavik University in the autumn 2005. The objectives of the course were threefold: The students should a) learn the methods of Rapid Contextual Design [2] through using them in a practical software project; b) get introduction to the research in this field through reading and presenting conference papers to each other and c) learn to write a summary of research papers. The goal of the practical software project was co-operation, both with real users and with other students in the course. After an introduction of the methods in a lecture, the students experienced the methods of Rapid Contextual Design [2] by using them while working with real users and report to each other what they did and how the work was going each week to learn from each others successes and mistakes. The course of User Centered Design has been given three times now. The first time the course was given, the students were also asked to analyze, design and evaluate a software system, chosen by them. The students handed in a lot of documents describing their results of the different phases in the software project according to the process of DSDM (Dynamic System Development Method) described in the book: DSDM – Dynamic Systems Development Method by Jennifer Stapleton [3]. The students had access to a web-site (www.dsdm.org) explaining the process and were instructed to use templates provided there for their deliverables. The students complained that the deliverables were very formal and it was very time-consuming to make them. The students groups worked in isolation, not teaching each other. The students were instructed to work with users in joint application design (JAD) workshops as described in the DSDM process [3], but they didn’t. The systems they designed were fine, but the students used a lot of time doing them and could have used more user-centered way of working. After this experience the procedure in the course was changed completely in the autumn 2004, asking the students to present their work to each other in short presentations and hand in informal deliverables each week during the software project work. They were instructed to use one or two methods each week, chosen by the lecturer, which encouraged informal ways of analyzing and designing the software systems and co-operation with users. The methods used each week were first described in a lecture and then the students used them the same week and gave a short presentation of the results to each other a week later. After handing in a description of the project the first week, the students went to the users’ workplace interviewing the users the second week, then they did a project plan the next week, in the fourth week they did personas and scenarios, the fifth week they did paper prototypes and evaluated them with the users and finally they did detailed design and presented their work in the eight week of the course. The text book the students used that autumn was Interaction Design, by Preece, et. al. [4]. The students were encouraged to use paper and pencil as much as possible during the whole project work. The students complained that they did not have any clear guidelines on how to prepare; process and analyze the results from the different methods from the text book [4], so they used the methods rather intuitively. It was a very positive experience for the students working in this informal way and they were surprised how much paper and pencil encouraged creative thinking. In the autumn 2005 the methods of Rapid Contextual Design [2] were introduced and used by the students. The structure of the practical software project was similar to the structure the year before, but now the project planning was skipped and the students had more detailed guidelines on how to use each method of Rapid Contextual Design from the text book than the students had the year before. The aim of this paper is to describe in detail the experience students had using the

methods of Rapid Contextual Design [2] in a practical software project. First there is a description of the process of the practical software project, then the usage of each method is described and finally the overall experience is stated.

2. THE PRACTICAL SOFTWARE PROJECT The duration of the practical project in a course on UCD in the autumn 2005 was 8 weeks out of 12 in the course. The students were asked to find themselves a subject for their software-development project where they could co-operate with at least one user once each week. Systems used on a handheld computer or a mobile phone were preferred. The students were instructed to find systems that had a lot of interaction between the users and the systems. The subjects of the projects the students chose were: a pizza ordering system on a mobile; a calling system for medical checkups for infants; a food recipe grouping web; a computer game; system on a handheld computer for a personal athletic trainer; and finally time and task registration for contractors on a mobile.

2.1 Participants There were 13 students that chose to attend, 2 females and 11 males. They formed 6 groups with one to three persons. The students were all on their third year of the BS-studies in Computer Science. All the students had taken a basis course in Human Computer Interaction.

2.2 The procedure The learning material in the practical project was the book: Rapid Contextual Design by Holzblatt, et. al. [2]. Each week one or two methods from the book were presented in a lecture and the students used them the same week in their project work. A week later each group gave a short presentation (5 – 10 min.) for the rest of the students on the outcome, benefits and drawbacks of using the methods, which was the main deliverables while working on the projects. The students kept track of how much time they used on each method. In total they used 20 – 30 hours per person in the project, not including the lectures and report meetings. In the end the students handed in a Power Point file, describing the subject of their project, the usage of each method, the cost and benefits of each method, the time used in each week and the overall experience. An overview of the procedure of the students’ tasks, deliverables the students delivered in each week and learning material can be seen in table 1.

Schedule Students tasks Deliverable Learning material 1. week Definition of the project,

interview with the user Short Word- document and short presentation

Cap. 1,2

2. week Contextual interview Short presentation Cap. 3,4,5 3. week Affinity diagram Short presentation Cap. 8 4. week Personas and scenarios Short presentation Cap. 9 5. week Data walk and visioning Short presentation Cap. 10, 11 6. week Paper prototype and user testing Short presentation Cap. 13, 14 7. week Work on redesign (Detailed design) Cap. 13, 14 8. week Present the outcome of the methods used,

cost and benefits in 30 min. presentation Power Point-file

Table 1: An overview of the students tasks, deliverables and learning material in the practical project

The grading for the practical work was done through a questionnaire, which all the other students and the lecturer filled in right after the presentation of the project work from each group.

3. THE METHODS USED IN THE PRACTICAL SOFTWARE PROJECT As listed up in table 1, the students used contextual interviews, affinity diagrams, personas and scenarios, data walk and visioning, paper prototypes, user evaluation and redesign in their work. They were asked to register the time they used on each method and the benefits and drawbacks of each method. This section will describe their experience of the methods.

3.1 The Contextual interviews A contextual interview is a one-on-one field interview with a user in his or her workplace to discover what matters in his or her work. Team members observe people as they work and inquire into actions as they unfold to understand motivations and strategy. The interviewer and user, through discussion, develop a shared interpretation of the work. The students were asked to interview at least one user. Three groups interviewed one user, two groups interviewed two users and one group interviewed three users. One group wanted to interview a user they did not know before, so their work would be as realistic as possible. This group had some trouble getting in contact with this person and was delayed because of this. The interviews lasted on average for an hour and they used two or three hours for preparation per. person. The students commented on that interviewing the users in the field was very valuable. The group analyzing the computer game had trouble because there was not any particular “old way” of doing things.

3.2 The interpretation session and the affinity diagram Interpretation sessions bring the group together to hear the whole story behind each interview and capture the insights and learning relevant to their design problem on post-it notes. An interpretation session presents all team members' unique perspectives to the data, sharing design, marketing and business implications. The team groups the post-its according the issues affinity and makes the affinity diagram which merges issues and insights across all users into a wall-sized, hierarchical diagram to reveal the scope of the problem. The students made 20 – 70 notes in their interpretation sessions and all complained that the affinity diagrams were maybe not that realistic because their project were not that big in scope. It it is recommended in the text book [2] to do at least four contextual interviews for the smallest projects and the affinity diagram should consist of at least 400 notes, but the students did one to three contextual interviews and were learning to use the method so that maybe influenced how much data they got. The groups used on average 9 hours for the interpretation session and making the affinity diagrams. Still all the students commented on that making the affinity diagram encouraged their creative thinking. All the groups except one used paper and pencil in this phase, see an example in figure 1. The group using a tool, downloaded a trial version of CD-tools, which is designed for using the methods of Contextual Design, see one screenshot in figure 2.

Figure 1: An example of an affinity diagram

Figure 2: Affinity diagram from CD tools

3.3 Personas and scenarios Personas describe typical users of the proposed system as though they were real people. Scenarios describe the tasks the user wants to perform in a storytelling way. The students made one to three personas according to the instructions in the text book [2]. There it is emhasised that the personas and scenarios should be made only according to the information from the contextual interviews and not added any information that they did not get in the contextual interviews. The students used on average three hours each to do the personas. The main benefits stated by the students were that the users came alive; it was easy to empathize with the users through the persona descriptions. It was especially valuable for the students doing the computer game, where there was no “old way” of getting the users goal, to visualize the users and their goals through personas and scenarios. The main drawbacks that the students mentioned when making the personas were that some of them did not have data enough from the contextual interviews so they started improvising.

3.4 The data walk The purpose of a data walk is to find holes in the data shown in the affinity diagram and to describe design ideas that pop up when walking the affinity diagram. Each participant is asked to read all the notes in the affinity diagram by himself in his own speed and note down holes he findes in the data and design ideas. The students used two to seven hours each on the data walk and visioning. Some groups got members from another group to assist in walking the data and that was a key to a success in this process, see an example of students working in figure 3. The students mentioned that it was very good to introduce the project and the data to new people and some stated that the users should be involved in this stage. The affinity diagram was most often displayed on the wall, with printouts and notes. Many new design ideas were written down in the data walk.

Figure 3: Walking the data

3.5 The visioning After creating the affinity diagram and doing the data walk, the students were ready to create a vision of how their new systems would support the users’ work. The students used whiteboards to sketch some vision ideas, as seen in figure 4. After making some three or four visions, summing up the pluses and minuses with each of them they did one consolidated vision, most of them using a tool. The students mentioned that the purpose of the visioning was not that clear to them. The projects were not that wide-ranging so the visioning was maybe not that important. In one project a requirement analysis had been done in parallel with this course. There the students mentioned that it was hard to go back to this analysis phase, when everything was decided. The students mentioned also that the visioning took a lot of time.

Figure 4: the visioning process

3.6 The paper prototypes The students did paper prototypes using post-it notes after the visioning session. In the text book [2] it is emphasized that the designers use post-it, so they can change the layout during evaluation with the user, see an example of one of the students’ prototypes in figure 5. One group thought it was too childish to show this to the user: “We are University students, we can’t show these handicrafts to the user”, they said, but they made drawings on paper of the interface. The other groups used post-it notes and liked that way of working very much, it did not take long time to make the prototypes and it was easy to evaluate them with the users. The students used on average five hours each doing the paper prototypes.

3.7 The evaluation and detailed design The evaluation of the paper prototypes was done with the user which “used” the paper prototypes. The students had made post-it notes describing the data so when the user inserted some information in the interface, the data was shown in the prototype by changing the post-its. Some students commented on that they needed to be very organized and it was time consuming to make all the post-it notes for the evaluation, it would be better to draw the interface on paper. Other commented on that it was very easy to “drag-and-drop” interface elements during the evaluation. After the evaluation the users redesigned the interface making detailed design according to the results from the evaluations. One example of the detailed design can be seen on figure 6. The students used three to eight hours each for evaluation and redesign.

Figure 5: An example of a paper prototype

Figure 6: Detailed design of the prototype above

4 THE OVERALL EXPERIENCE In the students final presentations of the projects, which they also delivered in, the students were asked to state the pros and cons of each method and the overall experience of the project work. After each presentation there were discussions in the whole group on their overall opinion about the project work. The students were very positive when reflecting on the experience of using the methods and some said that it surprised them how good these methods really are, it gave good results, it was easy to involve the users and all group members were active all the time. Some students were surprised that using the methods did not take as much time as they thought. The descriptions in the book [2] are precise, so it was easy for the students to use the methods first time, “the book is just like a User Manual” one student

commented. Another student said that it would have been even better to use the book for bigger projects than in this course. Many of the students liked working in such an informal way, using paper, post-it notes and pencil. The students mentioned that the contextual interviews were a gold mine of information. If doing the projects again they would have scheduled at least four contextual interviews in the beginning. Getting information so early in the development process was invaluable for the rest of the work, it was easier to concentrate on the things that really mattered and easier to coordinate the work. The students mentioned that working so closely with users during the whole project was very enjoying. This concurs with the conclusion in the paper by Curtis et. al. [1] where the usage of the methods of Contextual Design at Hewlett Packard in USA is described. It is stated there that using the methods of Contextual Design was the most valuable work they have seen within Hewlett Packard. When looking at the process of the project work, the students said that the final presentations were very informative, but the short presentations each week were tiring. They would have liked to be more active, discussing the pros and cons of each method in groups and hand in notes on that, in stead of doing these presentations to each other. All the students liked the experience of learning by doing, using the methods in a project like that was enjoying and gave good forum for discussions. It was also a very good preparation for reading conference papers where these methods were used or researched. When comparing the experience of the course in the autumn 2005 to the courses given the previous years, the latest was the best one in my opinion. The students did analyze, design and evaluate software systems using considerable less time that the years before with very good results. This really opened their eyes for that co-operating with users is invaluable source while designing software and the co-operation can be started very early in the software development process. One of the reasons for this efficiency in the course, is that the methods of Contextual Design are very well described in the text book [2], so it was rather easy for beginners to know what to do and how to do it. Another reason is that doing the contextual interviews right in the beginning of the analysis phase did encourage the students to focus on just the things that mattered to the users. When DSDM was used in the course the main focus for the students was on filling in templates for documents that they were to use according to the DSDM process and the students did not co-operate much with users. The joint application design-workshops (JAD) in DSDM are the forum for co-operating with users and the students were asked to form these workshops but they didn’t. So they learned how to use new methods like prototyping and showed some creative thinking in the group work, but they did not get inspiration from the users directly. I think one reason is that it was not as well described in the material they had how to involve users [4] as in the course material in the autumn 2005 [2]. Another reason could be that they where not encouraged enough by the lecturer. After this experience the deliverables the students handed in in the course in the autumn 2004 where much more informal and the focus was on using methods where co-operation with users is emphasized. The methods were picked by the lecturer and the students did not have good description on how to use the methods and how the deliverables of one method were used as an input while using the next method. The students used some time wondering about this but in the autumn 2005 the students managed to use more methods in a more effective way because of the good descriptions in the course material [2]. In the autumn 2005 the students also showed more creative thinking, especially doing the paper prototypes and the visioning than the years before. Now they were asked to use post-it notes while doing the paper prototypes and that was very inspiring for them. Also drawing the whole picture of the system on the whiteboard during the visioning session encouraged creative thinking, although some of the students commented on that they were insure what the whole point was in doing this, I am sure that it gave them good overview and made them look at new ways of designing the whole system. I could highly recommend the book “Rapid Contextual Design” as course material for courses where the focus is on creative thinking and co-operation with users.

ACKNOWLEGDEMENTS I want to thank Ásrún Matthíasdóttir, assistant professor at Reykjavik University and Ebba Þóra Hvannberg, associate professor at the University of Iceland for their very good feedback when reading through the paper.

REFERENCES 1. Curtis, P., Heiserman, T., Jobusch, D., Notess, M., Webb, J. Customer-Focused Design Data in a Large, Multi-Site

Organization, Proceedings of CHI’99, 1999, Pittsburgh, USA 2. Holtzblatt, K., Wendell, J. B. and Wood, S. Rapid Contextual Design, 2005, Elsevier, San Francisco. 3. Preece, J., Rogers, Y., Sharp, H., 2002, Interaction design: beyond human-computer interaction, John Wiley & Sons,

Inc., USA. 4. Stapleton, J. DSDM – Dynamic Systems Development Method, 1997, Addison-Wesley, London.