This framework represents a variation of Gero's FBS framework (e.g., [GK13]) and is meant to provide a general framework for thinking about design that is consistent with cognitive science, design theory, and systems theory.
It is still under development.
In keeping with Simon's definition [Sim81], designing is an activity that plans to intentionally alter the world.
As such, any truly deep theory about design and designing must remain consistent with our best understanding of reality. To see why PFBS makes sense in design, we will start by considering how we can generically model real things. From that, we'll see how we can describe any design process, albeit in general terms.
Throughout the following, a systems perspective is assumed.
Let's start by looking at an object that already exists. Consider the table shown to the right. What is it, really?
Without getting too philosophical - and to the extent that designers and engineers generally regard the world - the table is a collection of atoms, just like everything else. But the particular collection of atoms that is the table are of a sort, and arranged in a way, that we see “a table” rather than a rock, or a barracuda, or a cell phone.
Given the table's nature, we can describe it with a list of its inherent properties. These are properties (or characteristics, or attributes, or whatever you prefer to call them) that are, in combination, unique to a particular table, and that will generally not change unless the table becomes something else (we'll get to that shortly).
These inherent properties include: location, size, shape, material composition, thermal conductivity, poisson's ratio, inertia, electrical conductivity, viscosity (though not so much for a solid object like a table), and so on. If we collect all such properties and their values, we can uniquely identify a particular table among every table ever.
In particular, recognize that the properties of an object do not change (much) in response to stimuli to which the object is subjected. So, colour is not a property of the table, because its colour will depend on the colour of light shined on it. Instead, we would identify reflectivity (i.e., a description of how reflective the table is at different frequencies of light) as a property, because its reflectivity doesn't change depending on the light shined on it.
We can make a similar argument, and develop a similar description, for any other real object.
The boundary of the table is set to the extent of its properties. For instance, consider thermal conductivity. The table has a certain value of thermal conductivity, and the air around the table has a different value of thermal conductivity. If you graph the value of thermal conductivity in the space around the table (including the table's volume), you'll see a sudden discontinuity where the table ends and the atmosphere begins. That discontinuity marks the boundary of the table2).
An object's boundary separates the object from its context - everything else that isn't the object itself. A context is just a collection of other objects. In the case of the table, the context would normally include the surface it rests on, the air around it, objects resting on it, etc.
The structure of an object defines the object's response to stimulus. If we shine a light on the table (stimulus), the table reflects some of that light back (response). If we apply heat to the table (stimulus), the table's temperature will increase and it might change size slightly (response). If we put a weight on the table (stimulus), the table responds by deforming slightly (response).
The stimuli that “enter” the object arrive from somewhere outside of it - from the object's context. Changing the context changes (at least some of) the stimuli that will enter the object, which in turn will change (at least some of) the responses of the object.
If you think about it, structure is usually not directly observable from outside the system (e.g., by humans); it is only indirectly observable by way of behaviour. We can't even see the table, except for its ability to reflect light.
The degree and extent of the response of an object's structure to a stimulus is called the object's behaviour, and can (at least in principle) be fully described (e.g., via mathematics and the sciences) as a function of the object's structure and the inputs arriving from its context. This allows us to predict the behaviour of an object.
Notice that behaviour doesn't happen unless there are stimuli, which means behaviour cannot happen without considering an object's context, because all stimuli come from contexts. Also notice that, at the level of behaviour, the actual source of stimuli (i.e., what other object somewhere in the context is producing the stimuli) is entirely irrelevant. All that matters is the stimuli themselves.
An object's behaviour is like “consumption” of inputs (stimuli) and “production” of outputs (responses). From the point of view of the context, the object is a black box that transforms inputs into outputs. This transformation plays a role in the context. That is, the transformation of inputs to outputs allows other objects in the context to now use the one object's outputs as their own inputs.
In conventional design engineering, the inputs and outputs that form behaviour are flows of either mass, or energy, or information.
For instance, a wooden table has behaviours of resisting deformation when loaded, and combusting when sufficiently heated. In the context of a classroom, its behavior enables a functions of supporting teaching materials, providing a work surface, etc. However, in the context of a cold forest at night, the table enables the functions of providing heat and light to people. Same object, same behaviors; different context; very different functions.
An object can provide many different functions in a context, with only a few behaviours. Of all the functions that an object may provide, only a few are intended.
Function appears only in the presence of a context, which includes all the cosystems. Just as behaviour does not happen without stimuli/inputs, so too function does not happen without context - i.e., without co-systems with which the object system can interact.
It can be very tricky to distinguish between behaviour and function. They are really descriptions of the same phenomena, but from different perspectives.
Behaviour describes the response of an object to stimulus. As such, it depends on the stimuli and on the structure of the object. Behaviour doesn't refer to any entities; it describes phenomena an object can exhibit in isolation of context.
Function, on the other hand, is a description of a state change in the context of the object resulting from changes in the context from the “consumption” of inputs, and the “production” of outputs, by the object. In functional descriptions, neither the structure nor the behaviour of the object is referenced. The functional perspective focuses only on interaction of an object (system) with its co-systems, all within a given supersystem.
Switching between behavioural and functional perspectives allows one to focus on different aspects of a system. When switching from a behavioural perspective to a functional perspective, one loses details of how the object system works, but gains detail on how the object interacts with other systems.
The intended functions of an object are the reason the object was created. Clearly, this does not apply to natural systems and object, but only to artificial ones; this is because there is no intent in nature. When functions are intended, those functions are given a special name - they are the purpose of the object.
In the case of the table, its purpose is to provide whatever functions motivated its designer to develop it originally. Many other functions arise from the designer's decisions about how the table should look, be, and perform its purpose. These other functions are derivative from, but not equal to, its purpose.
Put another way, purpose exists only for artificial objects, and is the reason(s) why the artifact was created.
Most generally, the purpose of any designed intervention is to fulfil a need. The needs we fulfil by designing stuff are not our needs; they're the needs of others - of our products-to-be's users. So to design well means to design for the needs of others.
Needs are typically defined with respect to goals - a goal is a condition that will exist in some future state of affairs toward which we progress. In the case of engineering, we progress toward goal states through the use of technology.
Needs can be good (e.g., lower traffic accidents) or bad (e.g., increase personal wealth at the expense of the wellbeing of others). This gets us into areas of engineering ethics of intention and unintended consequences; for example, would Henry Ford have automated the production of automobiles if he'd've known that the use of IC-powered vehicles would come to account for about 50% of all the GHGs that are causing climate change today?
Unfortunately, our prospective users typically don't know what they want. If they did, then we designers wouldn't be needed. Users will tell you what they want based on (usually) very naive reasoning about what's wrong with the way things are. While users don't know what they want, they usually do know exactly what's wrong with the current state of things.
In many ways, the designer's job is to elicit from their users what they see as wrong with the current state, and then to propose ways to make things better.
Remember: designers don't design toasters; they design ways to make toast3).
Consider the case of toothbrushes.
Exercise for the Reader
How many ways can you think of to clean teeth?
What assumptions are you making?
What happens if you relax those assumptions?
What if food itself could be used to clean teeth?
Think of how you would describe the operation of, say, an automobile; that is, think of how the automobile operates. Set aside any interactions of the automobile with its user for now. Excluding interactions with co-systems (like users), operation becomes a description of the internal working of the product. Behaviour maps inputs to outputs only. Operation describes how the inputs are turned into outputs.
Behaviour would describe the mapping between position of the accelerator pedal and torque produced at the drive wheels. Operation would describe everything that happens in between those two things.
An automobile is a system of co-systems (drivetrain, structural system, electrical system, passenger system, etc). Operation therefore describes causal and temporal phenomena between those co-systems in the automobile.
There is something else that exists as a description of how co-systems interact: function. So, is operation the same as function? Not exactly. Function describes the changes of state that occur among co-systems in a context. Those changes of state are not (necessarily) related to one another. Operation is what knits those state changes together, by describing the causal and temporal relationships between those state changes.
The following images show examples of the PFBS structure of various products and systems, and help distinguish between function, behaviour, and structure. Note that none of the examples are exhaustive; they're meant to help show the differences between the three concepts, and the scope of things that could, under the right conditions, be construed as structure, behaviour, and function.
Note the similarity of the structural and behavioural features for “products” versus larger systems. The differences in function arise from considering the various situations in which the specific objects might be used.
The table below will be removed as more diagrams are added above.
|Letter opener||location, size, shape, material composition, thermal conductivity, index of reflectivity, poisson's ratio, inertia, electrical conductivity||deformation under load, reflection (colour), reactions to chemicals and heat, acceleration and kinetic energy, changes of state (due to, say, combustion)||extend one's reach (e.g., to reach behind a cabinet for a fallen toy), self-defence (e.g., during a home invasion), kill insects, clean dirt from under one's fingernails, open letters & packages, puncture plastic bags|
|Doctor's Office||location, size, shape, access (doors, steps, parking, etc.), seating, distractions (magazines, TV, etc.), doctors, nurses, receptionist(s), medical equipment and supplies, lights, heating/cooling, washroom||uninformed patients transformed to informed patients (including prescriptions), unwell patients transformed to well patients (e.g., stitches for cuts), payment of employees, transformation of usable supplies to used supplies / garbage||maintain well-being of patients & community, provide a “living” for employees|
Exercise for the reader: For the functions given in the table above, think of other things that can provide them besides their corresponding items. Explain why these alternatives might work, and the behavioural and structural differences that exist.
A summary of PFBS is shown to the right.
When describing reality in the previous section, we began by considering what an object was, and working our way from that through behaviour and function, to its purpose. Designing is just like that, except backwards.
When we design, we begin with purpose. Designing happens in response to some realization that the current state of the world is less preferred - that is, we imagine a more preferred state of affairs than whatever we've currently got. To get to that preferred situation, we design some kind of intervention (usually an object, which may be a process rather than a physical thing) that, once implemented, will bring about the preferred state.
This means we begin designing by identifying the purpose(s) of the intervention. The purpose(s) are functions - roles that must be fulfilled in a given context that will bring about the preferred situation. This is done during problem analysis and results in requirements that must be satisfied by any acceptable design intervention.
Once we've established the purpose of the object to be designed, we start to define more crisply all of the functions we need the object to provide. Functions are always described with respect to contexts, so to define the functions appropriately, we need to have a good description of the context. This means we start with developing a good understanding of the context, then define the functions we need for that context. This is usually done during concept design.
When we have described all of the necessary functions, we can start looking for behaviours that will produce the required outputs from the inputs available in the context. This stage is usually called embodiment.
Finally, we can seek out structures, shapes, materials, etc. that will produce the required behaviours. This is usually done as detailed design.
Notice that this overall framework for designing is based on a rational and universal framework of reality and how we perceive and understand it.
It is very important to distinguish between intended and unintended function and behaviour.
I have a letter opener that I've never used to open letters, but that gets nearly daily use as a screwdriver, a tool to reach behind furniture, to clean dirt out from under my fingernails after gardening, and to kill bugs. I'm confident whoever designed the letter opener did not intend for it to fulfil those roles, but it can and does because of its behaviours in slightly different contexts to those considered by the designer.
4). Since the ethical designer will, as they say, “do no harm”, it is incumbent on us to be mindful of the ways in which our designs can be misused and abused, and to do what we can to mitigate the harms that can result.We assume no designer intends harmful functions or behaviours
At the same time, we have to be observant of new and beneficial uses that our products can be put to, and to improve our designs in response. For instance, decades ago, the Apple iPod was (mis)used by doctors to carry medical records between hospitals. Apple noted this, and it led them to consider alternative uses of the basic technology. This observation informed Apple's eventual design of the iPhone5).
In figure 4 we see a graphical representation of some of the relationships between beneficial and harmful functions that are intended or not. We would like at least all our intended functions to be in the green area. We can be ethically and legally liable for the harmful intended functions.
Exercise for the Reader Think of products you use every day, and list out their beneficial and harmful functions and behaviours. Now consider: is it possible to eliminate the harmful ones? How do we resolve the ethical conundrum here?
The systems perspective is important to (a) manage complexity of interactions between objects and (b) ground discussion about particular objects and their structures, behaviours, and functions.
When we think about the table, we treat it as a black box, a system that we are outside of and into which we cannot see. We treat other objects in the context of the table similarly: the floor, the air, the objects resting on the table - they are all treated as black boxes too. As such, we can measure the behaviours of the objects, and we can describe the interactions between those objects functionally.
If we are considering an automobile, we treat it as a black box system; we consider it a single, indivisible object that interacts with other objects (other cars, passengers, pedestrians, the road, the atmosphere/weather, etc.).
If we then “open” the black box automobile, we must abandon concerns of other objects that interact with the automobile and only consider the inputs that enter the automobile from the context. However, we can now consider the other systems that compose the automobile - the space frame, the drive train, the passenger compartment, etc. Each of these are now black box systems that interact within the boundaries of the automobile “supersystem.”
It's important to understand that the terms “subsystem” and “supersystem” are relative terms; they are always defined with respect to the system we are considering. If we are considering the drivetrain, then the automobile is the supersystem; if we are considering the automobile, then the larger “transportation system” of which it is an element is the supersystem.
A system essentially bounds (i.e., puts boundaries around) its subsystems. The collection of subsystems of a system are generally referred to as cosystems. For instance, the cosystems of the drivetrain of an automobile are all the other systems in the automobile that are direct/immediate subsystems of the automobile. Neither the valve train, nor the truck locking system, nor the cockpit instrument cluster are cosystems of the drivetrain because they exist elsewhere in the overall system hierarchy of the automobile.
Although this perspective is very powerful, it can also be confusing if one does not pay careful attention to where in a system hierarchy one is.
A feature in engineering design is a geometry element associated with a manufacturing process. Features cannot exist except as elements of some physical part. A bolt-hole, for instance, is a feature. The hole cannot exist alone; it can only exist as an element of the part into which the hole was put.
We can apply PFBS to features. In this case, the physical part is the supersystem, and the features are its constituents - black boxes that interact through their behaviours to produce a function of the physical part.
However, it is not common to think of features this way. As a general rule in conventional design engineering, we think of physical parts as the most “atomic” and indivisible elements, out of which literally infinite systems can be constructed. This notion of parts as atomic is consistent with how we have defined system boundaries.
Robust design is intended to lead to designs that exhibit functional insensitivity to environmental variations.
PFBS then can help here by clearly distinguishing function from behaviour. A functional description free of commitment to behaviour helps firmly establish the nature of those functions in light of contextual variations. Furthermore, having an “independent” functional description allows designers concerned with behaviour to focus on finding appropriate behaviours (and operations, and structures) to satisfy the functional requirements of robustness, knowing that they will not necessarily change the function of the artifact as they alter behaviour, operation, and structure to ensure robustness.
Designers can then change behaviour in response to contextual variations (which will manifest as variations in inputs to the artifact system) so as to maintain functionality at the system level.