Extending the Situated Function-Behaviour-Structure
Framework for User-Centered Software Design
Matthias Uflacker and Alexander Zeier
Hasso Plattner Institute for IT Systems Engineering, Germany
We present an ontological extension for the situated function-behaviour-structure
framework to explicitly integrate the notion of user needs into the model and take
it as an able platform for mapping core elements of user-centered software design
to the framework. This allows us to reason about user-centered design as a conceptual and reflective conversation on interrelated design representations in a
social and dynamic context. Our model points out the requirement for computational design support to assist designers in sensing design information in context,
and provides a basis for understanding informational demands of design teams in
user-centered software engineering projects.
Introduction
The growing observance of user-centered design principles in software development allows us to draw on a more complete and satisfying perception
of design in a software engineering context. The notion of ‘software design’, once limited to a narrow set of pure architectural design and code
development activities, is now receiving widespread appreciation as a holistic and conceptual engineering methodology. Software design starts
long before structural decisions are being made and does not end after
code has been generated. It encourages creativity and innovation from day
one, encompassing need finding, user research and evaluation, and even
implies lifecycle aspects of a software product. A design-driven software
development process is capable of guiding a project team towards a usable,
feasible, and viable solution that satisfies the demands on the software.
Several user-centered design processes exist to provide the required
tools and methods for the activities that help in the development of useful
software solutions (e.g. Beyer and Holtzblatt 1998 [2]; Nielsen 1993 [13];
Vredenburg et al. 2001 [18]). Common to all of these approaches is a
strong and explicit focus on end-user needs, the specification of requireJ.S. Gero and A.K. Goel (eds.), Design Computing and Cognition ’08,
© Springer Science + Business Media B.V. 2008
241
242
M. Uflacker, A. Zeier
ments for an identified context of use, iterative prototyping, as well as repeated evaluation of the intermediary design solutions with the end-users.
An abstract view on a user-focused development process for interactive
systems is defined in ISO 13407 [9], which we use here to refer to these
core elements of user-centered design.
During the course of design collaboration, design teams accumulate
documents and generate artifacts that they use internally and externally to
communicate and share knowledge, insights and ideas about the design
state. This typically covers research results, contextual information, requirements, models, code, prototypes, test results, documentation, etc.,
which we collectively combine under the term design information, i.e. the
encoded knowledge and explicit representation of facts, ideas or emotions
that are relevant for the design process. There is the other world of implicit or tacit design knowledge that holds the design agent’s internal
representations of the design state space. This perception is strongly influenced by how the external environment is sensed, as well as by previous
experiences of the designer. From this theoretical point of view, design
becomes a function of the internal and external design representations as
they are interpreted by the designer, and which in return affects both of
these worlds through the actions the designer takes. Thus, the context of
design changes continuously through the recursive activities and interactions performed in a team. This concept of situatedness in design has been
described by Schön (1992) [17] as a reflective conversation with the materials of a design situation, in which he sketches design as the process of
“seeing-moving-seeing”: interpreting and making sense of the world (seeing), performing actions to affect a desired change (moving), and assessing
the effects in the changed environment (seeing), causing further actions or
the completion of the design cycle (cf. Clancey 1997 [3]; Winograd 1996
[20], pp.171–184).
This perspective on design reveals the importance for a design agent to
have a precise picture of the relevant design information in a larger context. This design context is not influenced by an individual alone, but is
constantly manipulated in a social, interacting and collaborative manner.
Having a holistic view on such a fluctuating design situation in a team, i.e.
achieving common ground among the stakeholders of a design process is a
crucial, yet challenging task in engineering design (cf. Bannon and Bødker
1997 [1]; Perry, Fruchter and Rosenberg 1999 [15]). However, this is further complicated by the growing technical complexity of software systems
being developed and the increasing global distribution of participants in a
development process. The collective work of a design team is more and
more related to information and knowledge that is distributed among different team members and geographical locations. This applies even more
Extending the FBS Framework for User-Centered Software Design
243
to a user-centered process, where inter-disciplinary collaboration and
knowledge accumulation is intensified, e.g. through repeated user research
and evaluation. As Layzell, Brereton and French (2000) [12] point out,
software engineering has become a social, team-based process and failure
to address interaction, communication and collaboration with design information appropriately will compromise the quality of a project.
Organizing and sharing this information within a project team is therefore a requirement for design progress. Understanding the nature of design
information and its relations is the goal of ongoing design research and a
prerequisite for building supportive tools. In order to better understand
and address the informational demands of user-centered design teams we
need a model to reason about design information in software engineering.
Therein, design must not be reduced to a discrete and static execution of
design methods on fixed data, but must rather be understood as a social,
conceptual activity that creates changes in the design environment based
on the context in which the design takes place. Identifying needs and
obtaining insights into the problem domain is a central part of design. Mapping the concepts of situatedness to the elements of a user-centered software engineering methodology gives us a valid starting point to improve
our understanding of design information and contextual relations in the
software domain.
For this reason, this work proposes an extension to Gero and Kannengiesser’s (2004) [6] situated function-behaviour-structure (FBS) framework
to explicitly incorporate need finding activities as a central part of a design
process, and continues by mapping elements of user-centered design to it.
In chapter 2, we consider situatedness in a team-based environment and
give a resumé of the situated FBS framework, which provides an ontological model for design activities and representations in dynamic engineering
processes. Chapter 3 builds up on this framework and extends it in order
to be able to capture specific characteristics of user-centered design. We
continue to show that the core activities of a user-centered process according to ISO 13407 are now consistent with the framework. In chapter 4 we
take the adapted model as a basis for discussing design context awareness
and the informational demands of designers in a user-centered process.
A general framework for situated design
Any attempt to model the process of conceptual designing isolated from
the dynamic context in which the design interactions are grounded will
provide very limited insights into the relationships between design agents
M. Uflacker, A. Zeier
244
and design representations. For this reason, we base our work on an approach that is respecting the situatedness of design activities and which
models design interactions in relation to the state of the design environment.
A model for situated design
Gero and Kannengiesser [6] have presented a general model for situatedness in engineering design processes that makes allowance for constant
modifications of the design state, based on present knowledge and expectations of the design agent. The relationships between design representations (X) and the design agent are represented as interactions between
mental and physical environments of the design process. These interactions are modeled as three recursively interacting worlds of intermediary
design representations (figure 1). We adopt a social view on these worlds,
to appropriately reflect the team orientation and inter-disciplinary work
environments of user-centered software design [8].
The external world is the physical world of encoded (tangible or digital)
design representations (Xe) outside the mental boundaries of a social collective. It holds the design information that has been collected and produced by the team, and which serves as input for successive design activities. The external world also provides documentation of the project state
and team communication.
The interpreted world is the world that is constructed inside the individual minds of designers, who collaborate by direct or indirect communicaExternal World
Interpreted World
Expected
World
Xei
Xi
Xe
= action
= interpretation / constructive memory
= focussing
Fig. 1. A model for situated design (after Gero and Kannengiesser [7])
Extending the FBS Framework for User-Centered Software Design
245
tions via their external world. The interpreted world describes the knowledge the team has about the external design environment as well as the
personal experience and memories (Xi). It is hence an individualized and
subjective perception of the design context at hand.
The expected world is embedded in the interpreted world, but comprises
the mental imaginations of a future design object and the predicted state of
the design after the accomplishment of planned or imagined actions (Xei).
These three worlds of design representations stay in close relationship to
each other through three classes of interactions:
1. Interpretation specifies the synthesis of design information in the external world into internal representations and concepts through sensation,
perception and conception [5]. This process of making sense of the external design context directly maps to Schön’s (1992) notion of “seeing”.
2. Focussing describes the collaborative generation of intermediary design solutions in an expected world, which is steered by the collective state
of the interpreted world.
3. Action transforms the envisioned design state from the expected
world into explicit design representations, affecting change in the external
world (which correlates to what Schön describes as “moving”).
A situated view on a design process can now be described as follows: In
a project scenario, encoded design information of the external world (Xe)
is interpreted by a design team, thus forming an internal representation of
the perceived design context (Xi). The model implies here the influence of
constructive memory, i.e. the design team’s knowledge and experience that
has been constructed through former interactions with the external world
(cf. Norman 2002 [14], pp. 54 ff.). This view on interpreting the external
world is connected to Gero and Fujii’s (2000) [5] concept of parallel push
and pull processes: the production of an internal representation is partially
pushed by the sensed data, but is also pulled by the agent’s current expectations. Mental representations of the expected design state (Xei) are ideated by the team members individually or in a collective by focusing on
the interpreted design context. Proper design actions are then carried out
that aim to affect an according change in the external world, thus starting a
new iteration of the situated process.
The situated FBS framework
Following Gero’s (1990) [4] differentiation schema for design knowledge,
design representations can be classified as descriptions of any of the three
aspects function (F), behaviour (B) and structure (S).
The function (F) of a design object describes what the object is for. E.g.
a spreadsheet application has the function “to provide a customizable set of
246
M. Uflacker, A. Zeier
data tuples”, “to allow entering and editing cell values”, and “to run arithmetic calculations on cell values”.
The behaviour (B) of a design object is conditioned to what the object
does. It is defined as the attributes that are derived or expected to be derived from its structure (S). The behaviour of the spreadsheet application
e.g. includes the “ability to handle multiple sheets”, the “time required to
import data”, and the “expressiveness of arithmetic instructions”.
The structure (S) of a design object is defined as “how the object is
built”. It describes the components of the object and their relationships.
The structure of the example spreadsheet application is expressed in software models and code.
Applying the model of situatedness to these three classes of design representations yields Gero and Kannengiesser’s situated framework for engineering design processes, depicted in figure 2. By instantiating the abstract notion of a design object (X), more specific representations for the
aspects of function, behaviour and structure in the external (Fe, Be, Se), interpreted (Fi, Bi, Si), and the expected world (Fei, Bei, Sei) are created. In
addition, representations for external requirements on function (FRe), behaviour (BRe) and structure (SRe) are integrated into the framework to take
the influence of external demands on the design process into account [7].
E.g. a structural requirement for a spreadsheet application could be the
compatibility with a specific hardware or software platform.
The different interactions between function, behaviour and structure in a
situated environment are represented by 20 processes shown in figure 2.
On top of these processes, the situated function-behaviour-structure
framework defines eight fundamental design steps.
1. Formulation consists of interpretations of external requirements
(processes 1–3), their augmentation by representations originating from
previous experiences (constructive memory, processes 4–6), the ideation
of an expected design state space (processes 7–9), and the formulation of
expected behaviour from the set of expected functionality (process 10).
2. Synthesis transforms the expected behaviour into an internal representation of an expected structure (process 11), which is then explicitly formulated by the design agent as an external representation of that structure,
making it available as input for later design activities (process 12).
3. Analysis comprises the interpretation of external representations of
the structure (process 13) and the internal derivation of behaviour (process
14).
4. Evaluation (process 15) describes the comparison of the expected behaviour and the interpreted behaviour derived through analysis.
Extending the FBS Framework for User-Centered Software Design
247
External World
Interpreted World
Expected
World
1
4
Fi
7
Fei
20
FRe
Fe
18
16
10
2
5
Be
Bi
8
i
19
BRe
Be
15
17
14
11
3
6
9
i
Se
Si
13
SRe
Se
12
=
=
=
=
transformation
comparison
interpretation / constructive memory
focussing
Fig. 2. The Situated FBS Framework (after Gero and Kannengiesser 2007a)
5. Documentation is the process of affecting change in the external
world by externalizing representations of the expected design state (processes 12, 17, 18) for the purpose of communication.
6. Reformulation type 1 implies changing the focus on expected structures (process 9) after re-interpreting representations of structure in the external world and constructive memory (processes 3, 6, 13).
7. Reformulation type 2 implies changing the focus on expected behaviour (process 8) after re-interpreting representations of behaviour in the
external world (processes 2, 19), constructive memory (process 5), and
structure (process 14).
8. Reformulation type 3 implies changing the focus on expected functions (process 7) after re-interpreting representations of function in the
external world (processes 1, 20), constructive memory (process 4), and
behaviour (process 16).
248
M. Uflacker, A. Zeier
Setting up the FBS framework for user-centered design
With the situated function-behaviour-structure framework, Gero and Kannengiesser have provided a descriptive perspective on the nature and process of engineering design. It appropriately reflects the dynamics and recursive relationships between the design agent’s internal state, activities
and external information. The framework is general enough to demonstrate flexibility and applicability, meaning that it does not specifically addresses one particular engineering discipline. Casting it to a particular
domain of choice can harmonize and enhance the understanding of more
concrete design processes. Kruchten (2005) [10] has proven that the
framework is applicable to software engineering processes by mapping
elements of the Rational Unified Process (RUP) to a previous, less detailed
version of the framework. Gero and Kannengiesser (2007a) [7] have
shown that the principles of “emergent design”, an evolutionary and agile
software development cycle, are consistent with their situated model of designing. Though dealing with software design, these works do not explicitly consider user-centeredness as a guiding principle for the design iterations. Elementary activities in a user-centered design approach, like user
research, need finding, or definition of a use context have not been discussed in reference to the situated FBS framework so far.
In its latest version, the FBS framework considers external demands by
employing requirements (XRe) as factors for the internal design activities
of a design agent. However, regarding product requirements as given or
explicitly available from external sources neglects the fact that many of
those requirements are unknown at the outset of a design task. Conceptual
design activities start earlier to unveil potential requirements that stem out
of initially hidden insights into end-user needs and the context of use. A
clear distinction between requirements and needs is therefore expedient in
user-centered design. Requirements are formal descriptions of necessary
attributes, capabilities or characteristics that must be provided by a future
software system. They account for business, technical, and user constraints and define the goals for the to-be-designed software product (e.g. a
specialized business application). Needs, on the other hand, describe the
status-quo, or the present condition of the end-user and the environment.
Needs represent user tasks, problems and possibilities in the context of use.
They are more informal in their specification and less binding as requirements, but provide essential input for the definition of requirements (Kujala, Kauppinen and Rekola 2001 [11]).
Both, needs and requirements are relatively unexplored in the beginning
of a design project. Through iterating field research and needs analysis,
Extending the FBS Framework for User-Centered Software Design
249
the picture of the user context becomes steadily more detailed and specified. Capturing insights and knowledge about the use context is important
for communication among the team and for later refinement. As a result,
the external design state is not only influenced through actions that aim to
transform expected function, behaviour or structure of an intermediary design object into reality. The picture of the external world also changes essentially through explicit documentation of insights, facts or decisions as a
result of interpreting external demands. This encoded representation about
the use context is generated, shared and communicated among the team
and later incorporated into further interactions and interpretations.
From this perspective, the FBS framework is missing some important
concepts in order to sufficiently provide a complete view on the activities
of a user-centered design process. The applied model of situatedness only
affects changes in the external world through actions that concern the realization of an expected or envisioned intermediary design state. The influence of the present conditions, constraints, targeted goals in terms of the
recursive interpretation and documentation of needs and requirements is
not reflected in the framework. Therefore, we motivate an extension of the
situated framework to address the abovementioned principles of usercentered design.
An ontological extension for situatedness
We adapt Gero and Kannengiesser’s model for situatedness to incorporate
the notion of user needs by introducing an additional class of external design representations XNe. At the beginning of a user-centered software
project, needs are considered to be mostly unknown and implicit. The design team starts to increase its understanding about the context of use
through incremental exposure, interpretation and documentation of contextual user information. This is supported through various methods for user
research and analysis, e.g. interviews, contextual inquiries or user observations, in which the representations of needs are refined and enriched. This
alternating interpretation and documentation process is considered in our
extension as a direct, symmetric interaction between the interpreted and
the external world. Gero and Fujii’s (2000) [5] concept of a parallel pushpull process is hence transformed to a combination of push, pull and publish, not only causing a state change in the interpreted, but also in the external world, in the representation of needs and requirements. Note that
documentation in this context does not refer to Gero’s notion of a design
step presented above, but describes the explicit publishing of interpretations of the external world. The extended model is shown in figure 3.
M. Uflacker, A. Zeier
250
External World
Interpreted World
Expected
World
2
4
Xei
Xi
6
5
=
=
=
=
3
XRe
Xe
XNe
1
transformation
interpretation / constructive memory
interpretation / constructive memory / documentation
focussing
Fig. 3. An ontological extension for the model of situatedness: external needs
(XNe) and documentation as a reaction of interpretation
The observance of user needs starts with the interpretation of already
explicitly encoded insights XNe or the discovery of user needs through
user research (process 1). The resulting representation of this interpreting
activity is influenced by the constructive memory of the designer (process
2). As an effect of this interpretation, the subjective perspective on enduser needs may be documented as a refined, possibly biased representation
(XNe) for communication with the team and successive design activities.
With the acquired interpretations of external needs, the design team can
continue to define or revise requirements. This is done through the interpretation of external representations of existing requirements (XRe, process
3), which is also a function of the other interpreted representations such as
needs (XNe, process 1), already existing design objects (Xe, process 6) and
constructive memory (process 2). This updated view on the external world
may yield in a reformulation of requirements and modification of their representation through documentation (process 3). The remaining interactions
between the interpreted and the expected world (process 4) and between
the expected and the external world (process 5) are not affected by our
extension.
Mapping the FBS framework to user-centered design
As an abstract representation of a user-centered design process, we take
the ISO 13407 [9] norm as reference for design processes for interactive
systems. The norm defines four basic user-centered design activities that
should take place during the iterative design cycle (figure 4). After having
Extending the FBS Framework for User-Centered Software Design
251
identified the need for a user-centered design approach, the process starts
with understanding and specifying the context of use. Essential knowledge
about the users, their characteristics, tasks and goals in the working environment is collected through contextual user research. Teams continue to
specify the user and organizational requirements in relation to the defined
context of use. This implies prioritizing requirements and usability criteria
and expressing them in measurable goals or terms that can be evaluated.
The next task is to produce design solutions that are concrete and understandable enough to be presentable to the user. Those intermediary design
solutions represent prototypes of the final system that are used for end-user
tests and evaluation. Depending on the state of development, these prototypes range from paper sketches up to high-fidelity and functional software
solutions. The evaluation of designs against requirements finishes a design iteration and marks the end of the process if the system satisfies the
specified requirements.
We will now show how these activities of user-centered software design
match into the FBS framework. With our ontological extension of situatedness, we are able to identify the core elements of a user-centered software design process.
Fig. 4. User-centered design activities defined by ISO 13407 [9]
Consistent to the conceptual differentiation between representations of
function, behaviour and structure, we integrate the interactions with functional needs (FNe), behavioral needs (BNe) and structural needs (SNe) as
M. Uflacker, A. Zeier
252
primary elements of the design process. The final integration into the situated FBS framework is presented in figure 5.
Understand and specify the context of use
Exploration of the use context starts with a deep investigation of user
needs and the interpretation/documentation of achieved findings. User
needs can concern functional, behavioural or structural aspects of the design (processes 21–23). A functional need that might be relevant in the
spreadsheet example could be for example that “users need to create and
run daily reports based on data in an existing enterprise system”. The internal perception of the context of use also depends on the previous experiences and knowledge of the designer (processes 4–6). In this case,
constructive memory can implicate the risk of not diving deep enough into
the world of the user, as the experience of the design agent might induce
early and misleading assumptions about the use context.
External World
Interpreted World
Expected
World
Fe
4
Fi
7
i
20
18
FRe
Fe
FNe
21
2
BRe
Be
BNe
16
10
5
Be
1
Bi
8
i
19
15
22
17
14
11
3
6
9
Sei
Si
13
12
=
=
=
=
=
Se
SRe
SNe
23
transformation
comparison
interpretation / constructive memory
interpretation / constructive memory / documentation
focussing
Fig. 5. Extended situated FBS framework
Extending the FBS Framework for User-Centered Software Design
253
According to ISO 13407, the output of this activity should be an adequately documented “description of the relevant characteristics of the user,
tasks and environment which identifies what aspects have an important
impact on the system design”. It is seen as a working document that is
made available to the design team to support design activities. Consequently, this description maps directly to the union of external need representations FNe, BNe and SNe.
Referring back to the design steps defined in the situated FBS framework, understanding and specifying the context of use marks the beginning
of a formulation process to create the initial design state space (cf. 2.2).
Specify the user and organizational requirements
Continuing the formulation of the design state space, design teams specify
the user and organizational requirements by interpreting requirements that
have already been explicitly defined for function, behaviour and structure
(processes 1–3). Taking into account user needs (processes 21–23) and
constructive memory (processes 4–6), the team starts to generate expectations for the future design and populates the design state space (processes
7–9). As part of the requirements analysis, measurable behaviours to mark
the fulfillment or non-fulfillment of functional expectations are formulated
(process 10). Requirement specifications are defined or re-defined accordingly and published in the external world for documentation purposes (via
the documentation part of processes 1–3).
The ISO norm stipulates an adequate documentation of prioritized,
confirmed and measurable requirements, which are specified here as representations of FRe, BRe and SRe. E.g. the functional need that has been formulated in the previous example might yield the functional requirement that
the system “has to provide the possibility to create and save templates for
reports” and that it “provides an easy interface for importing enterprise
data”. With the definition of requirements, the formulation of the design
state space is completed.
Produce design solutions
Producing design solutions not only involves the actual encoding of a design structure in the external world. It starts with a creativity phase and
ideation in the social, interpreted context of the design team. Based on internal representations of expected behaviour, the team starts to generate an
expected structure for the design object (process 11). This imaginary picture is then transformed to an explicit representation of the design object’s
structure (process 12), making the solution concrete and presentable to the
254
M. Uflacker, A. Zeier
users and team. Optionally, further external representations of intermediary or final design solutions are produced in order to document and communicate the behaviour (process 17) or function (process 18).
Thus, in terms of the design steps defined by the FBS framework, producing design solutions is composed of synthesis and documentation.
In the ISO norm, the production of design solutions is described to involve the use of existing knowledge to develop design proposals and the
explicit concretization of solutions by using simulations, models or mockups, etc. The former demand is fully addressed by the situatedness of the
framework and the internal representations Fi, Bi and Si that are constructed through interpretation and constructive memory, and on which the
generation of design solutions (Sei) is grounded. The concretization of design solutions is in line with the transformation of the expected design into
external representations Se, and optionally Be and Fe.
Evaluate designs against requirements
The evaluation of produced design solutions begins with an interpretation
of the externalized prototype (Se, process 13). This activity is governed by
the feedback that has been provided by end-users or experts during the
conducting of evaluation techniques. After interpretation, behaviour can
be derived from that structure (process 14), which allows to make statements about the design object’s overall performance. A comparison of the
analyzed behaviour (Bi) and the expected behaviour (Bei) shows whether
the design solution conforms to the expectations (process 15). While these
two steps correspond to the analysis and evaluation processes defined in
the FBS framework, one must differentiate here between two distinct denotations of the word ‘evaluation’: first is an external evaluation conducted
by the participants of the test procedures. Its goal is to collect feedback
from the test subjects about the performance of the system in terms of
measurement results, observations, surveys or user statements. After the
design team has analyzed these results, a second process of evaluation applies internally in the team to compare the expected and analyzed behaviour (which corresponds to Gero’s notion of evaluation in process 15).
According to ISO 13407, the aim of repeated acquisition of feedback
from potential users of the software is to assess how well the system meets
its goals and to select a design option that best fits the requirements. The
use of evaluation results in other design activities and the reporting of
feedback to the design should result in demonstrable changes in the system. The analyzed feedback can affect the structure of a design solution
by re-interpreting the external structure (process 13), constructive memory
of structure (process 6), the requirements on structure (process 3), or the
Extending the FBS Framework for User-Centered Software Design
255
structural needs (process 23). Changing the focus now on the expected
structures leads to the aforesaid changed state in the expected world (process 9). This structural consideration of evaluation results marks the reformulation type 1 of the FBS framework. We abstain from a detailed description for reformulation type 2 (behaviour) and reformulation type 3
(function), which are analogous to the one presented for structure.
Information awareness in situated design
Taking our extended model as a formal description for situated design, we
can identify basic informational demands of designers in user-centered
software projects. According to the definition of Gero (1990) [4], the act of
design is a “goal-oriented, constrained, decision-making, exploration, and
learning activity which operates within a context which depends on the designer’s perception of the context”. But how can design context be characterized? Its multilateral notion is often limited to a static design factor resulting from the design problem at hand and the environment of the design
object. For this work, we rather describe design context as the personal
awareness of a constantly changing situation in a design process, the set of
design representations, their relations, and hence the interpreted information and knowledge designers have about the state of a design process. Put
into a social, team-based project scenario, having context awareness allows
individuals to assess the present design information space, which is the result of and input for concerted design decisions and activities. With the
situated FBS framework, we can now extract a more precise picture of
what constitutes awareness in a user-centered design process. This is essential for the development of computational design support tools that aim
to assist collaborating design agents in sharing and enhancing information
awareness.
We describe two complementing properties of design context awareness
that can be sourced from our view on the FBS framework:
1. Awareness is shaped by the interpretation of external design representations and their relationships. From a distant perspective, the goal of
design is to transform a set of expected functionality (Fei) into an external
description of a design structure (Se) such that an artifact conforming to Se
will fulfill the functions in Fei (cf. Kruchten 2005 [10]). This non-linear
process is driven by external needs and requirements (XNe, XRe), producing a growing set of intermediary and interdependent design representations (F e, B e, Se). These interdependencies between representations
generated by the team are first of all tacit or implicitly anchored in the
256
M. Uflacker, A. Zeier
constructive memory of the designers and are rarely made available to
other process participants explicitly. They are shared though through individual or social actions and communication. Having a sense about what
and how representations are related with each other allows designers to get
a bigger picture of the current situation, to understand and assess particular
information in the design process correctly. The ability to perceive relationships between design representations improves the ability to interpret
the current design situation and to evaluate the options for future design
activities and decisions in a team.
2. Awareness is shaped by the relationships between external design
representations and humans. Conceptual designing is a human process.
The specification and externalization of needs (XNe), requirements (XRe)
or representations of a design object (via processes 12, 17, 18) is a subjective act performed by one or more individuals in the design process. Thus,
the information created can often directly be related to people who are involved in the design process (e.g. designers, users, etc.). Relationships
between (intermediate) design representations and individuals in a design
team express actions carried out by designers that led to a particular representation. Possible relations could be e.g. formulated as “contributed by”
or “revised by”. These relations are constructed implicitly during teambased communication and collaboration, and stimulate the perception of
knowledge distribution and team structure. Being informed about the relations between team members and design representations allows designers
to find answers to questions like “Who knows about …” or “Who did …?”
This brief characterization of information awareness indicates that the
potential of individuals to comprehend the design context in a specific design situation is closely connected to the integrity of the constructive
memory that is shared among the team. The constructive memory of a design team evolves through design interactions and collaboration of individuals. This is reflected in Wegner’s (1986) [19] transactive memory theory, which combines constructive memory processes of individual team
members in a collective ‘group mind’. However, a consistent distribution
of constructive memory among all process participants over the course of a
project is idealistic. Distributed teams and information, changes in the
team structure, individuals joining or leaving the design process, are common scenarios especially in larger software design projects, resulting in
knowledge that is disconnected and unshared. This creates the demand for
computational support of transactive memory processes for the provision
of a common, networked design information space in social collaboration
environments (cf. Bannon and Bødker 1997 [1]; Perry, Fruchter and
Spinelli 2001 [16]). Relationships between design representations, information, and people should be made explicit and provided to the design
Extending the FBS Framework for User-Centered Software Design
257
team to increase context awareness. The aforementioned factors influencing the awareness of the design context can serve as a first reference point
in the design of such systems and for addressing the informational demands of designers in a user-centered process.
Conclusion
We have presented an ontological extension for the situated functionbehaviour-structure framework. This was motivated by the fact that the
framework in its current state does not appropriately reflect central design
elements of a user-centered software design process. By introducing the
notion of user needs and documentation as the externalization of an interpreted use context, we have set up the framework to address basic concepts
of user-centeredness. We took ISO 13407 as a reference to identify the
core activities in a user-centered development process for interactive systems and were able to map those to the process entities in the extended
FBS framework. The four activities defined by the ISO norm (“understand
and specify the context of use”, “specify the user and organizational requirements”, “produce design solutions”, and “evaluate designs against
requirements”) were expressed as a composition of the eight design steps
provided by the FBS framework: formulation, synthesis, documentation,
analysis, evaluation, and reformulation type 1–3.
Based on the extended version of the design framework, we started a
closer investigation into the notion of design context and design awareness
in user-centered processes. Determining factors shaping information
awareness have been highlighted in the framework, describing the notion
of implicit relationships between design representations and designers.
This emphasizes the importance of having common ground, or a shared
understanding of the design situation in a team, and provides input for designing tools to support the socializing of constructive memory and sensing of design information in its context.
The added complexity that our ontological extension brings to the FBS
framework can be well justified with the increased explanatory power of
the model. The transfer of user-centered design principles to a situated
framework creates new potential for analyzing and reasoning about design
in software engineering processes. At the same time, the ontological extension is not bounded to concepts specific to the software domain. Preserving the generality of the framework, it is open for further discussions and
feedback from other engineering disciplines.
258
M. Uflacker, A. Zeier
References
1. Bannon L, Bødker S (1997) Constructing common information spaces.
ECSCW'97: Proceedings of the Fifth Conference on European Conference on
Computer-Supported Cooperative Work, Lancaster, UK: 81–96
2. Beyer H, Holtzblatt K (1998) Contextual design: defining customer-centered
systems. Morgan Kaufmann Publishers Inc., San Francisco, CA
3. Clancey WJ (1997) Situated cognition: on human knowledge and computer
representation. Cambridge University Press, Cambridge
4. Gero JS (1990) Design prototypes: a knowledge representation schema for design. AI Magazine 11(4): 26–36
5. Gero JS, Fujii H (2000) A computational framework for concept formation in
a situated design agent. Knowledge-Based Systems 13(6): 361–368
6. Gero JS, Kannengiesser U (2004) The situated function-behaviour-structure
framework. Design Studies 25(4): 373–391
7. Gero JS, Kannengiesser U (2007) An ontological model of emergent design in
software engineering. ICED07. Ecole Centrale de Paris: 70:1–12
8. Gero JS, Kannengiesser U (2007) An ontology of situated design teams.
AIEDAM 21(4): 379–391
9. ISO (1999) 13407 Human-centred design processes for interactive systems.
ISO 13407:1999(E)
10. Kruchten P (2005) Casting software design in the function-behavior-structure
framework. IEEE Software 22(2): 52–58
11. Kujala S, Kauppinen M, Rekola S (2001) Bridging the gap between user
needs and user requirements. Proceedings of PC-HCI 2001 Conference, Patras, Greece
12. Layzell P, Brereton OP, French A (2000) Supporting collaboration in distributed software engineering teams. APSEC ’00: Proceedings of the Seventh
Asia-Pacific Software Engineering Conference, Washington, DC
13. Nielsen J (1993) Usability engineering. Morgan Kaufmann Publishers, San
Francisco, CA
14. Norman DA (2002) The design of everyday things. Basic Books, New York
15. Perry MJ, Fruchter R, Rosenberg D (1999) Co-ordinating distributed knowledge: a study into the use of an organizational memory. Cognition, Technology & Work 1(3): 142–152
16. Perry MJ, Fruchter R, Spinelli G (2001) Spaces, traces and networked design.
HICSS '01: Proceedings of the 34th Annual Hawaii International Conference
on System Sciences, IEEE Computer Society, Washington, DC
17. Schön D (1992) Designing as reflective conversation with materials of a design situation. Research in Engineering Design 3: 131–147
18. Vredenburg K, Isensee S, Righi C (2001) User-centered design: an integrated
approach. Prentice Hall PTR, Upper Saddle River
19. Wegner DM (1986) Transactive memory: A contemporary analysis of the
group mind. In B Mullen and GR Goethals (eds), Theories of Group Behavior, Springer-Verlag, New York: 185–208
Extending the FBS Framework for User-Centered Software Design
259
20. Winograd T (1996) Bringing design to software. Addison Wesley, Reading,
MA