In my last few jobs—non-profit health support organizations in Chicago, the Kansas City Public Library—I developed a reputation as the person who can break your brand new website in ways that you never anticipated.
As we built our award-winning Civil War on the Western Border website here at KCPL; as the non-profit I worked at for my last few years in Chicago went through two different content management systems and completely redid their website—we obviously spent a lot of time testing the new sites and services, making certain of the functionality, running the systems through their paces before launching them to the public.
In the process, I learned that I’m the guy who identifies the most bizarre ways that things break down and fall apart. I search for the most counter-intuitive paths I can take through a site and I see where they lead me.
For example:
A site I worked on a few years ago had custom map functionality built for it. Users could track trips, plan routes, etc., and locate relevant support services based on geographic proximity. Like most online maps, you could search it and put pins in specific locations.
Like all online maps, you could zoom the view in and out. I wanted to see how the pin icon scaled as users zoomed. So I put a pin in a random address at the block-level resolution and then I zoomed out as far as the map would let me: from block, to city, to county, to state, to region, to country, to continent, to hemisphere, to world…
And still it let me keep zooming out. Zoomed out past the point where the whole world was visible, the map began to tile—it eventually stopped letting me zoom out with the whole world displayed four times, side-by-side. (Google Maps does something similar when you zoom out.) My pin only appeared in the North American continent in the middle map tile—so I tried zooming back in on North America on the map to the right. My pin wasn’t there.
Clearly, this wasn’t a huge problem—no one was going to zoom all the way out like that, this sort of playing around wasn’t the intent of the map. But people like to play around—especially with technology—and knowing how it behaved in extremis, knowing it could be broken this way led the developer to revamp the map. To address this issue, they made significant improvements that helped the map function better overall and made it easier to use even on a local scale.
No one else on the team thought to do what I did with this map, but finding such a strange way to explore it helped the developers make it better.
People ask me how I find these broken edges and strange corners where things fall apart—how I think to do such bizarre things and take such strange paths through sites.
It’s all to do with storytelling.
When we plan and develop websites or services, we first identify the need we want to address. We make certain we understand who we’re going to serve with it—primary, secondary, tertiary users, power users, casual users, etc.—and we design the site or service to get these users what they need as efficiently and painlessly as possible.
We built for use case scenarios—we consider the motivations, habits, and expectations of the people for whom we’re building our site or service, and we do our best create something that fulfills these factors.
Use case scenarios are stories—narratives that we construct using characters, motivations, and behaviors that are exemplars from the community we’re addressing. Storytelling is one of the methods that UX designers use during usability tests.
When I come to a new website, the governing narrative is usually pretty obvious—I can see how the developers expect me to interact with and navigate through the site.
What I do when I test a new site or service is to change this narrative. I try to make it tell a different story. I swap in a main character who’s someone completely different than the user in the developer’s use case scenarios. I imagine a user whose needs—and, in consequence, whose behaviors and expectations—are radically different than what the developers anticipated.
I specifically don’t use the site as intended. I try to make it tell a different story and see what happens.
You could argue that this is an unrealistic test of a new site or service—the whole point is that it was built to serve an identified need for an identified group of people. Why do you need to see what happens when you try and make it do things for which it wasn’t designed?
Who cares if it fails to do something it wasn’t intended to do in the first place?
I believe that bringing the unanticipated, the random, the illogical and counter-intuitive into the picture is the best way to inspire new ideas that enlarge your original vision in useful ways and make your site or service even better.
I say—if twisting the story around, if playing with it and doing the unexpected is all it takes to break your site…
Then your story isn’t strong enough to begin with.
John the Librarian 