FOCUS: PROFESSIONAL SOFTWARE DESIGN
Design Strategy
and Software
Design
Effectiveness
Antony Tang, Swinburne University of Technology
Hans van Vliet, VU University Amsterdam
// A study of software design activities establishes
four archetypical strategies that apply under different
circumstances. Designers can consider these
strategies among their early design decisions. //
SOFTWARE DESIGN STRATEGY is
about organizing design activities that
reflect the designers’ approach to creat-
ing a design, and the approach is often
opportunistic.1,2 Studies of design tech-
niques and software designers at work
indicate two important activity types
(see the “Related Work in Software De-
sign Strategies” sidebar):
• design space exploration is about
scoping the issues and deciding how
to approach the design, and
0 74 0 -74 5 9 / 12 / $ 3 1. 0 0 © 2 0 12 I E E E J A N U A R Y/ F E B R U A R Y 2 0 1 2
• problem-solving is about identify-
ing problems and finding solutions.
Designers can perform these activities in
different combinations and sequences.
For instance, they can begin by explor-
ing the whole design space broadly or
a particular design area in depth. They
can proceed during the actual design ac-
cording to a problem- or solution-driven
approach. Figure 1 shows the iterative
application of these activities.
Designers can switch strategically
between activities during the design
phase. However, the way they do so can
influence the final design’s effectiveness.
Choosing an approach that doesn’t fit
the problem will have a negative impact
on the design outcome. For instance, it
doesn’t make sense to start designing a
nationwide e-government system with
a depth-first approach because many
high-level issues must be considered
up front. Designers must understand
the scope of the design problem to plan
which activities to tackle early.
In a study based on a 2010 work-
shop at the University of California, Ir-
vine, we observed the design activities
and strategies employed by two teams
to design a traffic simulator. 3 Team M
and Team A consisted of two designers
each, and each team employed differ-
ent design strategies. Here, we evaluate
their effectiveness and identify four ar-
chetypal design strategies to use under
different circumstances.
Software Design
Exploration
Design exploration can be explicit or
implicit, elaborate or brief, and per-
formed before or during the actual
design. Depending on factors such as
designer experience and system com-
plexity, the way a design is planned can
significantly influence the end results.
As Figure 2a shows, Team M used a
breadth-first exploration strategy early
in the traffic simulator design. They
spent 9 minutes exploring the design
scope, using a drawing tool as a meta-
phor and concluding that they needed
to visualize the simulator. The tool calls
for a drawing area, which led to ques-
tions about which editing modes to dis-
tinguish and what objects to visualize
(such as cars, intersections, and sensors).
At this point, the team made no deci-
sions on how to model these elements;
they merely explored the issues broadly.
In minutes 21, 53, and 80, Team M
| IEEE S O F T W A R E  51
 FOCUS: PROFESSIONAL SOFTWARE DESIGN

RELATED WORK
IN SOFTWARE DESIGN STRATEGIES
Donald Schön suggests that the way designers frame problems
determines the features they focus on.1 Framing problems is a
strategy for planning design activities and managing the interplay
of design components. Carmen Zannier and her colleagues found
that the more structured the problem space is, the more rational is
the approach taken by designers.2 Linden Ball and Thomas Ormer-
od see the unstructured and opportunistic nature of design activi-
ties as the result of the cognitive constraints placed on designers.3
Raymonde Guindon suggests that designers are opportunistic in
following partial solutions, and the level of design structure de-
pends on the completeness of problem specification.4
Herbert Simon and Allen Newell describe how people generate
problem spaces when solving problems.5 They suggest six infor-
mation sources, such as previous experience and task descrip-
tions serving as guidelines. Marian Petre suggests designers use
14 strategies, such as identifying barriers, systematically exploring
solution possibilities, and developing assumption-consequence
scenarios.6
References
1. D.A. Schön, The Reflective Practitioner: How Professionals Think in Action,
Basic Books, 1983.
2. C. Zannier, M. Chiasson, and F. Maurer, “A Model of Design Decision Mak-
ing Based on Empirical Results of Interviews with Software Designers,”
Information and Software Technology, vol. 49, no. 6, 2007, pp. 637–653.
3. L.J. Ball and T.C. Ormerod, “Structured and Opportunistic Processing in
Design: A Critical Discussion,” Int’l J. Human-Computer Studies, vol. 43, no.
1, 1995, pp. 131–151.
4. R. Guindon, “Designing the Design Process: Exploiting Opportunis-
tic Thoughts,” Human-Computing Interaction, vol. 5, no. 2, 1990, pp.
305–344.
5. H. Simon and A. Newell, Human Problem Solving: The State of the Theory in
1970, Carnegie Mellon Univ., 1972.
6. M. Petre, “How Expert Engineering Teams Use Disciplines of Innovation,”
Design Studies, vol. 25, no. 5, 2004, pp. 477–493.

solutions. This reflects a depth-fi rst ex-

Design exploration
• Breadth-driven
• Depth-driven
FIGURE 1. Exercising strategic design activities. Designers can carry out design exploration
and problem-solving activities according to different strategies in different sequences and
iterations.
investigated the scope and evaluated
how to meet the design goals. The fi rst
time, they discussed the availability
of mathematical packages; the second
time, how to measure traffic flow; and
the third time, whether statistics would
be available to help them in the design.
These points represent a depth-fi rst ex-
ploration strategy.
Design problem-solving
Problem-
driven
Solution-
driven
Team A, on the other hand, spent
the fi rst 1.5 minutes investigating the
scope of the problem (see Figure 2b),
which they framed in terms of intersec-
tions and cars. They quickly noted the
problem’s time dimension—cars flow
through intersections, and both cars
and intersections must be modeled—
and spent the next hour discussing their
ploration approach.
Software Design
Problem-Solving
Designing software requires an un-
derstanding of domain-specific design
problems. Users and designers typi-
cally specify goals at a high level. As
the design proceeds, new and implicit
goals emerge, along with subgoals, and
become problems that designers must
identify and solve to achieve the goals.
Teams A and M used different prob-
lem-solving strategies. Team A used
a solution-driven strategy. In min-
ute 5, they were already making solu-
tion statements such as, “I’m thinking
in terms of MVC.” Then they decided
to use a queue to represent car move-
ments. With this data structure, cars
could pop from the queues when a light
turns green. They also decided to use a
controller to look after clock ticks.
Anchoring on a real-time, event-
driven solution, they continued to en-
hance this solution over the next hour
to handle intersections, left turns,

52 I E E E S O F T W A R E | W W W. C O M P U T E R . O R G / S O F T W A R E
 Exploration-breadth PS-coevolution Problem-driven PS-coevolution
Exploration-depth Exploration-depth Exploration-depth
10

8
No. of statements

0
1 11 21 31 41 51 61 71 81 91 101
(a) Team M

Exploration-depth Solution-driven Exploration-depth Solution-driven

4
No. of statements

0
1 11 21 31 41 51 61 71 81 91 101
(b) Team A
Design exploration
Problem framing
Solution identification

FIGURE 2. Design activities in terms of exploration and problem-solving: (a) Team M began with a breadth-first approach to design
exploration, and (b) Team A began with an in-depth exploration approach. The vertical axis shows the number of discussion statements on
design exploration, problem framing, and solution identification over the duration of the study.

traffic light timing, sensors, and traffic on problem identification.4 They suggest proposing solutions, asking questions
density. Accommodating these new is- that a solution can evolve with a prob- such as, “What are the effects of X?”
sues more and more complex, and they lem in a process called problem-solution In minute 54, Team M had a burst of
spent much time discussing the solu- coevolution (PS-coevolution). Software questions lasting about 10 minutes (see
tion but little time discussing the prob- design methods such as twin peaks and Figure 2a). During this time, they ana-
lems (see Figure 2b). In minute 77, they problem frames have a similar idea of co- lyzed issues relating to timing, traffic
saw that time was running out and de- evolving problems and solutions. density, and traffic flow. In the PS-co-
cided to abandon their approach and For the most part, Team M followed evolutionary approach, such question-
revisit the design scope, where they de- a PS-coevolution strategy. Through- ing appeared to have given Team M
cided to focus on code design and user out the design session, they alternated new insights, and the solutions that fol-
interaction. between raising design issues and pro- lowed addressed initiating traffic into
Kees Dorst and Nigel Cross show that posing solutions. They fi nally spent as the simulation model.
solutions are discovered and evolve based much time exploring the problems as Team M identified many more

J A N U A R Y/ F E B R U A R Y 2 0 1 2 | IEEE S O F T W A R E 53
 FOCUS: PROFESSIONAL SOFTWARE DESIGN
Problem-driven Solution-driven
Design exploration
Breadth-first
strategies
Depth-first
Low
FIGURE 3. Archetypal software design strategies. Complexity is about a system’s size
and difficulty. Experience is about a designer’s familiarity with the specific problems and the
system solutions.
problem statements than Team A.
Team M’s problem statements repre-
sented 31.9 percent of the total num-
ber of statements they made during
the study, compared to Team A’s 13.4
percent. Basically, Team M formulated
their design problems thoroughly while
creating their solution. This facilitated
a focused design discourse that reduced
design context switching. 3
Design Strategies
We’ve so far considered design ex-
ploration and design problem-solving
separately. The study teams performed
these activities without explicit discus-
sion or any conscious strategies. We
propose combining these two dimen-
sions to support conscious strategic de-
sign choices.
Figure 3 is a matrix of four arche-
typal design strategies that address
breadth-fi rst versus depth-fi rst ap-
proaches to design space exploration
and problem-driven versus solution-
driven approaches to solving design
problems in the contexts of design com-
plexity and designer experience.
The upper-left quadrant is a scop-
ing/questioning strategy. It applies to
green-field and complex systems in
54 I E E E S O F T W A R E | W W W. C O M P U T E R . O R G / S O F T W A R E
Problem-solving strategies
High
Scoping/ Scoping/
questioning solving
Complexity
No-scoping/ No-scoping/
questioning solving
Low
High
Experience
which designers have no prior experi-
ence. In these cases, designers need to
explore the design’s goals and scope
fi rst to understand the issues broadly.
This helps them appreciate high-level
relationships between issues, so they
can plan and prioritize activities. When
they begin searching for a solution,
they will identify new problems that re-
quire frequent backtracking as the solu-
tion evolves. This fits a context of high
system complexity and low design ex-
perience in the problem domain.
The upper-right quadrant is a scop-
ing/solving strategy. It involves using
packaged or known solutions in ap-
plication domains where the prob-
lems are well known and a solution is
readily available. Designers start with
exploring and setting the scope to en-
sure that no major surprises exist in de-
ploying a solution. If the target system
falls within the solution’s known capa-
bilities, the designers must explore few
design problems. This strategy fits a
context of high system complexity and
high design experience.
The lower-left quadrant is a no-
scoping/questioning strategy. It applies
when designers are familiar with the
design’s overall scope but not certain
aspects of it. Examples include tech-
nical and algorithmic problems such
as the security implementation. While
searching for a solution, designers
must regularly backtrack to explore the
problem space.
Finally, the lower-right quadrant is
a no-scoping/solving strategy. It applies
when the design problem and solution
are well-known. It fits a context of low
system complexity and high designer
experience.
Selecting the right combination of
strategies given the nature of a particu-
lar problem type at the right moment
is important in positioning how best to
design, but selecting a wrong strategy
can give rise to design problems.
Strategy and Design Effectiveness
Although the concepts of traffic lanes
and lights, intersections, and car queu-
ing are common and appear to be sim-
ple, building a traffic simulator to repre-
sent these relationships and events in real
time is complex. The two design teams
took different strategies in their design.
Initially, Team A worked from a no-
scoping/solving strategy. Because they
didn’t have a broad scope of design is-
sues from the beginning, they couldn’t
prioritize all the problems. These issues
arose as the team developed their solu-
tions and forced them to switch design
topics. Team A context-switched de-
sign topics in 1 out of every 4 discus-
sions. As the design problems grew
more complicated over time, they had
to revisit the same problem again and
again. Team A’s ratio of problem-to-
solution statements is 1 to 3, indicating
their strong preference for the solution-
driven strategy that led them to anchor
on a solution prematurely. The initial
solution wasn’t as suitable as it fi rst ap-
peared, so the problems gradually be-
came more difficult to tackle.
On the other hand, Team M worked
from a scoping/questioning strategy.
Using a PS-coevolution strategy, Team
M’s ratio of problem-to-solution
statements was almost 1 to 1, showing

ABOUT THE AUTHORS

that they explored the problem space
more thoroughly. The combination of
these strategies meant that they con-
text-switched design topics less fre-
quently, 1 in every 7.7 discussions,
making their discussions more effec-
tive. A depth-fi rst strategy like this is
effective when the issues in that area
are well understood, and the design-
ers don’t have to branch off to tackle
side issues.
Traffic simulation is complex, and
its design issues were new to all four
designers. Under these circumstances,
the scoping/questioning strategy is
more effective because the in-depth
design that follows a systematic prob-
lem exploration helps minimize con-
text switching. A no-scoping/solving
strategy potentially postpones problem
identification, but in Team A’s case, the
solution-anchoring effect appeared to
encourage the team to stay with their
solution. In other words, having settled
on a solution prematurely, they were
reluctant to abandon it and backtrack
to a better option. 3
Strategy and Design Context
A design problem’s complexity is rela-
tive to both the problem’s difficulty and
the designers’ experience in the relevant
application and technical domains. A
designer might have worked for many
years but can still be relatively inexperi-
enced with a new domain and technol-
ANTONY TANG is an associate professor in Swinburne University
of Technology’s Faculty of Information and Computer Technology, His
research interests include software architecture design reasoning,
software development processes, and knowledge engineering. Tang
received his PhD in information technology from the Swinburne Univer-
sity of Technology. He’s a member of the ACM. Contact him at atang@
swin.edu.au.
HANS VAN VLIET is a professor of software engineering at the VU
University Amsterdam. His research interests include software
architecture, knowledge management in software development, global
software development, and empirical software engineering. Vliet has a
PhD in computer science from the University of Amsterdam. He wrote
Software Engineering: Principles and Practice (3rd eds., Wiley, 2008).
He’s a member of the IFIP Working Group 2.10 on software architecture
and editor in chief of the Journal of Systems and Software. Contact him
at hans@cs.vu.nl.
solution is available, then using a ques- ACKNOWLEDGMENTS
tioning strategy to revisit solved prob- The US National Science Foundation fund-
ed the design sessions and corresponding
lems would be a waste of time. Instead,
workshop under award CCF-0845840. We
designers should choose a scoping/solv- thank the designers who participated in the
ing strategy. As new information and sessions that provided the input data to this
design issues are discovered, a seem- project. We thank the organizers, André van
der Hoek, Marian Petre, and Alex Baker, for
ingly simple design can become more
granting access to the transcripts and video
complex than fi rst anticipated. Newly data. We also thank the anonymous review-
discovered design issues may impact ers for their invaluable suggestions in im-
the design strategy. Designers need to proving this article. The Dutch Regeling Ken-
niswerkers partially sponsors our work under
choose a suitable strategy conscien-
project KWR09164.
tiously and adopt new strategies as the
context changes.

ogy. Moreover, a design problem that
appears complex to one designer might
be familiar to another. Mismatches be-
tween the contexts and strategies can
reduce design effectiveness and qual-
ity. If we consider study teams design-
ing the traffic simulator, the design is
complex, and none of the designers has
experience in the domain. Team M’s
choice of a scoping/questioning strat-
egy was more effective than Team A’s
no-scoping/solving strategy.
If designers are experienced in a cer-
tain application domain and a packaged
O
ur study shows that the mis-
use of a design strategy can
result in less effective designs.
The reasons lie in frequent switching of
design contexts and in revisiting design
solutions that don’t clearly articulate the
design problems. Deciding what strate-
gies to use, implicitly or explicitly, dic-
tates the course of design actions and
thus the design’s effectiveness. More un-
derstanding of these “meta” decisions
and their impact on design should help
reduce mistakes and wasted time.
References
1. W. Visser and J.-M. Hoc, “Expert Software
Design Strategies,” Psychology of Program-
ming, J.-M. Hoc, ed., Academic Press, 1990,
pp. 239-274.
2. R. Guindon and B. Curtis, “Control of Cogni-
tive Processes during Software Design: What
Tools Are Needed?” Proc. SIGCHI Conf. Hu-
man Factors in Computing Systems (SIGCHI
88), ACM Press, 1988, pp. 263-268.
3. A. Tang et al., “What Makes Software Design
Effective?” Design Studies, vol. 31, no. 5,
2010, pp. 614–640,
4. K. Dorst and N. Cross, “Creativity in the
Design Space: Co-evolution of Problem-
Solution,” Design Studies, vol. 22, no. 5,
2001, pp. 425–437.

J A N U A R Y/ F E B R U A R Y 2 0 1 2 | IEEE S O F T W A R E 55