In a test team meeting the other week I was reminded of a technique/game I’d been able to label after reading the amazing book Gamestorming. The technique/game is called “Staple Yourself To It”.
In a nutshell it is about finding an object, message or aspect of your product and stapling yourself to it so that you can map out its journey through a system.
Image from – BY-YOUR-⌘’s “Vampire Stapler” May 12, 2009 via Flickr, Creative Commons Attribution.
For example, in a business you may decide to Staple Yourself to a customer raised Case and follow the case through a journey (or variety of journeys).
Once you have it mapped out (I’d recommend a visual map) then you can start to look for areas to optimise, question and improve.
The same is true for a product under test; you might find a message, or a user action, or a form submission and decide to follow this through the system to look for interesting things.
I use the phrase interesting things because you might not always be looking for areas to test.
- You might be looking for awkward interfaces for example between people and software.
- You might be looking for parts of the process that really slow the journey down, or move to quickly for the overall system, or leave you sat waiting; these are classic waste areas which might become the focus of your efforts.
- You might be looking for usability issues, accessibility problems, reliance on third party software/services or performance bottlenecks.
- You might be looking for security holes or exploits.
- Of course, you might be looking for areas to probe further with exploration.
As an example:
We build and deploy cloud based contact centres. One of the fundamental actions a contact centre must do is route a piece of communication to a person (agent) to be dealt with.
In this example let’s use a phone call.
A phone call must reach our cloud from the callers phone and be routed to the right person so that they can have their query/question dealt with.
Staple yourself to it:
- The caller makes a call via their phone (What sort of phone? Who are they? Why are they phoning?)
- The call travels through the phone network to our cloud (Which telephony carrier? Which account? What number? International or local?)
- The call is routed by our Call Centre product (Which account? Which Line? What configuration do they have? How is the call plan configured? Is there an agent available to take the call?)
- The call is delivered to an agent (Who are they and can they solve the problem? What browser are they using? What phone system are they using? What configurations are there on the UI?)
In a relatively simple journey I can already start to dive down and ask questions of the journey and the processes involved.
Imagine the journey for a call that moved from department to department or got transferred to another system, or went through an IVR system, or got hung up at various points.
Documenting the journey is a good way to see where you can focus your energy and where there could be areas to explore.
Stapling yourself to something and analysing the journey can lead you right to the heart of the problem, or at least give you giant sized clues to help guide you. Without knowing the journey you could be prodding around in the wrong place for days.
Stapling yourself to a journey wont guarantee you will find the sweet spot but it’s just another technique to use to drive out information and the visuals that can help you to identify areas to explore.
Note: Apologies if this idea has been blogged about before in the testing context. I haven’t read anything about it but I know many people are talking about tours and this is not too far away from that idea.