THE DESIGN PROCESS

An Interdisciplinary Design Approach

As new technologies take advantage of more forms of media (e.g., sound, animation, video, etc.), professionals with experiences outside of a technical discipline are needed to contribute to the development of these technologies [4, 5, 6, 8]. When we began our collaboration, we looked to work with students, staff, and professors from both the Computer Science Department and College of Education. We believe that both computer scientists and educators can make significant contributions to the development of educational technologies. In working with our child collaborators, we were careful to have both education and computer science researchers experience significant contact hours in the classroom. In this way, there were few questions about the field research that was conducted. Different researchers with different points of view contributed to the data collected.

What we found was that researchers from each discipline were sensitive to different issues, observations, and experiences. For example, educational researchers were more aware of when the children grew bored, excited, or confused with the technology. On the other hand, computer scientists were more sensitive to how the children used the software and quickly saw where new technologies could be developed. Together, researchers developed a knowledge base of information before even one line of new code was generated. Only after two and a half months of collaboration with children, was the beginnings of a new technology environment developed. This made some of the computer scientists nervous. They were much more used to writing code than they were spending their research time with children.

At the onset of our field work in classrooms, there were days when some computer scientists felt unsure of what to look for when working with the classroom children. They felt uncomfortable that they had been thrust into the role of teacher rather than researcher. In those days, it was the educational researchers that were more at home working with the children; developing activities and coaching the students along until they found some proficiency with the technology. But as time went on, confidence grew in many of the computer scientists when it came to working with children. One technique that seemed to put both adults and children at ease was that researchers worked in small groups with students (e.g., one researcher to two or three children). Slowly, both adults and children began to feel more comfortable with the technology and each other. Eventually, children were able to offer design suggestions and point out problems with the software. It was then that the computer scientists took the lead and began to develop the first versions of KidPad. It should be noted however, that even at software design sessions, back at the labs in the university, educational researchers were present and considered to be full partners in the design of the software. This however, did not mean that there was full consensus in what to work on and when. There were times that the educational researchers wanted much more than what was possible with the limited programming resources available. Eventually however, thanks to some insightful discussions, a common understanding was established.

What we found interesting about the development process as a whole, was that each research discipline took turns leading the activities, depending upon the expertise that was needed in the context of the work. However, at no time were researchers from either discipline excluded from the research activities. While there were moments of frustration when research activities were unfamiliar or not clear, we found that an interdisciplinary research partnership can be an exceptionally supportive, creative, and productive experience.

Children As Our Design Partners

Collaborating with children is very different than collaborating with adults. Generally, when a user is brought into the design process, he or she can offer discipline expertise (e.g., in law, medicine, music, etc.). Children are experts at being kids; but exactly what that means is hard to say. They can't offer you a list of the five important things you must include in your technology. Often, children are not that self-aware or verbal about their needs. They must be given opportunities for communication and self-awareness, either through experience with technology or through participatory design exercises that ask them to see possibilities using low-tech prototyping tools.

For example, one design exercise early on asked children to begin brainstorming on paper by using a game board. On one side of the board they selected cards containing a short description of the technology they were to design (e.g., house-building software, letter-writing software, a trip to the New Mexico State Fair) , and on another side of the board they selected the various interface devices they thought they'd use (e.g., keyboard, mouse, joystick, etc.). Lastly they were given a few blank squares to draw their thoughts about the software they were designing. Thanks to this exercise, we saw software "features" we could never have anticipated (e.g., a "window bars" option in the house-building software, because according to one child designer "no one wants to have their house stolen on the computer"). Through this exercise, our child collaborators became more sensitive to the ingredients that they were asked to consider with the real software they used and discussed with adult researchers.

What we found in our collaboration with children was change and growth. We began our work together, as unequal partners. We as adults had to facilitate the children's use of the technology. We had to explain how things worked, and what possibilities they might try. While many of the children had used computers before, none had ever used a zooming software interface. It took some time to get used to, and some time to start asking questions. While we adults were facilitators and advisors, we were also observers. We immediately saw what activities the children enjoyed; we immediately saw what confused them. However, as the children's expertise grew, so too did the number of suggestions and design ideas they offered. Eventually, as their confidence grew we asked directly for design ideas, as opposed to waiting to be told them. We asked the children to develop storyboards of design ideas for the future. By the time the children were done, they had grown into full-fledged design partners. They needed time, experience, self-awareness, and confidence in our design relationship. With adult design partners, time, experience, and self-awareness may not be something necessary to develop; with children it may be critical.

back

next

1

Abstract

4

User Profile

7

Summary

2

Collaboration

5

Design Process

8

Acknowledgments

3

Goals for Development

6

Design Evolution

9

References