XXX_DECISION

The main reason for developing the flowcards was to teach programming. There was a need for a simple-to-understand method, which would be ‘obvious’ to use. The method needed to be scalable in the abstraction level, and still be able to generate an output suitable for programming. The cards have been used and developed over several years, and have been successful in giving students more control over their prototype behaviour.

This already excluded several options, including rigid visual programming language IDEs, such as Scratch by MIT (which is good in other aspects). As the intent was to create a learning tool, it should also enable groupwork, as well as being agile to implement, but just cumbersome enough that users would rather think a little rather than just mindlessly type.

Somehow the idea of having a flowchart symbol on a card was had, as it was a graphical method and relatively understandable to begin with. Soon it became clear that the cards could also be used for communicating interaction descriptions between designers and engineers, and for that end, it has been very good at bridging the engineering and design fields.

They are especially useful for interaction designers, as flowcharts provide well-understood structures and use clear visual symbols. Using a subset of two symbols, a tool called ‘Flowcards’ [1] was created. Each card has a symbol that can be written in, describing an action or a situation. The point is to help discuss behaviour, discuss ideas or understand programming constraints. Instead of using a programming environment or a computerised system, cards were developed to foster thinking and help a team to work together. In addition to the symbol, each card has an arrow or two arrows, which in combination with the text suggest the next card. By placing them one after another utilising simple restrictions suggested by the arrows, a flowchart can be created, and easily played around with.

xxx_branchingcolumns

Each card has a fixed size, 10cm x 6cm, and is made from laminated white plastic magnets. The intended use situation is a classroom or meeting-room setting, with whiteboards as the background. The cards contain a symbol of either a diamond or a box. The connections between the cards are drawn freely by hand, as necessary.

The box symbol indicates a specific action, and is called a process. Initially, it can contain any kind of description of an action, but during the iterations of use, the intention is to make it as explicit and simple as possible. As it is intended for design and communication, the content can be as simple as “turn off the light”. On the other hand, there is no defined level of detail for the content, and therefore it can be as vague as “adjust air-quality according to user’s nervousness”. The process can describe anything from a single instruction to a complex functionality: only the available space and understandability dictate what can be written. Typically at the beginning of a design process, a process box would start with vague descriptions and optimally end with specific commands. Writing a single assembler instruction to the box can be considered to be at the most fundamental level.

The diamond symbol is used to describe a decision or a branch, and has two arrows for the following actions. For a positive outcome, the arrow below the symbol is used. For a negative outcome, the arrow on the right is used. These are the only outcomes that are possible on a branch. The condition or question is written inside the diamond. The most basic use is an if-else decision, but it can be used with only one answer, with the negative answer bypassing the symbol below. The abstraction level of the text can vary, similarly to the process. While it is preferable to use simple questions, such as if something is on or off, it is also perfectly valid to start with very vague and abstract questions, such as “Is the user nervous?” Sometimes abstract questions are the only means of starting, since there might not yet be an understanding of how the measurement or decision could be measured or calculated.

 

[1] Mikkonen Jussi, “Flowcards – a communication tool”, Design Research Society Conference 2012, Bangkok, Chulalongkorn University, Bangkok, Thailand, 1-4 July 2012

Flowcards