By Birger Sevaldson
Timelines are very useful for several reasons.
All systems are dynamic, and static network diagrams have one big drawback: they do not describe the dynamics of the system properly. Therefore, timelines are needed as a central part of GIGA-mapping.
Timelines are also very useful for short workshops where there will be unstructured conversations. They have been used extensively by Andreas Wettre, a leadership consultant who is a long-term collaborator in SOD. He uses this approach with the leaders of companies and organizations who are immersed in change processes. In such processes the misalignment of perceptions of their shared organization is often an problem that hinders good communication.
Timelines provide a natural sorting device that allows for conversations to jump in a very flexible way back and forth along the timeline. It makes it possible to have open-ended, unstructured and emergency meetings that still are focussed and that generate a better overall shared understanding.
Timelines are not only good for describing processes, but also for designing and projecting possible futures. They also can serve as a seamless bridge to building scenarios and narratives (storytelling). These stages are needed for systems-oriented design to develop new interventions and innovations and to imagine how they might work. This is also crucial for preparing the system for extreme scenarios to test the system’s resilience and to hopefully avoid counterintuitive and unwanted effects from the system change. I systems theory the counterintuitive systems behaviour is a well-known problem. As designers we need to avoid solving problems just to create new ones.
In the following, we will present some timelines and scenarios. There is a blurred distinction between timelines that are descriptive, timelines that are generative and future oriented and scenarios in general.
A complex timeline showing how the situation of caregivers (Heringstad and Sælensminde 2014)
A map describing typical the everyday life of todays elderly people. (Johansen HIOA 2016)
A project timeline derived form Gant diagram showing research projects at the institute of design AHO. The map is both descriptive looking back and prescriptive looking forward for planning purposes.
A circular timeline indicates a repetitive process. Implementation map. ( Terese Charlotte Aarland, AHO 2009)
More to follow
By Birger Sevaldson
Donella Meadows suggested the concept of Leverage Points (Norwegian: "Inflytelsespunkter").
Leverage points ar places in a system where one could influence the system in a particular efficient way. The ZIP analyses and the Impact and Threshold analyses does cover some but not all of this. It is recommended to do a leverage point investigation of systems.
Here is a nice visual introduction to leverage points:
And here a link to the original article of Donella Meadows
Donella Meadows Leverage Points:
12. Constants, parameters, numbers (such as subsidies, taxes, standards).
Here is a video also found on the same webpage. It explains the Systems Dynamics approach
By Birger Sevaldson
GIGA-maps are rich and dense information representations. To work with such semi-organised complexities and develop the ideas within and to work with the interventions or innovations derived from the ZIP analyses and the creative process, we must use a series of evaluation tools.
Impact and Threshold Analyses
These analyses were developed especially for SOD by the SOD team.
To help make decisions for the systems interventions, the value of I points, their implementation and effect, the below evaluation analyses is a good starting point. Evaluate and range all the I points according to the following criteria:
4. Counter effects (unwanted and counter intuitive effects)
A slider type of graphics is useful for the evaluation.
The evaluation can be contextualized on a map, here for evaluating relations. (AHO 2013)
Other types are based on scoring. (Stig M. Henriksen et. al. NTNU 2016)
Here a simpler score system but more factors are included. (Håvard Banne et. al. NYNU 2016)
Another more detajled evaluation map (Julie Grytten et.al. NTNU 2016)
There are many ways to apply the principal. (Julie Grytten et.al. NTNU 2016)
From the Salto Connect project, (2rd year bachelor project, Marie Frogner, Trym Abrahamsen, Oda Heier, Torgeir Hæreid, Julie Sandvoll 2017)
Pro et Contra analyses. (See "Drøft" by Førland)
Pro et contra argumentation tree. (Stig M. Henriksen NTNU 2016)
Common Risk Evaluation Diagram with Y axis: Consequence and X-axia Probability (M. Aguirre, R. Mikalauskaite, L Blaasvær 2011)
The normal risk analyses diagram can be addapted in many ways. Click image to see larger version. (Jan Kristian Strømsnes, AHO 2011)
(Markus Gundersen NTNU 2016)
From the Salto Connect project, (2rd year bachelor project, Marie Frogner, Trym Abrahamsen, Oda Heier, Torgeir Hæreid, Julie Sandvoll 2017)
The design process is not linear; it contains periods of incubation and moments of illumination (Hadarmad). Therefore, the mapping by itself does not always lead to ideas and innovations. Also, furthering the development of ideas into concepts and designs is a process that is not harnessed by the mapping; rather, it is one that most often plays out in conventional design work. It is ok to ‘forget’ the maps and the rich systemic information for times of creative development. To allow this to happen, we have use ‘back-checking’. This means that at the check points, the concept is back-checked with the system represented by the GIGA-maps. This allows for an uninterrupted creative flow.
The image shows backchecking of concepts to the gigamap to trace how the concept connects to the system. (Stig M. Henriksen et. al. NTNU 2016)
By Sigrun Lurås
Layered scenario mapping is a technique used to gain insight into the ‘situation one designs for’. It is a systemic technique and emphasises presenting information in different layers going from an overview to very detailed information. The technique proposes a structured approach to collecting and presenting data and provides a template for sorting and presenting the data in a layered manner hierarchically, spatially, and temporally.
A guide presenting the technique is available online ( http://brage.bibsys.no/xmlui/bitstream/handle/11250/294118/Guide%20layered%20scenario%20mapping_lur%C3%A5s.pdf?sequence=1&isAllowed=y)
The technique is also discussed in a paper published by CoDesign (http://dx.doi.org/10.1080/15710882.2015.1072221)
In a paper1 published in CoDesign I introduce Layered Scenario Mapping, a mapping technique we developed in the Ulstein Bridge Concept project to address issues we had with coping with vast amounts of data from field research. The technique was developed to meet the needs we faced when designing a ship’s bridge, however, it may also prove valuable when designing for other contexts where the spatial and/or temporal dimensions are of importance. A guide enabling others to use the technique is available online.
Representing outputs from field research
A range of techniques for representing field research exists in design, including scenarios2, task analyses3, contextmapping4, customer journey maps, work models5 and many more. We found, however, that none of the existing techniques catered for our needs of getting an overview and details at the same time. Some of the techniques provided the detail, but lacked the context (e.g. task analysis). Others provided contextual insights, but lacked the necessary level of detail (e.g. contextmapping). We developed Layered Scenario Mapping for three reasons:
Layered Scenario Mapping is a systemic design method aimed at helping designers understand the system they design for. The resulting map represents this system. Our map layout consists of overview information to the left and detailed information to the right.
The overview provides the reader with a frame of reference to use when deciphering the detailed information. In our map the overview includes a descriptive title, a visual presentation of the ship’s technical specifications, a description of the scene and introduction to the scenario, a presentation of the actors involved in the scenario, a written scenario story, and document information.
The detailed information is presented using a ‘timeline matrix’, with a step-by-step description of what goes on and key information related to each step. In our map the following is included:
We found that the map made it easier to make use of data from different sources. The way the data had been filtered, sorted, and put into a framework made the data more accessible and easier to share among the team. The description of what happens in the timeline matrix was the most-used part of the map, and the visual elements were particularly important in gaining a broader understanding of the scenario.
We used the map individually when developing design ideas and in collaborative sessions to discuss the appropriateness of ideas. The map invited comments, corrections, and clarifying questions, and thus facilitated mutual knowledge development. The map became a ‘boundary object’6 that we used internally within the project team, and also in communication with users and other stakeholders. For an in-depth discussion on our experiences with the map and a review of its appropriateness, see the CoDesign paper.
Layered Scenario Mapping can be developed further, in many directions. The content of the map could be elaborated upon and expanded. As an example, we mapped out the scenario from the deck officers perspective only and believe we could have gained broader insight if we had also mapped out the scenario from the perspectives of several actors. Also, due to limited time, we made a paper-based map only. A digitised version could ease sharing and exploring the digital material collected during field studies.
The guide describing the technique is not intended as a definitive recipe, but rather meant as a useful starting point for others who would like to do their own Layered Scenario Mapping. I encourage others to develop the technique further!
1 Lurås, Sigrun. 2015. “Layered Scenario Mapping: A Multidimensional Mapping Technique for Collaborative Design.” CoDesign. doi:10.1080/15710882.2015.1072221.
2 See for example: Carroll, John M, ed. 1995. Scenario-Based Design: Envisioning Work and Te.chnology in Systems Development. New York: Wiley. Buxton, Bill. 2007. Sketching User Experiences: Getting the Design Right and the Right Design. San Francisco, CA: Morgan Kaufmann. Bødker, Susanne. 2000. “Scenarios in User-centred Design – Setting the Stage for Reflection and Action.” Interacting with Computers 13 (1): 61–75.
3 Kirwan, Barry, and Les K Ainsworth. 1992. A Guide to Task Analysis. London: Taylor & Francis.
4 Sleeswijk Visser, Froukje, Pieter Jan Stappers, Remko van der Lugt, and Elizabeth B-N Sanders. 2005. “Contextmapping: Experiences from Practice.” CoDesign 1 (2): 119–149.
5 Beyer, Hugh, and Karen Holtzblatt. 1998. Contextual Design : Defining Customer-Centered Systems. San Fransisco, Calif: Morgan Kaufmann.
6 Star, Susan Leigh, and James R. Griesemer. 1989. “Institutional Ecology, ‘Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907–39.” Social Studies of Science 19 (3): 387–420.
A Library of Systemic Relations
Birger Sevaldson 2011
Diagram of different ways to graphically treating relations between two entities. Line fonts and weight are used to codyfy the relations. (Birger Sevaldson, 2013, first version 2001 in article here >>>>> )
In our work, we realised that we needed to focus more of our attention on the relations. A simple line or arrow or a plus or minus, such as what one would find in casual loop diagrams, is not sufficient. Therefore, I developed this list of possible types of relations. It is probably incomplete and needs development. Please, go to the Forum to comment on the list and add more relations.
The colours are suggestions for colour-coded arrows or lines in a diagram. In addition to these, it would be wise to use different fonts for lines and label relations with descriptions.
This is a document under construction.
This is meant as an educational document and an ongoing research document. It is not a scientific document. For it to be this, it would need substantial discussions and a literature review for each point, something which is planned for later. Therefore, many of the sources and links might currently be off target and secondary and should be treated with care.
The library suggests colour coding and tagging with abbreviations for marking the relations.
Presentation from RSD5
Revision: 27th May 2018
December 2015: Changed the title from TYPES to LIBRARY of Systemic Relations, to emphasize that this is not meant to be a typology.
28th January 2013
24th January 2013
26th October 2012
16th August 2011
An example of a relation-oriented map as opposed to an object-oriented map. The relations are described according to the library at that stage of development (Young et al. 2013). Click the map to see a larger version, and use ctrl + and - to zoom in and out.
1. RELATIONS IN SYSTEMS THAT ARE DEPICTED WITH NODES AND CONNECTORS (typically objects connected with lines or arrows)
Network Theory >>>>>
Graph Theory >>>>>
1.1 STRUCTURAL RELATIONS, HIERARCHICAL SUPRA- AND SUBSYSTEMS (GREENS) (SR)
More on hierarchies here: >>>>>
1.1.1 Structural relations (Functional relations)(SRFR)
Example: There is no causal relationship between the wheels and the frames of a bicycle in the sense that the frame becomes smaller if the wheels grow larger. They are assembled in a structure where what they generate together creates a surplus output. The whole is more than the sum of the parts.
Example: Think of the relation in the air traffic system between the planes and the control system. The number of planes does not automatically decrease if the control system is reduced. This only happens through institutional regulations.
More on structural relations here: >>>>>
1.1.2. Macro-systemic relations (SRMA)
Example: Bikes and cars are related because they are sharing the same macro-system: the roads. (They are related in additional ways than this.)
1.1.3. Micro-systemic relations (SRMI)
Example: The rubber in the tires of cars and bikes comes from the same producer.
1.1.4 Horizontal structural relations (SRHO)
1.1.5. Vertical structural relations (SRVE)
1.2 SEMANTIC (Semiotic), THEMATIC, ASSOCIATIVE AND REPRESENTATIONAL RELATIONS (BLUE) (SA)
1.2.1. Semantic relations (SASR)
Semantic relations are entities connected through a sentence where one word forms the relation.
Example: Fish — lives in — Water. Fish and water are the entities while lives in is the relation connector.
Cow — is a — mammal
See more here >>>>>
1.2.2. Categorical relations (SACR)
Note: Categorisation has its own problems, especially when it comes to borderline cases and items that fit into multiple categories. See also thematic relations because the term is used in linguistics.
Example: The relation between universal design and ergonomics.
1.2.3. Associative relations (SAAR)
EuroVoc definition: The associative relationship is a relationship between two concepts that do not belong to the same hierarchical structure although they have semantic or contextual similarities.
Example: If two people are very similar to each other in their apperances, there is an associative relation.
For semiotic definitions on associative relations, see Ferdinand Saussure
1.2.3. Representational relations (SARR)
Example: The relation between a map and landscape.
1.3. SOCIAL RELATIONS (Yellows) (SO)
See also, Social Network Analyses >>>>>
Read about social relations here >>>>>>
1.3.1. Structural social relations (SOSR)
Note: There are always multiple relations between, for example, the members of a family; some are given while others are optional. The structural (biological) relation between family members is given (constant) while the social relation is optional or conditioned. One can choose to have a social relation with a relative. But it is not possible to have a social relation with your ancient foremothers.
1.3.2. Institutional social relations (SOIR)
1.3.3. Actions (SASR)
Example: Sharing political interests
1.3.4. Emotional relations (SAER)
1.4. HARD RELATIONS, CAUSAL RELATIONS, FLOWS, ETC. (REDS) (HR)
1.4.1 Causal relations (HRCR)
Example: If the heat is turned on, the kettle starts to boil.
Read more about causality here: >>>>>>
1.4.2. Qualitative causal relation (HRQR)
Example: The relation between architectural space and the micro-climate.
1.4.3. Relational Tools (HRRT)
Tools are typically modifying and influencing the relations, not the entities directly.
Example: AR used to increase a cultural understanding of biological systems.
1.4.4. Flows in human systems (HRFH)
Examples related to human society: Material flows, energy flows, information flows, knowledge, economic flows and stock markets
1.4.5. Flows in natural systems (HRFN)
Examples related to natural phenomena: water, air, magma, cosmic particle flows, etc.
1.4.6. Variables, stocks and flows (HRSF)
Example: A classic example is a bath tub: if the inflow of water is more than the flow out of the drain, the bathtub will fill up too fast and flood. If the flow out of the tub is larger, the tub will eventually be empty.
1.4.7. Negative relations (HRNR)
Example: The fox and rabbit example (tends to be a self-stabilising system)
1.4.8. Positive relations (HRPR)
Example: The a company showing increased profits on the stock market leads to an increase in the number of traders.
1.4.9. Feedback loops (HRFloop)
The effect of a chain of causal relations between variables that returns to the ‘starting node’.
Positive feedback loop (HR+Floop)
The sum of the relations is positive, so the system is unbalanced.
Example: (I find these very hard to get right because it is difficult to interpret, and it all depends on the variables one makes up.) Hostile negotiations accelerating into war
Negative feedback loop (HR-Floop)
The sum of the relations is negative, and the system is balanced.
Example: The fox and rabbit populations regulate each other.
2. SYSTEMIC RELATIONS THAT RESIST THE MODEL OF NODES AND CONNECTORS
Not all systemic relations can be abstracted to nodes with connections. They must be diagrammed with spatial maps, intensity maps or along timelines.
In many cases, we should challenge the predominant systems model of entities and relations. In many cases, it is more useful to use a model of continuum. When mapping out the myriad of relations, they will generate a weaving that is so dense that it generates a sense of a field more than an overview of a large amount of relations.
Examples are schools of fish or flocks of starlings, the phenomena called hive minds, collective intelligence or continuums as in oceans and weather systems.
2.1. Spatial proximity (SP)
Elements sharing the same space within an operational proximity for the agent (e.g., the user)
Examples: The relation between a chair and table. Of course, there is also a thematic relationship because they both are furniture and also may have a historic relationship because both could belong to the same style. There is also a functional and structural relationship. (Who said this is simple?)
Different use of proximity-based relations here >>>>>
2.2. Temporal proximity (TP)
Elements share a temporal proximity in relation to an agent (e.g., the user).
Example: Traffic regulation systems that are timed according to rush hours, which of course are caused by the working hours, which again are influenced by the planetary system (day length).
2.3. Spatial distribution (SD)
Intensity fields, variations and differentiation of the distribution of similar elements in space
Example: Temperature across a room with a stove in one corner
2.4. Temporal distribution (TD)
2.4.1. The distribution of elements over time
Example: The distribution of intensities in a music composition
2.4.2 Timing, rhythms and repetitions (TRR)
The same elements are appearing in a recognisable pattern.
Example: The repetitions in a music composition