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.
Web Accessibility
