"You were supposed to draw him standing up" - testing preconceptions in design

Last weekend whilst I was supposedly looking after my two eldest children and actually sneakily checking my email my attention was drawn by a tweet linking to a testing challenge on the Testing Planet website.

The focus of the challenge was a great website called draw a stickman. The site is a great fun interactive site that invites the visitor to draw a stickman and then proceeds to engage this man in a series of activities requiring further graphical contribution from the visitor to complete the story.

The title of the challenge, "Play with this, I mean test it casually", indicated to me that the focus of the challenge should be around the user interactions with the application rather than any deep exploration of the html content or structure. Some comments had already been posted around what happens if you draw just a line or a blob. While all valid issues, most of them were based around interacting outside of the instructions of the application. While it is true that many bugs can arise when users operate in contravention of the documentation and instructions, in my experience these can often be resolved through referring the user to the instruction that has been missed and possibly amending the details to make them clearer.

Scope for intepretation

Instead I tried to focus on working within the instructions presented but looking for scope to intepret these in a way that the designer never intended. It was pretty easy finding some excellent ambiguity just by focussing on the first instruction (and the name of the site) "Draw a Stick Man". To most people, including me, my first idea if someone asks me to draw a stick man is something like this:-

However there is a huge amount of scope in the instruction here. My first attempt at pushing the scope was pure deviousness. I drew a similar stick man as the one above, but just upside-down. He duly progressed to live out the remainder of the adventure moving around the screen by means of his head pulsating and sliding him along like a snail's foot. Great fun but probably not what we could call a bug.

Next I progressed from pure deviousness to a more serious deviation from the expected norm. I imagined a wheelchair-user visiting the site and duly drew my stick man sitting in a wheelchair. Again the result was quite fun, the wheel of the wheelchair operating much as the head in the upside-down experiment. The behaviour of the wheel, whilst understandable, might upset a more sensitive wheelchair user so this might constitute a bug that the software had not been designed with this in mind.

My next attempt took the lack of specfic detail around the position of the stick man a little further, I decided to draw him in a reclined position with his hands behind his head, a "lazy stick man".

The results of this were fantastic. Rather than moving down the screen to progress with the adventure, lazy stick man decided that opening boxes and fighting dragons wasn't for him and flolloped off the screen to the right, leaving a completely blank screen with no further instructions. It turns out that this was a lucky shot as in my next 10 attempts I only managed to get 1 man to take the same lazy path off down the pub.

Whilst hilarious fun this also consituted a definite bug in the system, as it was possible for someone who came to the site and followed the instructions in good faith, but deviated slightly from the expected inputs, could be left stranded with no idea what was supposed to happen next.

I find that issues when the instructions are open to interpretation but the application is limited to a single case based on the designers preconceptions can be hugely problematic. In this case it is not possible to refer the user to any documentation or instructions highlighting their mistake, as in their mind they were operating within the instructions and have made no mistake. If not addressed carefully there is even the scope for insulting the users of the system if you mistakenly take the stance of suggesting that their ideas and notions are incorrect (had the wheelchair image decided to exit stage right this could have been a more serious issue risking insulting a potential user).

Question Yourself

Next time you are testing inputs into a system, question yourself and your own preconceptions. Are your default test usernames all based on western length/structure names. Are you assuming that your users all have full ability to use keyboard, screen and mouse? I once worked on a system where a key user had a muscular disorder and could not use a mouse - it certainly opened my eyes to what keyboard accessible really meant. (Darren MacMillan recently wrote an excellent post on accessibility here). As well as cultural ideas, do your technological or organisational experiences lead you to interpret instructions in a way that may be hidden from or contorted by users with less experience of your context?

Are you testing the actual operating instructions or following your own notions on how these instructions should be implemented? If it is the latter then having your stick man run away could be the least of your worries.