Last week I posted a general overview of the conference I went to the week prior. In the first session after the Keynote I presented a workshop entitled “Visualising systems”; the details in this were kept brief to be put into their own post. Today I’ll be going into more details on the mnemonic and the thoughts behind it, the workshop, and some of their history.
This mnemonic isn’t intended for use in any specific type of visualisation; it should be generally applicable to any type of model or system that you are wanting to make a visual representation of. Nor is this specific to testing only, I just see these skills and thought patterns as useful in systems thinking, which I see as a key component of skilled and useful testing.
This mnemonic covers tries to help us think about the systems we are visualising in order to visualise them effectively. In the current iteration the mnemonic itself is NEPAl: (yes, the lower case “l” is intentional)
– Abstraction level
If after reading this you have thoughts on how the mnemonic might be improved for specific types of systems then I’d be keen to hear your thoughts.
Narrative is first on the list because this is what ties everything together. Stories have been the backbone of human memory and understanding for a long, long time. Stories can be seen as a journey of start, middle, and end…or they can be cyclical, branching, or any other number of structures. One useful heuristic to getting people to remember and understand your visualisation is if people can either understand the story of your system from what they’re seeing, or if they can easily remember your story by using your system as a reminder – stories do well for your visualisations as either reinforcers or reminders.
Narrative structure can be useful in defining how to shape your visualisation. Just as we can recognise the structures of other visualisations and models that we have found useful and apply them to things we make ourselves, stories have well recognised structures and we can apply those structures to our own models, and to the stories by which we remember and explain them. There are many different recognised narrative structures, some of which we can apply to our models of systems.
Some structures are linear; they start at one point, end at a different point, and things happen along the journey. In many types of structures (such as the Three Act structure and similar variants) there are specific points that create tension and problems; twists and confrontations. The resolution of these moves the people and plot towards it’s climax. Many systems can be very simply visualised or explained as linear; what actions happen over time, how money or information flows from place to place etc.
Some other structures, while still being linear, may end at or close to the start. I’ll highlight a few kinds of these quickly:
– Circular narratives, which have the start and end be the same point, although in a different state. An example might be a process map of a complaints ticket queue, which might start with a complaint being made, and end with that same complaint being resolved. Some very specific kinds of these stories exist, like the Hero’s Journey/Monomyth, which frequently end with protagonist returning to where he started from to contrast how things have changed.
– Feedback narratives, where the end of the “linear” narrative impacts the start of the next iteration. Many forms of iterative software development can, and frequently are, modelled this way.
– Ring narratives, where points from one “side” of the story reflect the other “side” in some way. A good example of this in software development is the V model; each point on the left of the model has a matching part on the right of the model. While usually not treated as literally in story-telling, it can also be compared to Newton’s Third Law – things that happen before the fulcrum of a story have some kind of thematic match on the other side of it that is due to it, or resolved by it.
Some other stories just don’t fit these kinds of models. We’ll call them “non-linear” for simplicity. Maybe it’s a gigantic flowchart that could go in any number of directions, loop any number of times, or otherwise isn’t simplistic enough to categorise like this. That’s fine. It might, however, tell us that we don’t have an easy way of explaining our story though, and lack of explainability is one thing that might be a way of recognising a problem.
I originally had this item in the mnemonic named “Tell a story”. Telling a story is the crux here – a story is what ties it all together. Understanding how the story of your system relates to the visualisation will inform on how to think about your visualisation. So, here are some useful things to think about in defining your narrative:
– What story is your visualisation trying to tell? Does it have a clear purpose or theme, or is it trying to be general use? What does this mean for the people who have to use or remember it?
– Are you passing down your narrative explicitly through writing, or some kind of legend, or is it implicitly a part of the visualisation? How might it change, be lost or forgotten over time; will it exist to prompt a memory of things you already know, or will you have some kind of legend to help describe what the various narrative structures and plots are?
– Where does the story of this system start and end? Can it have multiple starts and ends? How do the things that happen in one part of the system impact the other parts?
– Are there any loose ends that should be explicitly tied up? How are each of the twists and confrontations that happen during the narrative best represented and resolved?
Given the importance of Narrative to this mnemonic, the workshop I run to explain it uses shared storytelling; groups of people create visualisations of systems and stories that explain them, and tell these stories to the other groups in the workshop. As an interactive workshop, these groups are giving relatable examples that can highlight many of the techniques that can communicate information using visualisation.
Elements refers to two things which are interlinked: smaller, broken down pieces of the content of your story, and the way you might represent them visually. For instance, if we’re trying to visually model a flow of information, you might have some way of representing each state the information can be in, each place the information can be stored, people or things that access or modify the data, and so on.
By taking the story of your system, you can turn each character, place, item, or quality of those things into an element; take your monolithic story and turn it into simpler, smaller parts. I’ve seen this referred to in testing circles (especially as relates to Michael Bolton) as Factoring1,2; this seems linked to De Bono’s Fractorisation3, and the mathematical process of Factorisation4.
Looking at models that I’ve found useful shows us how they’ve taken a large idea and broken it down into smaller, more useful pieces (say, how the Heuristic Test Strategy or the Little Black Book on Test Design models the qualities of a system under test). Some models used before computer science might be the ways that people have classified animals – before modern science they were divided by prominent features and behaviours.
Aristotle (who was one of the first to spend a lot of time on taxonomy that we still have the writings of) also had another interesting way of modelling “causes” which I feel can be well applied to the elements of the system:
– the Material cause; what substance or material is the thing made from?
– the Formal cause; what shape or qualities does this thing have?
– the Efficient/moving cause; what triggers this thing? What causes it to change, start, or stop?
– the Final cause; what purpose does it have? Why is it in the system?
We can use these causes, or other models that you find useful, to help factor the system into individual elements for visualisation. What types of things is the system made from? What qualities do these things that the system is made from have? What purpose does it serve in the system? What comes before or after it? Should things that are similar to each other be represented in a similar way to make what they are, and how they fit into the story more explicit to the consumer of the visualsation?
As per it’s original name (“Identify elements”), in the workshop that I present this mnemonic in I have people start by taking sticky notes and writing down as many different things (elements) they can think of that might be represented in a system visualisation. I then ask them to form a basic system using all or some of the elements they have chosen, and explain this to the group using an arbitrary story of that system. It’s always interesting to see the different systems that people come up with, given the very basic guidelines to the instruction. Some people create a very generic model of a process or system, others take very specific scenarios that they have been in and model how it happened.
Perspective is all about the lens through which we are viewing the system. If the system that you’re visualising is an objective thing, the visualisation you make of a system is a subjective image of it. It’s a map of the territory, not the territory itself. Given that our map is going to be imperfect, we need to decide what the map will focus on, what it (or it’s users) care about. Just like how in a story there are different ways you can perceive the story (such as from the point of view of a specific character, from a 3rd person perspective etc), how your visualisation is structured will depend on what perspective you wish to view the system from, or what type of element is most important to you.
As described in the section on Narrative, many linear visualisations follow the flow of a single thing: time, money, information, actions, consequences etc. Each of these are great examples of different perspectives you can take on the same system. Which perspective you take will filter what kinds of elements you place, and how you represent them. This is a way to filter the visualisation, lower noise to increase signal.
Some useful questions for thinking about perspective might include:
– “What connects these elements together?”
– “What most differentiates the elements I want to represent?”
– “What information that could be here is better left unsaid or implicit, rather than made explicit?”
These questions will shape what elements you use and how they are represented; it will also shape the map on which they’re placed and what that represents.
For instance, an organisational hierarchy chart generally cares about the control of, and relationships between people; how you map the relationships between the people could represent different types of command and control structures, power dynamics and so on. Lines and dotted lines, the colour and shape of the polygon the position is in are all commonly used. Other options include the absolute position in space representing information about some kind of authority it had (be it financial or otherwise), or the size of the shape itself representing something. All of these things (location, relationship, size, shape, colour, content) are all elements that can be used in visualisation to great effect.
Other examples of using the map itself as part of the visualisation include graphs explicitly labelling their axis with things such as money or time, which forces all other things displayed to use that perspective; quadrant plots pick two axes that matter to the viewer and display the relation of parts of a system to those axes by their position in space; affinity maps have the elements on the visualisation and the whitespace between them represent what the affinity between the elements are – ideas placed closer to an idea share more with it, ideas further away share less.
I originally called this part of the mnemonic “Pivot your data”. I felt that “Perspective” was more approachable and didn’t need as much history for people who hadn’t spent too much time playing around with Excel. To give a concrete example of this step in the workshop, I ask people to take their existing system (which in the previous step they had put together from an arbitrary group of elements), and to think of a different perspective to view the system from.
Abstraction level is here to give us a more contextual perspective; that our system that we are visualising is both a part of a system, and has other systems within it – that every system is systems all the way down. We choose to hide the complexity below a certain level, or in certain black boxes, because it makes it easier to understand and more useful to us; similarly, the part of our system that we are visualising might be the hidden depths of another system to someone else, and we need to think about where our system connects to, includes, and is a part of that, or another system.
For example, and speaking as someone whose speciality is not in code, code itself is an abstraction. Many of the languages used today are High-level, people write in close-to-language words. We have tools that translate this into something much lower-level. It becomes machine code, and eventually we zoom out and it’s all electrons running around hitting…stuff that I know even less about. But the point is, that we can zoom out and out and out, with our system becoming a tiny speck somewhere, or we can zoom in and in and in and and realise that we’re staring at something that, moments ago, was probably a trivial detail that we wouldn’t have even thought about. But it’s all systems, and they all impact each other. Higher level systems are like the Final cause, the purpose of this system. Whatever we do here impacts something up there, and needs to fit into that. Lower level systems cause hitches from where we needed to smooth over the complexities to make it more understandable (or just because we didn’t understand it); lower levels trade simplicity for leaks.
Perhaps we can think of this as a corollary to Spolsky’s Law of Leaky Abstractions (which I’m sure someone else has already thought of) – “All non-trivial models, to some degree, will be abstracted”. The things that we need to think about when modelling and visualising our systems is which things are safe to be, and need to be, abstracted. Just like how Perspective allows us to filter out elements that just create noise, Abstraction level can help us make informed decisions on how far down the rabbit hole we need to go when mapping our system.
On a testing side-note, I consider one of the important things that testing does is expose these leaks; in many of the projects I’ve worked on, the leaky abstractions that we use in development create many of the defects that matter. Learning to move up and down abstraction levels and how to gather information that keys us into when one of these connections between systems might be leaky is a very useful skill.
Many times we oversimplify things out of habit. It’s important to make a conscious choice about the right level of abstraction to use. Some of the questions that you can ask that help you identify where you are abstracting something without realising, or what level of abstraction might be useful in a given situation include:
– “What comprises this element? If I had to factor it, what might that look like?”
– “What possible Final causes can I think of for this system? What might this mean about the content of the system that I should keep in mind?”
– “How important is it for the perspective I am taking that I have this level of detail? How might a future user of my visualisation find this detail out if they needed to?”
– “Does this level of detail create more noise than signal? Do I have a more effective element to present the information with, or is it better to cut the information off at a certain level of abstraction?”
– “Are the levels of abstraction I’m thinking about abstracted in some way? If the levels blurred or were further divided, what might this look like, and could this be useful information?”
– “Is there any information from a sub/super-system that might better put this system in context? Is this knowledge best served explicit or implicit in the visualisation?”
Originally this part of the mnemonic was “Choose your abstraction level” (for those trying to follow, the original mnemonic was “PICT” – it wasn’t even in a semblance of order). In the workshop I ask for a new system to be visualised from the old one at a different abstraction level. Some of the results are interesting: some are zoomed in or pulled out, some are meta-systems, like a generic model from a previously specific one.
If you made it this far, thanks. Seriously, thank you. That’s all for now though – this ended up being more of a beast than I’d wanted, but it’s better published than an eternal draft. I’d be interested to hear your thoughts on the ideas I’ve presented, and if you want me to expand on any given area I’ll see what justice I can do it.
Still on my plate to write about is some larger-scale thoughts on Aaron Hodder‘s “All Kinds of Minds” talk from WeTest Weekend Workshops 2015, as mentioned in the last blog, let’s see where that goes.