I was watching my four and a half year old daughter play Recipe Rhumba! on the Kids’ CBC web site with a banana in one hand and her other hand on the laptop’s trackpad. Now the game requires that you drag and drop recipe items (see the image below) which I figured she wouldn’t be able to do with just one hand. Yet as I watched, she proceeded to click an item once, which caused it to be picked up, then she dragged her finger to the tray, and as soon as she was over it, the item automatically dropped. Now I guess I just took for granted that dragging and dropping items required the mouse button to be kept pressed during the whole drag operation. But that was me taking things for granted. Considering kids and their likely inability to keep the mouse button pressed during the dragging operation would require a different design, which is what Kids’ CBC did.
So why am I telling you all this? Because without actually watching a kid interact with the game, I would have never considered something as crucial as the drag and drop interaction as it applied to children. I would have simply taken it for granted and delivered a flawed product. This is exactly the sort of thing I was talking about in my post on Experiential Perspective. Until you actually get into what you’re building and interact with it like a real user, you’re going to be missing key nuances and what you deliver will end up being sub-par.
★
Amen! You don’t even want to know how many times this has happened to me. I code something up, test it and it seems perfectly intuitive to me. Someone else tests it, and they report it is intuitive and works fine.
So we set up a beta and give it to couple of end users and then watch them be BAFFLED by our “intuitive” interface.
Or I’m amazed the way some people use the tools we take for granted. For example, whenever I need to make edits to an attachment I save it somewhere on the file system first. Then when I need to send it I go to my email client, create a new email, and attach the file.
I actually observed people to open the email from an attachment, edit it, then go to File->Send To and email the working copy, without it ever actually being saved on the file system. Of course this failed miserably when we got 3rd party documents which used VB macros that required the files to be saved somewhere on the fie system in a non-temp directory for some reason. Whoever wrote them never assumed people could use office documents this way. And so the app would blow up every time people opened it directly from the email without saving it somewhere first.
Also, I wonder why we ended up with the “Drag and Drop” action rather the more intuitive “Pick up and Drop” action you described above. It seems like it makes more sense. But then again, until I read this post I never even considered it.
Luke: You know it’s like Paul Bennett says in his 2005 GlobalTED talk, “Design is in the Details.” He says that often the best design solutions are the ones that are right in front of you and you’ve got to try hard just to see them. (He explains it better than I just did.)