1. User-Centered Design and Agile Software Development
Processes
Beatrice Hwong David Laurance Xiping Song Arnold Rudorfer
Siemens Corporate Siemens Corporate Siemens Corporate Siemens Corporate
Research Research Research (SCR) Research
755 College Road 755 College Road 755 College Road 755 College Road
East East East East
beatrice.hwong@sc david.laurance@scr xiping.song@scr.sie Arnold.rudorfer@scr.
r.siemens.com .siemens.com mens.com siemens.com
ABSTRACT software development teams must find a way to
The time and budget to create software products is communicate successfully with their clients, both to
shrinking; successful enterprises will economize both capture client needs and to show how the product will
by combining processes and exploiting synergies be implemented to meet those needs. Most software
between SE and UCD practices. By intelligently development methodologies now rely on use cases or
combining the strengths of SE and UCD processes “user stories” to capture client needs; however, for
and by using one development artifact, e.g. many systems, these approaches are limited in their
storyboard, it is possible, more quickly than before, to ability to convey useful information to the client; this is
focus on client requirements, to design and implement often not completed until the end of an iteration, when
the user interface, and to shorten test iteration cycles. running code is implemented.
With use of a single artifact, time compression for the
project life cycle is achieved. This position paper In a growing number of software systems, the user
presents an experience report on how we have interface accounts for approximately half of the total
successfully combined SE and UCD practices. lines of code [1]. Among our clients, this is often
recognized late in the development cycle, typically
Author Keywords after much of the code for the system has been
Process integration, optimization, agile and iterative written. In our development experience, UCD
development, storyboard, requirements and design expertise is sometimes engaged at this time, but it is
models. often too late in development for UCD-related
changes to be introduced. Significant UI defects often
INTRODUCTION remain unaddressed in the released product.
What is the current market situation for user-centered At Siemens Corporate Research, we have seen both
design (UCD) and software engineering (SE) software of these problems repeated in our consulting
providers? Scarce resources force providers to experience. We believe that we have addressed both
achieve more with much less and, at a minimum, to of them by introducing UCD techniques directly into
maintain the status quo of quality. the software development process. Our requirements
Managers and decision makers in the software team includes UCD expertise as well as traditional
industry are increasingly demanding quick turn-around requirements engineering expertise; in addition, we
in software development and related tasks. In this create a storyboard for each client scenario, and use
context, both schedule and feature content are often that storyboard to capture overall client requirements.
dictated by market window, without regard for quality While the storyboard may be translated or
or feasibility. Software Engineers have responded decomposed into individual scenarios or story cards, it
with a shift from traditional, plan-driven approaches to provides a graphical narrative that communicates
more “agile” methods, relying on short development directly with the client. It can be reviewed by both
cycles and requiring frequent client interaction to client and requirements teams during software
create a climate where developers and clients can development, and can be used to verify correct
agree on the combination of features and quality that function of the software within the development cycle.
can best meet the market needs. In effect, by We have thus adapted a combination of UCD and SE
engaging the client repeatedly in a series of interim methods and practices into the overall product
reviews, we can facilitate and speed the development development process. This can be seen as merely
process while continually aligning our project with user “common sense”: to tailor one’s design and
and market needs. In order to do this successfully,
1

2. development process to the needs of a specific quality, rely on a minimum development overhead
project. However, without a clear understanding and (e.g. minimum specifications), and have the capability
experience of both worlds, it is difficult to see the links to adapt continually to short-term changes.
and similarities. Projects cannot effectively capitalize
A traditional waterfall development model cannot
on the right methods to be used in UCD and SE.
deliver the code within a time frame of 6 weeks paired
Recently, more examples of intelligently combining with the other challenging constraints. It takes too
UCD and SE can be found be found. For example, much time to elicit the requirements, transform the
Extreme Programming and agile software requirements model into a design model, do the UI
development [2] were presented in one of the principal specification as well as the define the test cases.
software engineering conferences ICSE’03 [4,6,7]. This leads us to adopt an iterative approach, and to
There are 2 main streams identified by the research consider various agile methods. But even with agile
literature. One is the integration of UCD techniques methods, we have experienced limitations in gathering
into the software engineering process [7]. The other is feedback quickly enough to keep our severely
the active coordination and communication of the shortened development cycle on track.
UCD and SE processes running in parallel, and joined
To overcome these limitations, we propose aligning
by well-defined process interfaces [4].
UCD and SE processes as shown conceptually in
This position paper is an experience report of how figure 2. Each discipline (UCD + SE) is interconnected
UCD and SE practices can synergistically deliver with each other like in a “puzzle” process chain. UCD
client-centric and advanced software features. and SE people work either quasi parallel with each
other (independently) via clearly defined interfaces or
First, we will outline the overall process
jointly (integrated). Both approaches have its unique
applied in the development of hospital
advantages and challenges.
administration demo software system used for
sales and marketing purposes. . To build a set of feature using a UCD-SE process and
fit into a tight time window, the development team
Second, we present a thorough discussion of
needs to rely on software artifact(s) that can serve
how the process is accepted by all
multiple purposes, (e.g., from a requirements model
stakeholders.
to a design and test case model). Our experience
Third, we highlight the potential for future exploring the overlap of UCD and SE processes led to
work. the use of a single software artifact for design and
development of advanced product prototype demos
AN INTEGRATED DEVELOPMENT PROCESS [3].
Over the past 3 years within SCR, the User Interface
Overall, the optimized UCD-SE process consists of 3
Design Center and the Software Engineering
major activities (see figure 3): (i) Requirements, (ii)
Department have worked closely to streamline the
Design and Implementation, and (iii) Validation. The
product development process. Software engineers
key to this process is to use the storyboard as a
and user-centered design specialists work together to
single, unifying artifact across major activities.
deliver an advanced product prototype showcasing
hospital administration features
Requirements
A project where we typically try to capitalize on A small upfront effort identifies stakeholders in the
advantageous UCD or SE methodologies could start project scope (e.g. domain expert, user
as follows: A potential client requests that we assist representatives) and enumerates scenarios. The
them in developing a new feature set to be shown to development team then carries out a 2-hour client
customers at an up-coming conference. The client workshop with domain experts and composes the
typically has no feature requirements specified and basic story in terms of screen prints or sketches, task
often does not know what should be built. The flow (sequence of screens), and data requirements.
timeframe can be as little as 6 weeks. Of course, our
development team needs to deliver superior code
2

3. responsibility for these story cards, developing both
code and unit tests.
Validation
At regular intervals, we hold a “round-trip review” with
the client. All functionality is reviewed interactively,
and the client provides feedback on the
implementation of the storyboard. The storyboard is
updated during the review if possible. Client change
requests are often minor, but frequently, the review
process helps the client to understand new
Figure 1: Sample Storyboard Used for requirements.
Requirements Specification, UI Specification and Finally, the code is validated with a full regression test
Test Case for Regression using the storyboard as the test case specification.
The initial output of the client workshop is the
storyboard. We have been using MS PowerPoint as Retrospective
the tool to produce the storyboard. People can make In order to check the development process, the team
annotations on the screens such as data changes, carries out an improvement workshop at the end of
scenario steps, or an elaborated user interaction. The each development interval. This is an informal session
PowerPoint “Notes” section contains both a detailed where the entire team reflects on the previous interval
description of the user interaction and a data section. and documents what went well and what could be
improved. The output is an action plan that
The storyboard enables the following lines of activities formulates gradual improvements in the process such
in parallel: a) the development team is able to provide as a groupware tool for the development team and the
a good development estimate since the overall flow of client (LiveLink) and the adoption of coding standards.
the story is well defined, b) it can be used to evaluate
the complexity of the interaction to be developed, c) The overall development of the features in the
the user-centered design specialist can evaluate the example project took 3 ½ staff-weeks. If a traditional
level of usability using the wizard of Oz method (or waterfall approach were taken, we estimate it would
paper prototype usability testing), d) the client can have taken 8 to 12 weeks.
work with other domain experts to validate the
functional requirements e.g. defining a new advanced GAINING STAKEHOLDER ACCEPTANCE
feature set for a product e) Marketing people (clients)
can produce the demo script using the storyboard. We chose to start requirements capture through a
In our project, we have succeeded in eliciting workshop in response to our clients’ requirement for
concrete, buildable requirements from our clients an extremely short development schedule. In that
(marketing and sales staff) using a storyboard. This context, the choice of storyboard seemed a natural
way, the risk of late requirements changes can be way to document the workshop and provide rapid and
minimized as the story is visually present. The last high-quality feedback to our clients.
step in the “Requirements” phase is the storyboard Our clients have generally been quite happy with both
review in a read-out session to user representatives the workshop approach and the storyboard artifact.
where the whole development team attends and can They understood the storyboard without training, and
ask very specific questions on user interactions and they are comfortable using it. They have been able to
can clarify ambiguous domain details. In the 6-weeks propose and review changes in storyboards, and over
project, the requirements phase took 2 staff-weeks to time have learned to expect that we can capture and
create 1 simple, 2 medium and 1 high complexity implement their requirements efficiently and
storyboards. effectively.
Design and Implementation Initially, our storyboards were informal and
Next, the development team reviews the storyboard incomplete, capturing just enough for our
and decides how to decompose the screens and development team to get started. During
features into manageable coding activities. Activities development, we found that it was difficult to maintain
may support specific aspects of the storyboard, or communication with our clients at a sufficient level to
developers may create additional “story card” sustain the required development pace. Because of
equivalents that can be built up to support the this, we have over time begun to capture more
storyboard. Individuals or pairs of developers take complete information in the storyboards themselves,
3

4. so that each became a single record of customer • What is the common design language that
needs. UCD and SE specialists understand?
Another key item was how UCD and SE people • What UCD and SE processes/ methodologies/
collected, analyzed and validated the requirements, tools work in which situation and context?
achieving quasi-parallel threads of work for each
discipline in the project. In order to support • How can the business impact of the process
communication between team members with different optimization be measured in terms of
(UCD and SE) backgrounds, we needed a common economic added value?
language. The storyboard provided the means to • What are the best practices in the industry?
develop that language; moreover, since it uses a
metaphor the client is already comfortable with, it
promotes better communication all around.
ACKNOWLEDGMENTS
Conclusions The authors are very grateful to the Siemens
Carrying out a retrospective analysis of a series of Corporate Research Soarian Financial Vision Demo
projects conducted over the last 3 years, we have development team (including Herb Foster, Junius
come up with the following learnings regarding UCD Gunaratne, Steve Masticola, Gilberto Matos,
and SE process optimization. Christopher Nelson, and Raj Tanikella). The members
apply the depicted process on a daily basis and have
• Provide a clear rationale for the optimization contributed many ideas to further shape and refine
of UCD and SE processes (for instance, in this work.
terms of economic value or increased quality)
REFERENCES
• Every UCD and SE process optimization
needs to consider the type of project that is 1. Meyers B., Rosson M. B. Survey on User Interface
being carried out as well as which domain it Programming, CHI ’92, Conference Proceedings,
will contain. For example, storyboards make Monterrey, CA, 195-202
sense for advanced product prototype 2. Beck K., Extreme Programming Explained:
development in the healthcare sector, but may Embrace Change, 2000
not make sense for other project types or in 3. Siemens Medical Systems, Siemens Corporate
other domains. Research (invention disclosure from Arnold
• Rudorfer, Beatrice Hwong, Robin Kavanagh): Agile
Software Development Process Enables Rapid
• Collaboration of UCD & SE people builds an Application Development of Advanced Demo
understanding of each other’s processes. Prototype by Means of Multiple Use of Storyboard,
Therefore, the increased understanding can 12/03
avoid unhealthy competition within or across
projects. 4. Pardha S., Pyla, Manuel A. Quinones: Towards a
Model-based Framework for Integrating Usability
• The choice of storyboard is separate from the and Software Engineering Lifecycles, ICSE’03
decision to use a single artifact. The 5. Laurance, D., Rudorfer, A.: Optimizing Use of
storyboard seems to suit the problem domain Software Engineering & User-Centered Design
(healthcare information systems) well, but Practices in Demo Development, SAIG 8 Control
there may be other, more appropriate artifacts Systems Software Architecture Improvement
in other sectors. At the same time, the use of Group, October, 2003, Nuremberg
a single artifact appears to be motivated by
development schedule and problem size. 6. Paech B., Kohler K. Usability Engineering
Integrated with Requirements Engineering. in
FUTURE WORK Proceedings of ICSE’03 (International Conference
From the experience gathered so far, we are planning for Software Engineering – Portland, Oregon)
to diversify the UCD and SE process optimization idea 7. Ferre, X.: Integration of Usability Techniques into
to other types of projects and also to different domains Software Development Process, in Proceedings of
(e.g. Power Generation, Automation and Control). ICSE’03 (International Conference for Software
Specifically, we are further investigating the following Engineering – Portland, Oregon)
questions:
8. Cronin, D. RUP & Goal Directed Design. Toward a
• Can a general process model be built? New Development Process, July 2003,
http://www.cooper.com/content/insights/newsletters
/2003_07/RUP_&_GDD.asp
4

5. 5

6. Figure 2: Integrated UCD-SE Development Process
Requirements Design and Implementation Validation
Figure 3: Compressing the Integrated UCD-SE Development Process into 3 Major Blocks of Activities
6