I worked in collaboration with fellow Computational Design master's student Atefeh Mahdavi Goloujeh in the planning and execution of this design workshop toward our respective thesis research.
We began the workshop with a physical activity, both an icebreaker and a means to encourage different ways of thinking about intersections. We laid four cardboard ‘teardrop’ shapes, about 2 feet in diameter, on the floor, to suggest a cloverleaf interchange with the negative space.
Then, in a physical simulation with human bodies representing vehicular traffic, we asked the participants to begin walking through and around the intersection. The rules for agents in this simulation were that they should strive for continuous (not necessarily fast) motion and that they could not communicate with each other with speech.
We asked the participants to spend five minutes listing on Post-It notes as many real-world factors influencing the activity of traffic intersections.
Then, the participants brought their factors to a large whiteboard to group similar factors into an affinity diagram, meant to draw out patterns of thinking. This led to a discussion about the different types of factors they had come up with, noting the common themes that had arisen, and their perspectives on these factors. We asked the participants to identify five factors that they wished to focus on for the coming activities.
The factors that the participants chose to simulate were:
In Loopy, a designer-user represents the interaction between system factors; for example, in an ecological simulation, one might include ‘predators’ and ‘prey.’ Two arrows would be drawn: A positive relationship from prey to predators (more prey leads to more predators), and a negative relationship from predators to prey (more predators leads to less prey).
For the intersection simulation, we encouraged the participants to think of their factors not necessarily in strictly quantitative terms, but also qualitative — a positive relationship might mean that factor A leads to ‘better’ or ‘stronger’ factor B (as opposed to more of it).
The participants began by drawing circles for each of these factors, and then drawing arrows to model the relationships between the factors. They hypothesized that smartphones have a negative relationship to negotiation between drivers and pedestrians — more smartphones results in less communication. After setting up the relationships between factors, the participants ran a simulation by making a change to the system: Increasing the number of smartphones in use. They then observed the resulting changes to the system. They found some of the results unrealistic, and changed some of the relationships in order to run the simulation again and observe these changes in action.
Eventually, they added a sixth factor, ‘safety,’ to serve as a yardstick by which to measure their simulations. After iterating on the simulation a few more times, they moved on to the final activity, proposing potential design interventions that could shift their modeled system in desirable directions.
Finally, the participants used the whiteboards to propose some design interventions based on their system simulation. They first rewrote their initial factors on the board, and one of the participants drew a storyboard for an embedded sign meant to address smartphone users. They also sketched an intersection with smartphone-linked signage. The last design intervention was a system of signs aimed at cars approaching intersections that would state the number of pedestrians at the coming intersection.
From observing the participants using Loopy to model factors of urban intersections in a system, we draw three overall conclusions. First, Loopy is an effective tool to simulate the unexpected consequences of changes in a system (that is, to simulate emergent behavior). Second, Loopy is most useful when viewed as a dialogue between the software and a designer or, preferably, a group of designers. Finally, Loopy helps designers to clarify and make explicit certain assumptions they hold, but it also hides other biases.
Throughout the activity, the phenomenon (and observation) of emergent behavior played a significant role in the participants’ usage of the tool. Loopy requires the designer to make some change to the system in order to begin a simulation run. On the first iteration, the participants increased ‘smartphones,’ leading to an undesirable scenario of little signage and accessibility. All the participants noted how a small change in one area of the system could have ripple effects that defied their expectations qualitatively and quantitatively.
Rather than using Loopy as a tool for optimization, the participants were engaging in a generative dialogue with the software. Throughout the duration of the simulation activity, they designed at least eight iterations on their initial system. Observing unexpected behavior led the participants to trace certain effects, analyze their model, and make adjustments. Loopy allows designers to peer into causal relationships within their simulation, and encourages self-conscious iteration on their work.
Through discussion of how to model factors and relationships, designers working collaboratively must articulate certain assumptions they hold. However, Loopy also appears to reinforce other biases, and hides the effects of any un-modeled factors or relationships. In this workshop, the participants’ beliefs about how and why intersections function provided justification for their system model, and they had to communicate these to each other. Later in the activity, however, the simulation appeared to take on more and more agency, and conversation around the faithfulness of their model to reality took a backseat to creating desirable scenarios. In later iterations, working at a faster pace, the participants forgot what exactly they had changed from one iteration to the next and for what reasons. A particular challenge for designers working with Loopy or other simulation software is to remain engaged but skeptical throughout the process.