I’ve been using mind maps on and off for many years now for a variety of usages. Sometimes just for ideas, sometimes for test ideas, sometimes for my learning.
Recently though I took a step back to observe the underlying purposes to see whether other audiences might gain value from the maps. I quickly realised that in some contexts mind maps actually make a very good communication medium. So here’s two ways I’ve recently used mindmaps for communicating to other team members. Both of these ways worked well in my context. They might work for you. Or they might not. I’m offering no guarantees.
Sharing of Test Ideas
During any planning meeting I usually whip open XMind on my laptop and get typing. As the conversations flow about requirements and stories I jot down ideas in xMind. The linking of “areas” or “streams” is done on the fly as I see obvious links emerging. It’s a brain dump of test ideas, thoughts, questions and data characteristics. After the meeting I’ll refactor the mind map and tighten up the “areas” or “streams”. This mind map will guide my testing. I won’t be bound by it, but it will lead me. In a sense it could be my “coverage” or “Test Plan”.
But I realised a while back that this mind map can serve another purpose too. It can serve a communication purpose. It’s perfect for the rest of the team. And so I’ve started sharing these mindmaps to give the programmers (and soon the project team) an idea of things I’m going to be looking for.
Some of the content in the mind maps are checks, some are tests and some are speculations or “edge” thoughts. Some will be vague or left open for future edit as the final architecture and design emerges. I will add many more ideas. I will remove others.
In this context I use them initially to drop ideas in to, secondly to communicate my test planning and thirdly to organise and help me manage my testing. They serve at least 3 functions, from just one document. But they aren’t always the answer for every context.
Mapping of usability reviews
One thing I am always keen on doing is getting out and about to meet the customers, but more importantly, to meet the end users (if you know who they are). The more end users I can meet, in their own situ, the better. I’d like to embed myself further in the teams and do some serious ethnographic research, but obviously time issues and deadlines often prevents this. Even so, one or two hours with an end user in suti using your product can offer a wealth of insights. I use mind mapping as a way to track how our users use our application.
Whilst I’m observing the end user I scribble notes. Lots of them. Which I then re-enter in to digital format using XMind. It’s important for me to do this as soon as I can after the observation whilst things are fresh in my mind. The reason for mind maps is that they offer a low tech and high visibily way to organise observations whilst also communicating to many audiences. The feedback gathered in the map can then be brought back to the office to be shared with the team.
Here’s the standard starting map I use to guide me, but again, not bind me when observing end users.
The feedback from both uses has so far has been great which has inspired me to keep using Mind Maps in these ways.
It’s another way to communicate and reduce long feedback loops. I also find mind maps easy to read (with a reasonably small amount of data) and are a good representation of thoughts and flow. They can be delved in to in detail or glanced at. They can be stored, printed, hacked around, mashed up with other mediums and can in themselves, contain other formats such as images and documents. For some of my contexts, they are the preferred mind dumping tool of choice. I know I’m not alone and in fact, I can thank Darren McMillan and Albert Gareev for getting me hooked on MindMaps again.