DesignWIKI

Fil Salustri's Design Site

Site Tools


research:achieving_balance

Achieving Balance

Achieving balance is a better perspective on the general intent of designing, than is “problem solving.”

Initial ideas about designing as balancing have been presented at the 2009 Design Principles and Practises Conference. A concept map of the presentation made there is available.

Overview of "Balance"

My notion of balance emerged from thinking about what Chris Alexander calls misfits [Ale64]. A separate explanation of misfits and balance is available.

Balance is the notion that a situation can be modelled as a set of forces that all reach some kind of dynamic equilibrium, and that the job of the designer is to use a design intervention to alter the forces so as to change the dynamic equilibrium in a way favoured by the stakeholders. This notion of unbalanced forces is also noted by Don Norman, and is quite similar to the idea that contradiction drives change (TRIZ) and transformational learning ([FKL09]).

Balancing how things are (facts) with how we wish things were (needs & desires) requires that we have some pre-existing idea of at least some alternatives. That is, if you think the current situation is “bad,” then you must be comparing it to some other state that you think would at least be “better.” But if you have no idea that a better state is possible, you cannot recognize the shortcomings of the current situation. No one knew they wanted an iPhone until they saw it; and no one thought there was any reason to not throw sewage out a window until the technology existed to make toilets and sewage systems. This is a point also made by Don Norman.

So a significant part of creativity in design is being able to discover rather than invent things. This point was also evident in other great creative minds such as Steve Jobs and Edwin Land. John Sculley is quoted saying “He [Jobs] said if I asked someone who had only used a personal calculator what a Macintosh should be like they couldn’t have told me. There was no way to do consumer research on it so I had to go and create it and then show it to people and say now what do you think?” It should be noted that Jobs was responding to a similar comment made by Land; so, in fact, both these great creative minds agreed that products are more discovered than invented.

From a systems perspective, we can think of balance as follows. A situation is a system of stocks and flows. Each stock and flow is characterized by various parameters that obtain specific values when the system is in dynamic equilibrium. However, that point of dynamic equilibrium - of balance - is not preferred. The designer alters the characteristics of the stocks and flows, possibly introducing new ones or removing existent ones, to change the balance point to a more preferred one.

Example. In an article by Don Norman: “Southwest Airlines has been successful despite the fact that it ignores the two most popular complaints of its passengers: provide reserved seating and inter-airline baggage transfer. Southwest decided that its major strategic advantage was inexpensive, reliable transportation, and this required a speedy turn-around time at each destination. Passengers complain, but they still prefer the airline.” This is an example of the airline balancing their service to maintain a market instead of just listening to their customers.

Example. Consider ground-source heating (GSH). GSH is generally recognized as a sustainable way to heat a home with low operating costs, but GSH is more expensive to install than other less sustainable technologies. Therefore, GSH is not very popular. The forces here are capital cost and pollution on the one hand, and operating cost and sustainability on the other. These forces balance at a point where relatively few people use GSH. As these forces change due to changes in technology, economics, environmental awareness, regulation, etc., the balance point will change, and more (or fewer) people will use GSH.

We also assume a systems thinking perspective:

  • A system is a set of interacting elements (which may be other systems) that provide defined functions and is crisply distinguished from its environment or context [KMR90].
  • Systems thinking is based on viewing a domain of interest as consisting entirely of systems.
  • Systems encapsulate function, and interact physically by exchanging mass, energy, and information.
  • System properties emerge from the interactions of subsystem elements with the system’s context (which includes other systems).
  • Changing the location of system boundaries can completely redefine the functionality and purpose of a system.
  • A system that interacts with its context well is one that balances properties of the context with properties available by the system itself.

TODO Add to the general notion of balance redundancy (Stafford Beer) & buffers as 2 other characteristics of natural systems that should be built into how we design.

TODO Absorb this cmap into these notes.

Terminology

TODO These terms need to be folded out into their own definition pages.

Designer
a generic term to denote all active participants in a design process; it is not meant to identify single individuals.
Model
any representation of a thing used to understand it from a specific perspective for a particular purpose. Models are by definition imperfect because they must ignore, abstract and structure what is present in the thing being modeled in order to be usable. Designers must therefore maintain awareness of the resultant limitations built into any models used.
Bounded rationality
We assume all agents exhibit bounded rationality, which, per Simon [8], denotes both imperfect knowledge and imperfect reasoning by agents.
Situation
Per Gero [3], a collection of active entities (agents, human or otherwise) that influence one another's behaviours in carrying out activities. In designing, we consider the designer, the design, all other agents and entities, as well as information present in the form of experiences, expertise, etc. to all be part of the situation. “Situation” is a term used to denote a real-world thing.
Context
a model of a situation, containing as much relevant information as necessary for a specific purpose. While some researchers describe designing as being “situated,” we prefer to distinguish between things as they are (a situation) and models of those situations. We can only work with models, because we cannot perceive the situations directly. Thus, we prefer to think of designing as contextual, to absorb the notion that those context models are not perfect, due to bounded rationality.
Framework
an implicit description of a family of processes, intended not to describe the actual processes, but intended to describe the goals that the family of processes can achieve if properly implemented.
Requirements
aka a design brief, is a model of a design problem. As such, requirements do not fully express a design problem, but rather express it as well as can be expected in a given situation, and given bounded rationality.

Problem solving vs designing

Many people consider design as a kind of problem solving. But the notion of describing everything as either a problem or a solution is itself problematic.

Differences between designing and problem solving are explained below. (From [SRE09])

Solutions end problems.

  • A problem sometimes vanishes upon solution.
    • But we cannot predict the nature of the new context because of bounded rationality.
  • The context resulting from implementation of an intervention is also imperfect, and is only one possible outcome of the designer's activity.
  • Therefore, we expect new problems to arise because of the solution.
    • It is not so much that the problem ends upon solution, but rather that it just changes.
    • We can consider, then, as a general constraint on designing in the problem-solving framework, that developing an intervention must minimize the detrimental impacts of future problems that arise from the intervention.
      • However, it is difficult, if not impossible, to know what those future problems are.

Problems are static once specified.

  • This is a common misconception, based on the common practice of “freezing” requirements, which model a design problem, before intensive designing starts.
    • If they were not frozen, then they may change faster than the designers can manage them.
    • Thus, in current practice and for practical reasons, requirements are typically frozen to give the designers a fixed target, as it were.
    • However, freezing the requirements does not freeze the problem on which they are based.
    • Indeed, a significant amount of project management in many large-scale design tasks (e.g. buildings, urban planning, commercial or military aircraft) arises directly from managing changes to requirements after they are supposed to be frozen, but that have become “stale” due to unforeseen external forces.
    • Furthermore, requirements are only imperfect models of design problems, which further increase the likelihood that there will be errors that must be corrected after the requirements are frozen.
  • If the requirements remain frozen, the designers risk developing a wrong solution for what the problem will have become.
  • This dilemma has been recognized, at least implicitly, by the drive toward shorter lead-times; the shorter the lead-time, the less likely the requirements are to have become stale. However, as the rate of technological, social, political, and economic change continues to increase, it will become ever harder to develop designs fast enough.
  • The fundamental matter here is not that design problems change, but that we treat them as if they were fixed.

Design problems are solved by choosing the “best” alternative solution.

  • The term “best” is a relative term, but is usually treated as an absolute.
    • That is, in problem-solving, there is a tacit assumption that it is possible to unequivocally identify the most appropriate solution.
    • In fact, “best” should be defined with respect to:
      • the design alternatives known to the agents (a function of bounded rationality);
      • the accuracy and completeness of the requirements (which should be allowed to change over time);
      • the accuracy and completeness of the expected future context when the design solution will be implemented;
      • and other factors.
    • However, problem-solving as it is commonly practiced ignores effects one might anticipate in the future, usually because they cannot be quantified to the same degree as the requirements (which are essentially historical in nature).
    • Without a willingness to consider the future effects of design solutions, and to build requirements that account for those effects to the best of our ability, the consequences of our design interventions cannot be controlled or mitigated at all.
    • Yet, the conventional problem-solving framework provides no mechanisms for this.

Problems are typically solved algorithmically or heuristically.

  • We often name as “problems” situations for which a solution can be worked out algorithmically or heuristically.
    • For instance, finding the roots of a binomial equation is a typical “problem” that is “solved” by students.
  • The prevalence of this view of problem-solving implies that design problem-solving is similar, but this is not true.
  • Designs emerge through human interaction, over time, and via reflection about the context.
  • Preliminary design implementations and prototypes are very often used to elicit information from users that further clarify the specifics of why the “as-is” situation is undesirable.
  • This reinforces the idea of coevolution of problem and solution [PM97], where the act of solving a design problem illuminates the problem itself.
  • Salustri has argued elsewhere [SE07] that designing is an appropriate approach precisely where algorithmic and heuristic methods fail - i.e., with so-called wicked problems. In any case, design appears to be non-algorithmic and non-heuristic, which places it at odds with the conventional notion of problem-solving.

From problem-solving to balance

I prefer to think of design as seeking balance.

I come to the word balance based on Alexander's use of harmony [AIS77] to describe what a good pattern should achieve.

  • I choose “balance” over “harmony” largely because I think the former connotes a slightly more clinical, measurable sense than does the latter.

Balance implies a dynamicism; the forces (drivers) that lead to imbalance can change in time, so finding balance is something to be done over time also.

Superficially, a well-designed product – one with balance – is only balanced with respect to the context in which it was designed.

More deeply, a balanced product should at least try to attain a prolonged balance in its operating life.

  • This means adapting to environment, robustness (not susceptible to environmental variability), flexibility, failure tolerance, etc.
  • It also means accommodating and allowing theretofore unforeseen affordances.

This suggests a deeply balanced product is designed with the future in mind, and not just whatever market was identified in the short-term for it.

  • This is a nice connection to sustainability.
  • TRIZ can also be interpreted as a way of attaining balance.
    • The TRIZ-style contradictions are the drivers that cause imbalance.
    • The TRIZ-style principles restore balance.

The notion of problem also implies (for me) a certain subjectivity. Problems don't exist in nature – they only exist in our minds.

  • A situation is a problem because it conflicts with our intent/wish/desire.
  • This conflict is an imbalance.
  • Reattaining balance doesn't solve the problem, it eliminates the problem.

Rob W has suggested that balance is a metaphor for problem solving. I'm not sure. Indeed, I think it might even be the other way around, or rather that problem-solving is a model of balancing.

  • A problem is an imbalance that conflicts with the intent of an agent.
  • A problem is situated (look up Gero re this), whereas the imbalance is not (modulo the perception problem).

Klaus K in The Semantic Turn, presents challenges, opportunities and possibilities as drivers of design.

  • Problems are a type of challenge.
  • Should read this to see how these 3 are defined.
  • Naively, I see both challenges and opportunities being perceptions of imbalances.
  • Dunno what to say about possibilities till I read the book.

One can consider a “problem” as a mismatch between one's goals & desires, and “how things are.” A problem is a model of that mismatch. Situated mismatches (i.e. situations containing perceived mismatches between goals/desires and “how things are”) are a more designerly way of thinking about things (as opposed to artistic or scientific thinking).

Balance via counter-intuition: This idea was contributed to the DPP paper by Nathan Eng. Any pursuit of this idea must attribute it to him.

  • The notion of counter to something means finding the opposing force and using it.
  • EG 1: Sometimes it is critical to be ambiguous in a specification/communication so that the frozen thing is still in some ways changeable (a paper by Claudia Eckert on this; Nathan may have other references).
  • EG 2: Sometimes you have to slow down to let other parts of the system in balance to catch up. There are examples in process modelling (I think) where letting one sub-process take longer results in a more stable (lower mean time) overall process. On the human factors side, it is important to slow people down at the right time to make them think carefully about what they are communicating, etc.
  • EG 3: In an age of massive and growing information systems, it is critical to integrate functions for “forgetting”. Remembering is an act of forgetting. This relates to how much work you try to reuse between systems vs. reinventing quickly.

Diagramming balance

Fig. 1: Environmental forces create a balance point of some system. New designs generate different forces, which move the balance point to a preferred location.

Consider the figure to the right.

The white nodes represent contextual/environmental factors. The blue node represents a design solution. The links (arrows) represent the forces exerted by the environment on the situation; the length of the link represents the “strength” of that force.

The faded links and blue node represent the original situation. The imbalance between the red and green environmental factors is noted as not-preferred. A new design intervention interacts with environmental forces and results in a new configuration of forces, as represented by the brighter links and blue node. We calculated that in this configuration, the red and green forces are preferred to their original versions. The new situation is more balanced than the original.

We note that the angles of the links and the positions of the environmental factors are irrelevant.

NOTE: there are also links between the white nodes, to model the coupling between environmental factors, but they have been excluded here simply for clarity. Such links allow changes to one force to propagate throughout the system.

So, when a new design is implemented, at least one link changes length. To maintain balance, other links must also change length. These other changes in length represent changes in the rest of the situation.

Assuming appropriate relationships are specified to quantify the forces represented by the links, we can quantify the degree of balance in a design. Such a calculation will probably result in only a dimensionless measure, which is relatively meaningless on its own. However, it

  • will allow us to compare different designs and determine which is more balanced, and
  • can guide designers in identifying which forces are most relevant to design for.

Of particular interest is that this approach can be computerized with force-directed graph modeling software.

Similarities to control theory

stdcontroldiagramwitheg.jpg Fig. 2: The standard control system block diagram, with an example.

Designing as balancing can be analogized to well-known control theory. Consider riding a bicycle: to remain upright, the rider must continually make adjustments to offset forces that try to change his balance point to an undesirable place (i.e., he falls). Every adjustment is like a new design intervention, designed to offset the difference between what is desired and what actually exists. The adjustment/intervention alters the situation, which in turn alters the forces, which in turn requires a further adjustment/intervention. This is the essence of control theory.

To the right we see a conventional control block diagram. Below it is a colour-coded example of the diagram applied to controlling the heat in one's home with a furnace and thermostat. Certain external forces seek to move the home's heat level away from the desired point. The thermostat measures that “error,” and uses a comparator to decide if the furnace should be turned on. Once on, the furnace moves the system back toward the desired state.

Fig. 3: The control diagram with the designer as the control element.

The question is how to use this analogy to model designing as balancing. There are (currently) two different interpretations of the analogy.

In the first analogy, shown to the right, the designer assumes the role of the control element in the block diagram. This figure is topologically equivalent to the standard block diagram; it has been altered only to highlight the nature of the system it describes.

The pink box is new. It represents the collection of models that the designer works with. In other words, only the designer, the product, and the “real world” are actual; everything else exists only in the designer's mind.

Fig. 4: The control diagram with the designer as the comparator.

In the second analogy, shown to the right, the designer assumes the role of the comparator in the block diagram. This figure too is topologically equivalent to the standard block diagram. In this case, the control elements are the “real world” phenomena that will cause the balance point of a situation to change.

The role of the designer is to determine the degree to which the current situation needs to change (the comparator). In this case, the combination of that measurement of change, plus the current situation results in a design intervention intended to bring about that change. We note here that at a systems level, the intervention itself is a black box from the point of view of the situation, so all design interventions that can effect the necessary change appear (functionally) identical.

Influences of DaB

To more fully consider what DaB might mean in practise, the authors consider in this section some of the implications of DaB with respect to some aspects of design activities.

Context and requirements

Ideally, a fully implemented DaB system would result in nearly instantaneous (with respect to the time scale of the process) transmission of contextual changes to the design, and update of appropriate documentation, throughout the design process. This also opens the possibility of allowing clients and users to engage more fully in the design process – a-la participatory design – and interact more with the designers.

This would fundamentally change how requirements and design briefs are defined and managed. In the conventional problem-solving (PS) framework, requirements are typically given as expectations of and on the artifact. However, in DaB, requirements focus on context and include three parts:

  • the identified “forces” acting in the context,
  • measures of the perceived imbalances in the forces, and
  • a rationale of why the imbalance is undesirable, which implicitly gives guidance on possible avenues to improve the balance.

In other words, with respect to requirements, problem-solving focuses on defining expectations for the future, while DaB focuses on determining the inadequacies of the present.

If requirements were allowed to change throughout the design process, there would also be a significant impact on the legal status of those requirements. In many industries, requirements or design briefs carry certain contractual obligations: accepting a set of requirements may be (and usually is, in fields like engineering design) construed as a contract to “solve a problem.” A detailed study of the legal implications of DaB, with respect to requirements specifications, is beyond the scope of this paper, but it is certainly a significant issue to be treated before DaB can ever gain widespread acceptance.

Design parameters

The authors use the term design parameter to denote a named value that characterizes some aspect of a design. They describe a design that relates back, usually quite directly, to particular requirements.

In PS, design parameters are assumed to be fixed by the time the design is finalized, because they strictly characterize the design as an isolated entity. They are typically a single value possibly with a tolerance (a range of acceptable but sub-optimal values) such that any value outside the tolerance range is entirely unacceptable. Tolerances are typically used only in designs that will have to be directly manufactured (e.g. engineering and related high-technology fields).

In DaB, design parameters must more readily accommodate the possibility of changing requirements. This can be done quite easily by using intervals rather than single values. An overview of intervals is available in [HW90]. For our purposes, it suffices to think of an interval as a value-range, typically marked by its limits, that brackets all reasonable values without prejudice to one particular value or another. Intervals have arithmetic, algebraic, and calculus operations in direct analogy to the more conventional single-valued mathematics, and can be used in both quantitative and qualitative situations.

How DaB treats design parameters will alter how change management happens. In typical practise, change management can account for a large portion of design cost, because of its administrative overhead. There is vigorous ongoing research to look for ways to eliminate the need for changes, especially in the technical design disciplines. Unfortunately, this is, in the authors' opinion, exactly the wrong thing to do. Changes will happen; we believe trying to control or stop them is doomed to failure. A better course of action is to develop streamlined and highly flexible methods of managing change. For example, the open-source software community has developed a variety of lightweight change management processes, some of which could be applied to non-software situations. This is a separate research question that will be covered in a future publication.

Designing affordances into products is potentially different in DaB than in PS. In PS, affordances designed into products are meant to address the problem directly. In DaB, a given design is only part of an ongoing and evolving process that designers must include in their thinking. In DaB, then, one must consider how any affordances designed into a product will affect future situations. One might consider making more adaptable or flexible the affordances of products being designed currently. The benefits of doing so include product longevity, greater product use, and possibly broader or larger market; but there are also risks including product misuse, greater chance of product failure, and increased liability.

Designing affordances relates to the use of intervals for design parameters. Smaller intervals generally mean more limited and targeted affordances. Smaller intervals lead to products that are generally easier to build, but will be more specific in function, affordance, and, therefore, usefulness and scope. Intervals can therefore be used as a tool to help designers trade off all these issues.

Concept evaluation changes

Any decision-making method can be used to evaluate design concepts. Interval-based design parameters can be used in all decision-making methods. So, concept evaluation can very easily incorporate design parameters as described above. However, the result of a concept evaluation exercise using intervals will be an interval itself. This means that, firstly, more concepts might be identified as preferred (if concepts' intervals fall partly above a preference threshold) and, secondly, the intervals of design concepts being compared may overlap. This will require changes to the way we select the “best” concept in a given comparison, but it will also afford opportunities. For instance, overlaps between concept intervals suggest that those concepts can be grouped and that new concepts could be derived that maximizes interval coverage; such maximizations could indicate broader usefulness of products.

Similar changes can be expected in other methods of design analysis, comparison, and evaluation, such as design critiques. All this leads us to believe that opportunities for new design methods exist in a DaB framework, compared to PS frameworks.

Need for more careful analysis of possible futures

Underlying many of the possible changes resulting from the adoption of DaB is the notion of being more mindful of the future impact of designs. There are various tools (e.g. in engineering design, Failure Mode and Effects Analysis) that can be adapted to work in diverse design settings. These tools help designers predict what can go wrong with a product, so that those problems can be “designed out” of the product before it goes to market. To extend such methods beyond the technical design fields will require using methods of futurology and future studies, and include the construction of scenarios of what might happen once a product is introduced.

This relates to the description of future situations that include the artifact/product being designed. Given such descriptions of future situations, one can study the balance of those situations and then consider how to change the current design to accommodate perceived shortcomings in those future situations.

Prototype/test activities change

Since DaB focusses on addressing the imbalance of a situation – which is a direct result of forces external to the control of the designer – prototyping and testing of early concepts with the involvement of users or clients becomes even more important. Each external participant in such activities will bring a particular and possibly novel point of view to the activity, any of which may reveal inadequacies in the design.

Prototyping and testing is also important to evaluate performance. Given the potential for increased adaptability of designs developed under DaB frameworks, this is an important issue. Increased adaptability usually means increased efficacy, but increased efficacy also usually means decreased efficiency. A suitable balance between efficacy and efficiency is very important for a successful design, and prototyping and testing is a fundamental way to gather the necessary information for such assessments.

See Also

References

Ale64. a C. Alexander. 1964. Notes on the synthesis of form. Havard University Press.
FKL09. a D. Forgues, L. Koskela, and A. Lejeune. 2009. Information technology as boundary object for transformational learning. J Information Tech in Construction, 14:48-58. (link)
KMR90. a Dean C. Karnopp, Donald L. Margolis and Ronald C. Rosenberg. 1990. System Dynamics: A Unified Approach. Wiley and Sons, New York.
SRE09. a F.A. Salustri, D. Rogers and N.L. Eng 2009. Designing as Balance-Seeking Instead of Problem-Solving. Design Principles and Practices, 3(3):343-356. (link)
PM97. a J. Poon M.L. Maher. 1997. Co-evolution and emergence in design. Artificial Intelligence in Engineering 11:319-327.
SE07. a F.A. Salustri and N.L. Eng 2007. Design as…: thinking of what design might be. J Design Principles and Practices, 1:1(19-28). (link)
AIS77. a C. Alexander, S. Ishikawa and M. Silverstein. 1977. A Pattern Language: Towns, Buildings, Construction. Oxford University Press, London.
HW90. a Walid Habib and Allen C. Ward. 1990. Proving the Labeled Interval Calculus for Inferences on Catalogs. In Design Theory and Methodology (ed. James R. Rinderle and David G. Ullman); ASME, New York. pages 63-68.
research/achieving_balance.txt · Last modified: 2020.03.12 13:30 (external edit)