Timelines, scenarios, Stories

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.



Ingrid Heringstad Marianne Sælensminde Caring for caregivers 2014 web2

 A complex timeline showing how the situation of caregivers (Heringstad and Sælensminde 2014)


Johansen Hverdagen til dagens eldre 1 HIOA 2016 s

 A map describing typical the everyday life of todays elderly people. (Johansen HIOA 2016) 


AHO ID prosj Timeline s


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.



implementation terese charlotte aarland web2

 A circular timeline indicates a repetitive process. Implementation map. ( Terese Charlotte Aarland, AHO 2009)


More to follow






Leverage Points

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).
11. The sizes of buffers and other stabilizing stocks, relative to their flows.
10. The structure of material stocks and flows (such as transport networks, population age structures).
9. The lengths of delays, relative to the rate of system change.
8. The strength of negative feedback loops, relative to the impacts they are trying to correct against.
7. The gain around driving positive feedback loops.
6. The structure of information flows (who does and does not have access to information).
5. The rules of the system (such as incentives, punishments, constraints).
4. The power to add, change, evolve, or self-organize system structure.
3. The goals of the system.
2. The mindset or paradigm out of which the system — its goals, structure, rules, delays, parameters — arises.
1. The power to transcend paradigms.



Here is a video also found on the same webpage. It explains the Systems Dynamics approach

Evaluation Tools

By Birger Sevaldson


IMG 0045 gallery

(AHO 2013) 

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:

1.  Systemic impact (leverage)
1.1 Radius of ripple effects
1.2 Short term
1.3 Long term
1.4 Platform effect (to what degree the intervention is creating conditions for further interventions)

2.  Thresholds
2.1 Economic
2.2 Technological
2.3 Cultural
2.4 Organisational


3. Synergies
3.1 Synergies between intervention and the existing system
3.2 Synergies between interventions
3.3 Orchestration effects (combined effects, high-level synergies)
3.4 Orchestration thresholds (how easy is it to orchestrate the implementation?)

4. Counter effects (unwanted and counter intuitive effects)
4.1 Short term
4.2 Long term
4.3 Counter effects between the intervention and existing system
4.4 Counter effects between interventions

5. Resilience
5.1 Resilience toward micro-fluctuations
5.2 Resilience toward macro-fluctuations
5.3 Resilience toward extreme scenarios
5.4 Black swans


The PUGH Matrix is a similar evaluation method. Read more about it here >>>>>



A slider type of graphics is useful for the evaluation.

IMG 0001

The evaluation can be contextualized on a map, here for evaluating relations. (AHO 2013)



Threshold Analysis

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)


Julie Grytten hials 2 2016

Another more detajled evaluation map   (Julie Grytten NTNU 2016)

 Julie Grytten et al hials 2016 2 s


There are many ways to apply the principal. (Julie Grytten NTNU 2016)


Salto connect systemic evaluation 1 1200


From the Salto Connect project, (2rd year bachelor project, Marie Frogner, Trym Abrahamsen, Oda Heier, Torgeir Hæreid, Julie Sandvoll 2017)


Additional evaluations

Pro et Contra analyses. (See "Drøft" by Førland)

  1. Make a list of the ‘pro’ arguments that support your idea.
  2. Make a list of the ‘con’ arguments to your project.
  3. Select the most important pros and cons and develop pro and con arguments for each of them.
  4. Repeat this to a level where you think you have some well-supported arguments.
    If these analyses result in heavy counterarguments to your project, you should tweak, redesign and reform your project to address the issue. If this is not possible and you still want to continue with the project, you need to honestly explain the issue to stakeholders.


Stig M Henriksen hials 2016

Pro et contra argumentation tree. (Stig M. Henriksen NTNU 2016)


Risk analyses:
Risk analyses: Select the most important threats from your worst-case scenarios or through group discussions or individual considerations SWOT analyses or similar. Create the normal risk diagram according to two axes one for probability and one for consequences.


 14 Risk management manuela linda et al small


Common Risk Evaluation Diagram with Y axis: Consequence and X-axia Probability (M. Aguirre, R. Mikalauskaite, L Blaasvær 2011)



RISK ANALYSIS Kwant Controls 1200

The normal risk analyses diagram can be addapted in many ways. Click image to see larger version. (Jan Kristian Strømsnes, AHO 2011)


Risk MArkus Gundersen 2016 1200

(Markus Gundersen NTNU 2016)


SaltoConnect riskanalyses 2017 1200

From the Salto Connect project, (2rd year bachelor project, Marie Frogner, Trym Abrahamsen, Oda Heier, Torgeir Hæreid, Julie Sandvoll 2017)

Worst-case scenarios:
Create two extreme scenarios that are at the edge of what is probable. Develop the scenario so that it shows how your system will survive or adapt to a new situation. For example, imagine that a ship’s bridge is burned out. A small emergency bridge at a different place on the ship allows for emergency operation. The system will survive, though in a reduced state.
This is about the resilience or the robustness of your intervention.
Black swans: A scenario of something really unexpected happening
to your design. You might already have developed this idea of the black swan in the development of the extreme scenario.



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.

Back-checking for synergies:
Check your idea and intervention regarding the ripple effects on the system. Try to find synergies. Are there new possibilities that are opened by your intervention or idea?

Back-checking to the GIGA-map:
Draw your idea or intervention back into the GIGA-map, and draw the relations to everything in the map that is influenced, changed or needed for your design to work.

Stig M Henriksen backchecking hials 2016 s

 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)

Layered Scenario Mapping




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 (

The technique is also discussed in a paper published by CoDesign (


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:

  • to get a framework that would help us understand the context and the individual parts of the situation we designed for, as well as how the parts relate to the whole and to other parts;
  • to facilitate the sharing of data collected, and insights gained among the team;
  • to present the situation we designed for at the level of granularity necessary to gain an in-depth level of understanding.

The map

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:

  • a visual presentation of the vessel’s position in relation to other objects, such as the port and the rig;
  • the mode of operation, indicating what kinds of rules apply, and what technical mode the vessel is in;
  • a short description of what happens;
  • the actors involved, and who communicates with whom and by what means;
  • a visual presentation of the users’ positions on the bridge, shown in a bird’s-eye view;
  • what equipment is used;
  • the information and functionality the users need to be able to carry out each task; and
  • illustrative photos to provide contextual information.

Our experiences

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.

Further developments

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. 

Library of Systemic Relations


A Library of Systemic Relations

Birger Sevaldson 2011

Relations fonts web


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


Birger Sevaldson


Revision: 27th May 2018

Earlier revisions:

December 2017

January 2016

December 2015: Changed the title from TYPES to LIBRARY of Systemic Relations, to emphasize that this is not meant to be a typology.

February 2015 

28th January 2013

24th January 2013

26th October 2012

16th August 2011



web map

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)

 See also

Network Theory >>>>>

Graph Theory >>>>>



More on hierarchies here: >>>>>


1.1.1 Structural relations (Functional relations)(SRFR)


Very often, systems are described as the assembly of parts where the sum is more than its parts. This is not a cause and effect relationship; rather, it is a structural relationship.

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)


These are relations that are caused by the entities being subsystems in the same "supra-system" but without necessarily being in direct contact with each other.

Example: Bikes and cars are related because they are sharing the same macro-system: the roads. (They are related in additional ways than this.)
Examples: A winter coat and bikini are both part of the clothing wardrobe of the same person.

1.1.3. Micro-systemic relations (SRMI)


These systems are related because they share a relation through a subsystem:

Example: The rubber in the tires of cars and bikes comes from the same producer.
Example: A Mixmaster and a hair dryer can share similar electronic parts from the same manufacturer.

1.1.4 Horizontal structural relations (SRHO)


These are relations between branches in a tree structure.

1.1.5. Vertical structural relations (SRVE)




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) 


Categorical relations are entities part of the same thematic field or category. Themes and categories are manmade sorting devices, and there is not necessarily a causal relation between the members of a category.

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.
Example: Genres of music. There are many possible relations between genres of music, but if we think of the relation between the music of Australian aborigines and a symphony by Bach, we can only think of a few relations, such as biological (music being programmed in our genes) and thematic relations (both being music).

1.2.3. Associative relations (SAAR)


Metaphors and analogies: These are the types of relations that pop up during brainstorming because of associating one thing with another.[.1] 

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.
Example: If I say bird, you say fish....

For semiotic definitions on associative relations, see Ferdinand Saussure

Sources here >>>>>> in Daniel Chandlers Semiotics for Beginners

1.2.3. Representational relations (SARR)


Images, representation, videos, simulations, VR and AR

Example: The relation between a map and landscape.
Example: The relation between a diagram and the reality it represents.
Example: The correlation between a VR environment for virtual prototyping and the reality it represents.

More here >>>>>>
And here 

1.3. SOCIAL RELATIONS (Yellows) (SO)


See also, Social Network Analyses >>>>>

Read about social relations here >>>>>>


1.3.1. Structural social relations (SOSR)


Example: Family, friends, etc.

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)


Example: Work, municipality, nation, culture, language, laws and regulations, money, contracts, etc.

1.3.3. Actions (SASR)



Social relations created through action

Example: Sharing political interests

Read more on social actions (based on Max Webers’ [.2] work), including seven different types of social actions >>>>>>



1.3.4. Emotional relations (SAER)




1.4.1 Causal relations (HRCR)


Cause and effect models: The nodes depict what entities cause an effect and what entities are being affected; the relations (normally arrows) depict the effect.

Example: If the heat is turned on, the kettle starts to boil.
Example: If the tolls for entering the city by car increase, the passengers using public transportation go up.

Read more about causality here: >>>>>>

1.4.2. Qualitative causal relation (HRQR)


The amount or intensity will not be influenced, but the quality will be changed.

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)


These are the concrete flows of values in society. They are driven by needs and economic forces.

Examples related to human society: Material flows, energy flows, information flows, knowledge, economic flows and stock markets
Examples: Traffic flow and crowds of people

1.4.5. Flows in natural systems (HRFN) 


These are driven by pressure differences (field conditions) or by nuclear processes. At one level, these might be understood as causal relations, but on a more detailed level, they need to be understood as differentiations in uniform fields, such as flows in water, which are caused by the impact of heat causing internal differentiation of pressure, but the shapes of the flows themselves are generated by internal chaotic principles that resist simple cause and effect analyses.

Examples related to natural phenomena: water, air, magma, cosmic particle flows, etc.

1.4.6. Variables, stocks and flows (HRSF)


This is the normal way of describing systems in systems dynamics. Variables are nodes that might change under the influence of other nodes. Flows are the flows of the content of the nodes from one node to the other or the influence from one node to the other. Stocks are the storing capacity of the nodes.

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.
Example: The number of predators and prey will influence each other. If the amount (stock) of rabbits is increasing, the amount of foxes will increase, which will lead to a decrease of rabbits, which will lead to a decrease of foxes, which will lead to an increase of rabbits and so on.
Example: The relation between the price of goods and the availability of them

1.4.7. Negative relations (HRNR)


If node A increases, node B decreases.

Example: The fox and rabbit example (tends to be a self-stabilising system)

1.4.8. Positive relations (HRPR) 


If node A increases, the node B increases, or if node A decreases, then node B decreases.

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.
Example: If the price goes up, the sales go down (-), then the price goes down (+) and the sales go up (-) and the price goes up (+). This is seemingly a self-stabilising system, but it's not a negative feedback loop because it's neutral (two -  and two +). The model is never quite like reality.


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?)
Example: The proximity between a neighbourhood and a park
Example: The proximity of the Bygdøy museums

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).
Example: A cafe serving lunch at lunch hours.

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
Example: The density and distribution of sunbathers in a park

2.4. Temporal distribution (TD)

2.4.1. The distribution of elements over time

Example: The distribution of intensities in a music composition
Example: The distribution of traffic density over the course of one day

2.4.2 Timing, rhythms and repetitions (TRR)

The same elements are appearing in a recognisable pattern.

Example: The repetitions in a music composition
Example: The rhythms of intensity in the density of traffic
Example: The rhythms and patterns of usage of the rooms in a house





More Articles ...

Page 1 of 2