FOCUS: PROFESSIONAL SOFTWARE DESIGN
Strategies
for Early-Stage
Collaborative
Design
Ania Dilmaghani, Oracle
Jim Dibble, Cooper
// A set of 10 design session ground rules can significantly
enhance the process and output of early-stage design. //
SOFTWARE DESIGN CONSISTS of
an ongoing series of decisions, from
the development project’s initiation
and the elicitation of requirements to
the initial system architecture sketches
to a developer’s choices of suitable al-
gorithms, data structures, and user in-
terface controls. Early-stage design re-
fers to the set of design decisions that
occur at product inception, when the
software design team has a rough un-
derstanding of the problem and a vague
set of requirements. A nontrivial por-
tion of a software team’s initial work
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
involves improving their understanding
of the problem domain to produce a de-
sign that addresses users’ needs. Early-
stage design, then, involves the creative
exploration of both the design problem
and its possible solutions.
Almost every software project re-
quires broad thinking from multiple
perspectives. Software architects, inter-
action designers, and developers must
collaborate to understand the problem,
generate potential solutions, and evalu-
ate those solutions, so that they arrive
at an innovative and effective design
that the team can subsequently imple-
ment. Surprisingly, many software
companies today still have individuals
performing much or all of the design
alone, producing detailed technical
project plans that include major flaws
that aren’t discovered during cursory
project plan reviews; often no one finds
them until implementation or even well
thereafter, when the system is deployed
and in use.
Collaboration during early-stage de-
sign can catch crucial flaws in both the
problem analysis and the proposed so-
lution. Design partners can challenge
assumptions, identify potential road-
blocks, and help ensure that design de-
cisions are airtight. However, not every
collaborative design session succeeds—
locking multiple designers in a room
doesn’t guarantee progress. By devising
a strategy for collaborative work ses-
sions, designers can participate in more
productive and creative sessions. A col-
laborative design session is more likely
to succeed when designers agree on
ground rules for conducting the session.
Figure 1 shows the authors’ collabora-
tive design session in a research study of
professional software designers.
Here, we present 10 ground rules
for collaborative design sessions that
can significantly enhance the process
and output of early-stage design. We’ve
distilled them from our individual and
joint experiences of software design
over roughly 25 years, 15 companies,
and scores of projects. We’ve selected
and honed them through an iterative
process of reflection and application;
we include them when inducting new
team members and use them to guide
our own practice. Making the most
of collaborative design results in clear
gains: uncovering assumptions, coor-
dinating design thinking, identifying
conflicts and misconceptions, explor-
ing alternatives, and fortifying the de-
sign rationale.
| IEEE S O F T W A R E  39
 FOCUS: PROFESSIONAL SOFTWARE DESIGN

FIGURE 1. The authors participated as research subjects in the Studying Professional Software Design study. During the collaborative
design session, we were tasked with designing a traffic control simulation system for civil engineering students. These video stills capture our
interaction during the design session.

40 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
Agree on
Agenda and Goals
When a design team gathers to address
a complex problem, the number of is-
sues can be overwhelming. The team
might disagree on which issues to ad-
dress, leading to long-running meet-
ings without clear outcomes. Most
designers have participated in un-
structured meetings that seem to drag
on forever, losing both energy and
momentum.
To ensure progress, designers should
plan a collaborative design session just
as they would plan any other meeting.
By setting time limits and achievement
goals, designers can force themselves
to focus on the fundamental problems.
Should the design session result in the
software architecture? The interaction
framework? The detailed design of a
specific component? Or are the design-
ers refining the requirements by work-
ing through a set of user scenarios?
By identifying the meeting’s goals
up front, designers can reduce the pos-
sibility of digression because all par-
ticipants are on the same page from the
beginning. Each collaborator takes re-
sponsibility for keeping the meeting on
track and steering side conversations
back to the meeting’s stated purpose.
If the team must address multiple prob-
lems, they can explicitly “time box”
each topic to guarantee time for discus-
sion. While this sometimes means that
designers must table a topic that hasn’t
been fully addressed, they typically
make progress across the board. They
might even have an easier time with the
topic later, after addressing other prob-
lems that shed light on it.
Determine
the Target Users
On a large project, the problem space’s
scope and complexity can overwhelm
the team. Brainstorming discussions
can take the team in multiple direc-
tions because different individuals
have different priorities and expertise.
Individual designers might fixate on a
few detailed design problems, while
failing to address the core design issues.
When collaborators don’t first agree
on the scope and nature of the design
problem, misunderstandings and faulty
assumptions can occur.
Collaborative design gives the best
results when designers work from a
shared understanding of target users.
By defining user goals before address-
ing implementation concerns, designers
can generate innovative solutions that
better meet user needs.
To ensure progress, designers should plan
a collaborative design session just as they
would plan any other meeting.
For almost all software systems, de-
signers should identify target users as
the first step toward agreeing on the
problem scope. This provides a com-
mon frame of reference for design deci-
sions. They should start by discussing
their current understanding of the tar-
get users, their work context, technical
experience, attitudes, behaviors, and
goals. If they don’t have a clear under-
standing of these factors, they should
find a way to learn more about them.
Then they can explore requirements
from the target users’ perspectives.
Reframe Requirements
around Users
Product requirements can come from
internal and external sources includ-
ing executives, marketing information,
sales data, competitive analysis, mar-
ket analysis, existing customers, po-
tential customers, and users. When col-
lected into a single document as a list
of features, these requirements often
lack a holistic product vision: stated re-
quirements are in conflict, crucial fea-
tures are missing, and prioritization
J A N U A R Y/ F E B R U A R Y 2 0 1 2
is unclear. Implementing the require-
ments directly as stated can produce a
system that’s a patchwork of features.
Such a system might seem intuitive to
its implementers but often makes little
or no sense to target users.
Early-stage design becomes the pro-
cess of converting feature lists into an
integrated product vision, structured
around user goals and usage context.
Creating this holistic vision doesn’t in-
volve simple requirements translation
but instead is an ongoing process of
discovery.
Scenarios are great tools for explor-
ing target users’ needs and framing the
problem from their perspective. With
user scenarios, designers can organize
the activities suggested by the require-
ments into a plausible narrative of tar-
get users’ usage patterns. Scenarios let
designers organize and prioritize fea-
tures based on users’ needs. Designers
can refactor the original requirements
list, adding features crucial to achiev-
ing user goals and downgrading fea-
tures incidental to product usage.
Sketch the
Problem Domain
To begin understanding the problem
domain, designers often sketch dia-
grams and pictures to communicate
ideas. Diagrams offer a great way to ex-
amine the relationships among objects
in the problem domain, as well as the
ways users might interact with them.
However, designers often feel obligated
to formalize their notation and nomen-
clature early in the process. Formal
notation can lead designers to make
premature design decisions because
| IEEE S O F T W A R E  41
 FOCUS: PROFESSIONAL SOFTWARE DESIGN

DESIGN SCORECARD
In early 2009, we participated as research subjects in the
Studying Professional Software Design study. In the research,
design pairs were allotted two hours to design a traffic control
simulation system for use in civil engineering university classes,
for a hypothetical customer, Professor E.1 We evaluated the
effectiveness of our two-hour design session using our design
ground rules.
AGREE ON AGENDA AND GOALS: NO
We didn’t draw up an agenda or plan our session. The two hours
moved quickly, and we had many design topics still to address
when the researchers give us our 20-minute warning.
DETERMINE THE TARGET USERS: YES
During our design session, we acknowledged the separate needs
of the customer (the civil engineering professor, Professor E) and
the users (her students).
REFRAME REQUIREMENTS
AROUND USERS: YES
We spent a fair amount of time going over the requirements
to understand the application’s various uses. This led us to
discover that students would need to save their maps, traffic light
settings, and simulation settings independently so that they could
experiment with the system’s ability to deal with different traffic
loads.
SKETCH THE PROBLEM DOMAIN: YES
We spent a good portion of the session drawing images of roads,
intersections, traffic lights, and cars to understand the interactions
of objects in the problem domain. Only at the very end did we
sketch out a preliminary entity-relationship diagram, based on
what we learned about the problem domain.
DRIVE TO A SOLUTION: YES
We actively participated in the design discussion; Jim drew
potential solutions at the board, while Ania asked probing
questions and offered new design ideas. While we sometimes
traded roles during the design session, we typically didn’t draw at
the whiteboard simultaneously. We went back and forth proposing
ideas and building on each other’s insights.
FOSTER COMMUNICATION: YES
We used hedging and inviting words, such as “maybe,”
“perhaps,” “it might work this way,” and “what do you think?” We
intentionally used such language to foster discussion—hedging
language indicates openness to critiques of current ideas and
proposals of alternative ideas.
EVALUATE AS YOU GO: YES
As we came up with ideas, we tried to evaluate them against
the needs of our customers and users. Throughout the session
we kept asking questions: What will Professor E need? What will
the students want? How will we measure the success or failure
of a particular simulation? Frequently assessing proposed ideas
against the scenarios we established helped us determine which
solutions to pursue.
MINE DISAGREEMENTS: NO
In our design session, the point of disagreement centered on

the notation pushes them to think in
abstractions.
Early-stage design is not focused
on determining the full class hierarchy
or the exact entity names, but instead
on understanding the problem domain
and proposing a high-level solution.
Deciding too soon to express the prob-
lem area in a formal notation, such as
Unified Modeling Language (UML)
diagrams, can shift the focus from un-
derstanding the problem space to de-
signing a solution.
In early-stage design, designers
shouldn’t constrain themselves to a par-
ticular design notation. Instead, they
should use drawings that help them dis-
cuss and explore the problem domain.
Drawing schematics of real objects in
the problem domain can help designers
understand how those objects work. De-
signers should turn to formal notation—
such as class diagrams—only when they
understand how the objects interrelate.
Drive to a Solution
Once they understand the problem do-
main, designers can generate potential
solutions and choose a path for refine-
ment. They can brainstorm multiple
ideas and evaluate the pros and cons of
each to choose the best solution. Alter-
natively, designers can pick a reason-
able solution and walk it through a se-
ries of potential usage scenarios.
Collaborative design sessions can
become contentious when multiple
competing solutions are on the table.
Designers must move from generating
a broad range of solutions to refining a
single solution for the design problem.
A successful strategy here is to take

42 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
 the behavior of the “car” entity in the model—should each car
entity make independent choices about its route and speed? We
managed to move past the disagreement. However, we spent
too much time on this topic because we didn’t properly try to
understand each other’s underlying concerns.
decisions and understandings. In our real work, one of us would
have recorded the outcomes of our design session.
Reference
1. M. Petre, A.van der Hoek, and A. Baker, “Editorial,” Design Studies, vol. 31,
no. 6, 2010, pp. 533–544; doi:10.1016/j.destud.2010.09.001.

DON’T SWEAT THE DETAILS: YES

There were times when we delved
into details about how the traffic light
panel would be displayed or how the
user might configure an intersection.
Overall, however, we kept moving
forward. When questions arose that
we couldn’t answer or that required
stakeholder input, we took notes
and moved on. We frequently found
ourselves deferring decisions that could
be assessed by building and evaluating
a few quick prototypes later.

CAPTURE
DECISIONS: YES
As we moved forward in our design
and understanding of the problem
space, we kept iterating through the
decisions we had already made. At
several points, we took pictures of the
whiteboard before erasing and moving FIGURE A. Whiteboard snapshot from the authors’ collaborative design session. As part
on to the next level (see Figure A.) At of a research study, we collaboratively designed a traffic control simulation system. As design
the end of the session, we restated our work progressed, we captured our design decisions by snapping photos of our whiteboard.

on specific roles: one designer drives by
sketching and explaining ideas, while
others help to navigate to an opti-
mal solution. Dividing roles forces the
group to focus on a single solution’s
potential rather than arguing over dif-
ferent ideas. Having one designer lead
the session creates a central point of
interaction and provides momentum
for the group. The other designers
can help guide the design forward by
challenging underlying assumptions,
considering potential roadblocks, and
ensuring that design decisions have
solid rationale.
Foster Communication
Communication styles, in terms of both
verbal and body language, can strongly
influence a design session’s flow of
ideas. When designers raise voices to
win arguments, sigh in response to sug-
gestions, or dismiss others’ ideas out of
hand, they suppress ideas and impede
the resolution of potential problems.
Designers can choose com­munication
patterns that shape the design session
into a joint exploration rather than an
adversarial experience. They should
agree that any ideas put forward are
partial ideas, not fully refined solutions.
As such, designers can support and as-
sist each other in revising rather than
disposing of ideas, while remaining
open to the critique and questioning re-
quired to refine the solution.
Small changes in communica-
tion patterns can encourage the free
flow of ideas. By using active listening

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  43
 FOCUS: PROFESSIONAL SOFTWARE DESIGN
skills—avoiding interruptions, using
open body language, and summariz-
ing what they think they’ve heard—de-
signers can ensure they grasp a part-
ner’s concerns and incorporate them
into the evolving design. They can also
communicate critical feedback in a way
that shows respect. By explicitly us-
ing hedging words, such as “maybe,”
“perhaps,” and “might,” a designer
can convey openness to a collaborator’s
perspective. The ultimate goal of col-
laboration is to understand the problem
and arrive at a suitable solution—not
to individually lay claim to discovery
of the solution. Designers should leave
their egos at the door.
Evaluate as You Go
When designers envision several poten-
tial directions, a mechanism for evalu-
ating the effectiveness of various solu-
tions might not be immediately evident.
Determining the best solution can even
become contentious.
User scenarios are valuable tools for
evaluating potential solutions. Because
they keep users’ needs and goals front
and center, designers can use them to
shape, evaluate, and revise solutions.
Choose com­munication patterns that shape
the design session into a joint exploration
rather than an adversarial experience.
Designers choose a framework that
seems to meet users’ needs and walk
it through several usage scenarios.
During this process, designers refine
the proposals as they encounter un-
expected roadblocks or unanticipated
user needs. As they proceed, they can
add detail to the scenarios, using them
to record the system’s evolving struc-
ture. These refined scenarios prove use-
ful in later stages of implementation,
where development teams can use them
44 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
as starting points for manual and auto-
mated system tests.
Mine Disagreements
Disagreements inevitably occur. They
can block progress and eventually cre-
ate long-term strain in collaborative re-
lationships. Even with the best of inten-
tions, every design team will run into
areas of disagreement—over the scope
of the problem, the needs of the target
users, or potential solutions. This in-
evitability of disagreements leads many
people to avoid collaboration alto-
gether: why spend the workday arguing
with a colleague over who’s right?
Effective collaborators turn disagree-
ments into opportunities—they mine
disagreements for important insights
about the problem domain or the ways
in which different users might react to a
proposed solution. Although a disagree-
ment might seem like a simple difference
of opinion, it can point out fundamen-
tal problems, a mismatch in the under-
standing of the underlying problem, or
a lack of insight into the target users’
goals. While designers need to resolve
disagreements to make progress with
the design, they also need to under-
stand the root causes of disagreements
to make sure that the design is correct.
To get the true benefits of collab-
orative design, designers must learn to
work through disagreements. When a
disagreement arises, designers should
take a time-out from the discussion and
ask questions about the nature of the
disagreement:
• What underlying problem is being
solved by each proposed solution?
• Why is it important that the system
work this way?
• Are there any underlying as-
sumptions for either side of the
disagreement?
If a design team can’t get to the root
of the problem, they can call in a third
person for a new perspective. The new
person can shed light on the problem
by assessing how well the design op-
tions address users’ goals, by posing
additional questions, or by proposing a
novel solution. Alternatively, designers
might choose to table a disagreement,
giving them time to reflect on the issues
independently. By working to recognize
the source of disagreements, designers
can come to a more cohesive solution
that better meets the needs of the de-
sign problem.
Don’t Sweat the Details
Even the best-planned design sessions
can bog down in details. Every com-
plex system contains numerous design
problems spread through multiple lay-
ers of fidelity. Designers can easily
spend an inordinate amount of time on
spit-and-polish issues before founda-
tional decisions have been resolved. In
collaborative design, everyone shares
responsibility for ensuring that the
group doesn’t get lost in the weeds of
design.
The best designers stay at the right
level of detail for the problem at hand.
Designers should focus on foundational
issues during early design sessions. To
maintain momentum during these ses-
sions, they defer detailed issues to later
stages of the design, keeping in mind
that some questions might best be an-
swered through quick prototyping, user
testing, or implementation. When de-
signers encounter questions that they
can’t answer without external input,
they can record them for follow-up re-
search. If necessary, designers can hy-
pothesize answers so that they can pro-
ceed with the design.
Capture Decisions
Designers can easily forget all the is-
sues, decisions, and results covered in
a design session. They travel through
a maze of paths, sometimes backtrack-
ing when they reach a dead end. They
might make decisions and then reverse
them when they fi nd more optimal solu-
tions. They can raise new questions and
fi nd unexpected answers. When design-
ers fail to track the results of a design
session, they often have to revisit the
decisions that once seemed resolved.
To assure that decisions are re-
corded, designers should agree at the
start of a meeting who will take notes.
As the meeting progresses, the scribe
keeps a list of unresolved questions, ar-
eas for further research, and questions
for customers, users, colleagues, and
product owners. The scribe should also
snap photos of important diagrams and
whiteboard notes. At the end of the ses-
sion, the team should verbally summa-
rize decisions and capture outstanding
disagreements. Wikis are a great way
to share these notes, as they allow for
easy reference and ongoing conversa-
tion. Taking the time to document the
discussion can avoid everyone having
to revisit and rehash the issues.
C ollaborative design can serve
as a valuable technique
throughout the software devel-
opment process. It’s especially powerful
in early-stage design, while exploring the
problem domain, mapping out the user
interface, and determining the software
architecture. These tasks require a broad
scope of understanding that can often
only be accomplished by multiple people
working together on the design.
By agreeing on a structure for de-
sign sessions, designers can leverage the
power of collaboration, producing inno-
vative solutions without creating undue
friction. Design sessions work best when
designers set concrete goals, focus on the
big-picture decisions rather than design
ABOUT THE AUTHORS
ANIA DILMAGHANI is a development manager at Oracle, where she
leads the UI group responsible for the Web application of Oracle’s Busi-
ness Transaction Management product. Her interests include designing
and developing user interfaces and applications across a wide range of
technologies and user needs. Dilmaghani has a BS in computer science
from San Francisco State University. Contact her at aniad@yahoo.com.
JIM DIBBLE is an interaction designer at Cooper, a product strategy
and design consultancy in San Francisco. His interests include design-
ing enterprise software, consumer products, and mobile applications
to help people achieve their goals. Dibble has a BA in computer science
from Brown University. Contact him at jim@cooper.com.
details, agree on the target user, evalu- indicates, we can also forget to follow
ate design options with user scenarios, the ground rules consistently—but in
and focus on open communication over our experience they’re essential to effec-
notation. When designers do disagree, tive early design. We continue to employ
they can harness their disagreements to them, and encourage our colleagues to
produce a more refined solution. leverage them as much as possible.
We have learned these lessons over
our many years of software design. We Selected CS articles and columns
have certainly had our share of fail- are also available for free at
ures—as the “Design Scorecard” sidebar http://ComputingNow.computer.org.
Call for Articles
IEEE Software seeks practical,
readable articles that will appeal
to experts and nonexperts alike.
The magazine aims to deliver reliable
information to software developers
and managers to help them stay on
top of rapid technology change.
Author guidelines: www.computer.org/
software/author.htm
Further details: software@computer.org
www.computer.org/software
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 45