The document discusses the use of evolutionary prototypes as boundary objects to facilitate communication and collaboration between software engineers, user interface designers, and usability specialists. It highlights how these prototypes aid in formalizing product requirements, enhance client communication, and convey usability issues effectively. The experience detailed in the paper illustrates the successful integration of software engineering processes with human-computer interaction methods, leading to improved project outcomes.

1. Using Evolutionary Prototypes to Formalize Product Requirements
Junius Gunaratne, Beatrice Hwong, Christopher Nelson, Arnold Rudorfer
Siemens Corporate Research, Princeton, NJ
{junius.gunaratne, beatrice.hwong, christopher.nelson, arnold.rudorfer}@siemens.com
Abstract new software features. Though MED knew what high-level
features should be built for the demo, they found it difficult
Boundary objects are artifacts that facilitate to formalize how the features, the user interface (UI) and
communication and interaction between people or groups the task flows should work. Software engineers and
functioning in different domains. Software engineers, user usability specialists needed to collaborate due to a strong
interface designers and usability specialists have different focus on the UI look and feel, use of new technology, and a
domain knowledge, different terminologies, and shared very tight timeline. To facilitate communication and
terms with different, distinct meanings. Boundary objects interaction between the two groups and the client, SCR
can help assist the process of designing software by used an evolutionary prototype as a boundary object.
providing a common interface for communication between This paper reports on our success of first using
professionals in different domains. The Software storyboards—followed by an evolutionary prototype—to
Engineering department and User Interface Design Center act as a common interface between software engineers, UI
at Siemens Corporate Research used an evolutionary designers, usability specialists, and the client. Storyboards
prototype as a boundary object to help elicit product are used to brainstorm and capture some initial
requirements from their client, Siemens Medical Solutions. requirements by aiding communication between different
This enhanced communication with the client and between domain experts. The storyboards are then replaced by the
groups at SCR. This paper describes how the evolutionary prototype for the remainder of the project. We found that
prototype functioned as a boundary object and how it tools such as Microsoft PowerPoint or Macromedia
allowed software engineering processes and human- Director did not provide an artifact with a high enough
computer interaction methods to proceed concurrently fidelity to allow for sufficient communication between
without the need for well-defined interaction points. group members. The evolutionary prototype used J2EE
application technologies similar to the real product to help
software engineers determine implementation feasibility of
1. Introduction requested features based on the real product’s software
architecture constraints. Our experience with traditional
Siemens Corporate Research (SCR) is the Siemens prototyping tools and the need for using real product
research and development facility in the U.S. chartered to technologies drove us from storyboards to an evolutionary
deliver advanced technology solutions to Siemens business prototype.
units worldwide. SCR is comprised of several groups in
different domains including Software Engineering (SE) 2. Background
and the User Interface Design Center (UIDC). Quite often
customer requests require collaboration between the In most cases the purpose of prototyping is to quickly
different groups at SCR. Therefore it is beneficial to create an artifact that demonstrates behavior of an intended
attempt to find methods that allow for these collaborations product [1]. However, the purpose of our prototype
to occur in a timely and efficient manner. extended beyond simply demonstrating the product’s
One such attempt started with a request from Siemens intended behavior. A number of members expressed
Medical Solutions (MED). MED produces software concerns about how to appropriately translate language and
packages for managing clinical, administrative and artifacts from one domain to another—UI designers usually
financial hospital business processes. The new visionary do not understand UML models, and only a few software
software features are demonstrated annually at major engineers are familiar with human-computer interaction
industry conferences. For one such conference, MED (HCI) methods, to mention a few examples. The prototype
requested help from SCR to demonstrate some of these as a boundary object resolves this issue by providing an

2. artifact understood by all team members, ensuring effective perform tasks such as checking a patient in, assigning
communication of ideas in addition to helping facilitate facility resources such as beds and doctors, and handling
discussion and creating estimates for development. delinquent billing. The software needed to adhere to new
UI standards based on an unfinished, still evolving style
2.1 Prototypes as Boundary Objects guide. The success of their software relies heavily on its
usability due to the wide range of potential users, and the
Boundary objects are used as a means of coordination environment in which it is used. For this reason, it was
and alignment [2]. They serve as translators between imperative that usability specialists at UIDC be included in
disciplines and are malleable enough to adapt to changing the process from the start.
needs. They are working arrangements and are adjusted as The very short amount of time available (about 10
needed, and they are neither imposed by one community, weeks) to complete the requested features put a heavy
nor by appeal to outside standards [3]. constraint on this project. The absolute deadline set by the
Conventional boundary objects used in software date of the industry conference meant that software
development include UML and storyboards. UML can engineering and user-centered design cycles needed to run
show interaction between different components of in parallel.
software. Storyboards can demonstrate progression of a
task and describe user interaction on a screen. Both of 3. Benefits of an Evolutionary Prototype
these types of boundary objects typically abstract software
at high enough levels to transcend the boundaries of To demonstrate conceptual versions of the product,
disciplines, but they each lack benefits the other provides. initially MED and SCR created a storyboard that defined
UML lends itself to use by software engineers since it functions to be implemented. SCR asked MED questions
supports their standard needs and processes, while about the state of the system in hypothetical situations. It
storyboards lend themselves to use by HCI specialists for quickly became evident that the behavior and logic of the
similar reasons. system could not be expressed adequately with a
McDaniel, Olson and Olson at the University of storyboard. A storyboard can be updated to reflect changes
Michigan studied combining SE processes and HCI in requirements, but it is difficult to foresee the
methods through rapid prototyping and iterative design and implications of those changes when the boundary object is
analysis, but this combination of the processes created not interactive. The prototype needed to evolve, along with
difficulties. Software engineers tended to “respond to user the requirements, in order for it to be a valuable artifact in
suggestions in preference to design team suggestions.” facilitating communication throughout the entire duration
Additionally, “the interface designer’s suggestions were of the project. An evolutionary prototype is interactive and
implemented, although not the way they were suggested.” it allows us to experiment with the real technologies used
[4] Arguably, these problems could be avoided by in the actual product. Interactivity allows us to better
improving project management or with more frequent demonstrate usability problems to the client. Use of
communication. Though some communication problems technology from the actual product shows the client
existed, this attempt shows the potential of a prototype to implementation constraints in software architecture.
work as a boundary object. Finally, interactivity and use of technologies from the
In contrast to the study at the University of Michigan, actual product allows MED to demonstrate advanced
some members of our UIDC staff had formal background functionality at conferences.
in both software development and usability. Also, SCR SCR met with MED in design review meetings every
communicated with MED on a weekly basis to give project one to two weeks using the prototype as a discussion piece.
status reports and participate in design review meetings, As MED requested changes on the features under
and at SCR, SE and UIDC communicated on a daily basis. implementation, software engineers assessed the impact of
Since the two departments are down the hall from each the changes on the architecture and design and later
other it is not difficult to have development or usability incorporated the changes into the prototype. As SE
questions answered quickly. All of these factors helped developed the prototype, UIDC ran usability tests on the
communication through the prototype, and the evolving prototype. Usability specialists searched the
development process. prototype for inconsistencies in the UI. UI designers
looked for areas where the prototype’s UI did not conform
2.2 SCR’s Role in MED Projects to the style guide. Issues communicated to SE through the
prototype included button placement, icon use, and when
MED’s suite of programs is used for managing to give feedback to the user after a task or operation is
hospitals, supporting both clinical and business-related completed. UIDC constantly received feedback from the
workflows. It is intended for use in medical facilities to client and software engineers about UI limitations.

3. Feedback to software engineers happened throughout SE’s bed information. The initial requirements, captured in a
and UIDC’s processes without the need for well-defined storyboard, are a collection of several screens representing
interaction points since discussion revolved around the the different states of zooming. The storyboard mislead
prototype. While SE and UIDC ran their processes, MED MED and UIDC by appearing to capture all feature
started validation testing to make sure the prototype requirements. When software engineers tried to implement
evolved in the intended direction. This permitted the storyboard they often raised questions MED and UIDC
requirements to mature quickly and kept client did not consider. Using the storyboards as the boundary
expectations in sync with what was going to be delivered. object between groups left some details lost in the
During design review meetings software engineers gain translation of one group’s terminologies to other groups’
a greater appreciation of usability by seeing the client terminologies.
struggle through tasks. Since usability specialists are The storyboard lacked sufficient information for
available in design review meetings they provide feedback software engineers to implement the zooming feature. SCR
on potential improvements. This gives usability specialists used the prototype to demonstrate to MED how the poorly
a simple way to convey usability problems to both the defined zooming behavior requirement created usability
client and software engineers without use of formalized problems. If a user clicks the zoom in button, the
documents. Since software engineers and the client application zooms in on the open hospital. If a user clicks
participate in meetings with usability specialists, HCI the zoom in button and there is no open hospital, nothing
methods such as think aloud techniques, cognitive happens and there is no feedback provided to the user.
walkthroughs, and heuristic evaluation are implicitly SCR found this to be a problem, and only by seeing the
practiced without having to extensively educate software problem manifested in the prototype did MED perceive it
engineers and the client about the methods. The client is as a problem too.
asked to complete a task in a style similar to cognitive
walkthrough. User interface problems in the task are 3.2 Prototyping Bed Filtering
documented by both software engineers and usability
specialists in heuristic evaluation style. The client and Beds in a hospital have a variety of characteristics that
software engineers are not immediately aware that they are restrict their use. For example, a bed in a maternity unit of
performing a cognitive walkthrough or heuristic a hospital is only available to a woman. Additionally, beds
evaluation, but through the act of using the prototype as a have different states such as being empty, occupied, dirty,
discussion piece they participate actively in the HCI or reserved for a future patient. A bed manager typically
methods. has to check the status of hundreds of hospital beds in
After the initial requirement definition, SCR order to find one that is appropriate for a particular patient.
implemented the first version of the prototype, but Use of a bed filtering mechanism can dramatically speed
continued to maintain storyboards as an alternate form of up the time it takes to find a bed by only displaying
specifications. MED preferred using the prototype as the appropriate beds.
boundary object because of its strength of communication Defining the bed filter feature’s behavior began as a
over the storyboards. The prototype became the de facto sequence of storyboard screens and quickly moved to a
standard for defining product requirements. The prototype. After completing the initial implementation of
storyboard—initially driving the requirement definition— filtering, MED met with SE and UIDC to discuss changes.
became dated and superfluous. Change requests from meetings were made to the prototype
The prototype’s implementation of hospital resource and then discussed in the next meeting. Through such
views and filtering beds are two examples of how the meetings SE and UIDC refined the filtering rules for bed
prototype served to bridge communication gaps in the selection. MED did not explicitly state some rules for bed
software development process among SE, UIDC and filtering in the original storyboard. Only after using the bed
MED. filtering feature in the prototype did MED realize specific
behaviors needed to be implemented. SE and UIDC
3.1 Prototyping Hospital Resource Views collected a number of bed selection rules as a result of
eliciting requirements through the prototype. For example,
One feature of the prototype is the ability to navigate when a bed manager searches for an empty semi-private
through the hierarchical structure of an Integrated Health bed, sometimes the state of the adjacent bed determines
Network (IHN) to view hospital information. In hospital whether it is suitable. If a female occupies the adjacent
resource views a user can navigate the IHN and see a bed, the empty bed is only suitable for a female. MED also
listing of hospitals. In the hospital a user can see different did not specify initially that when an adjacent bed has a
units, rooms and beds within that hospital. It is possible to hazard indicator, the empty bed cannot be assigned and
zoom in and zoom out on hospitals to view unit, room, and must be blocked until the hazard is cleared. Such rules

4. could not be collected without the prototype. The other at any point in their processes. The evolutionary
prototype demonstrated to MED the importance of creating prototype provided a union of the two sets of benefits from
well-defined bed filtering rules, forced MED to fill in gaps UML models and storyboards and permitted early testing
where rules were not complete, and it helped software of interaction sequencing. This allowed us to quickly find
engineers refine bed filtering logic. problems with usability and functionality, which in turn
allowed us to quickly discover and implement solutions.
4. Lessons Learned Through use of an evolutionary prototype as a boundary
object SCR quickly gathered a mature set of requirements
At the end of our project with MED we ran a process to create a high quality deliverable.
improvement workshop to determine what worked well,
and what did not. We learned that the prototype worked 7. References
extremely well to facilitate communication between the
groups, but we did not make use of its full potential. We [1] K. Schneider, “Prototypes as assets, not toys: why and
have since come up with new methods to handle change how to extract knowledge from prototypes”, Proceedings of the
18th International Conference on Software Engineering, IEEE
requests coming from the client. Our new methods use the
Computer Society, Berlin, Germany, 1996, pp. 522-531.
boundary object to capture the details surrounding the
change request. In a change request, the client or usability [2] Star, S.L., and Bowker, G., Sorting Things Out:
specialists are forced to explicitly state how to navigate to Classification and Its Consequences, MIT Press, Cambridge,
a screen or dialog box in a specific module in the MA, 1999.
prototype. Software engineers, on the other hand, must
reference specific modules in the prototype when changing [3] A. Ernesto, H. Eden, G. Fischer, A. Gorman, E. Scharff,
underlying code. This is important because both SE and “Transcending the individual human mind—creating shared
UIDC need to do impact analysis, but the information the understanding through collaborative design”, ACM Transactions
on Computer-Human Interaction, Vol. 7, No. 1, March 2000, pp.
two groups need to analyze requests often differs. By using
84-113.
the right boundary object, we ensure that the necessary
information for both groups is correctly captured, [4] S.E. McDaniel, G.M. Olson, and J.S. Olson, “Methods in
communicated and disseminated. Search of Methodology—Combining HCI and Object
Orientation”, Proceedings of the Conference for Computer-
5. Next Steps Human Interaction 1994, Boston, MA, 1994, pp. 145-151.
[5] R. Chatley, J. Kramer, J. Magee, and S. Uchitel, “Model-
This project proved that a prototype can be used very
based Simulation of Web Applications for Usability
effectively as a boundary object between SE, UIDC, and Assessment”, Proceedings of Bridging the Gaps Between
our client when developing a J2EE application in the Software Engineering and Human-Computer Interaction at
Health Services domain. We intend to apply the same ICSE’03, Portland, OR, 2003, pp. 5-11.
techniques to future projects with different technologies in
different domains such as embedded systems, and [6] X. Ferre, “Integration of Usability Techniques into the
communication equipments and services. Software Development Process”, Proceedings of Bridging the
Gaps Between Software Engineering and Human-Computer
Interaction at ICSE’03, Portland, OR, 2003, pp. 28-35.
6. Summary and Conclusion
[7] K.S. Sousa, and E. Furtado, “RUPi – A Unified Process
Typically, for HCI methods to be beneficial they must that Integrates Human-Computer Interaction and Software
be run very early in the software lifecycle, before Engineering”, Proceedings of Bridging the Gaps Between
development starts [5]. This increases the time it takes to Software Engineering and Human-Computer Interaction at
get a product to market. The time to market can be ICSE’03, Portland, OR, 2003, pp. 41-48.
dramatically shortened by running software engineering
processes and HCI methods concurrently, with well
defined interaction points for the teams to re-sync and
communicate [6,7], but the problem with this approach is
that time is wasted as one team waits at one or more
interaction points for the other team to catch up.
Using an evolutionary prototype as a boundary object
allowed for the client, SE, and UIDC to proceed with their
specialized tasks in parallel and to communicate with each