The EchoUser Experience

Does not compute image

This morning, while recruiting participants for an upcoming startup usability study, I stumbled upon a mythical creature I didn’t think existed. After chasing it through the underbrush of the internet to no avail, I eventually gave up, disgusted and disheartened, for the creature was gone - potentially forever.

And the creature in question? That rare breed of human who doesn’t have access to a DSL connection.

I know, I know, breathe in deeply - I didn’t think they existed, either. But it turns out that this kind of person is out there, and we have to plan for them accordingly.  More and more I find that people respond to my online recruitment ads, often for a remote study that needs screensharing and the like, without having the necessary technological hardware to actually complete the study. Like that story where from the band of monkeys eventually one will write Shakespeare, sometimes potential participants make it into the pool when they really shouldn’t.

It would be easy to blame the participant - I mean, who doesn’t have DSL access these days in the U.S., anyway? As it turns out, quite a few people don’t, so in the end it really is our bad as user researchers, not the participants. We need to make sure we’re designing studies - and recruitment procedures - that aren’t exclusionary from a technological perspective, even when we’re building a product or service that requires (relatively) advanced technology.

Examples of non-traditional recruitment abound: Etan once stood in a BART station for hours to recruit BART riders, while Mick loitered in a Best Buy (with permission of course) hoping to snag potential wireless hub buyers. The main problem, however, is that these methods, while often very effective, are time consuming - and expensive.

So how to recruit in an internet-ready world, when we’re not all on the same technological page?  Any thoughts? Examples?

I’m currently working on a usability and design prototyping project for a San Francisco-based iPhone app company (that shall, for now, remain unnamed).  So far it’s been fascinating, and lots of fun figuring out new ways to test the app, record the sessions, and integrate rapid design prototypes from week to week.

One of the more interesting parts of the project revolves around a diary study activity: we’re basically following half a dozen app users over a month to see how their experience with the app evolves, for better or worse.  I’m currently sending out 2 mini surveys a week, and have a shared “whiteboard” google doc where they can jot down any thoughts they have on the fly.

Experience Blogging

The neatest trick to the diary study, in my opinion, is the inclusion of what I’m calling “experience” blogging: basically, I’ve encouraged the participants to send screenshots of interesting moments they encounter while using the app by using the iPhone’s built in screen capture function (”On/Off” and “Main menu” simultaneous click).  I set up a dedicated photoblog on Posterous.com, and the participants basically send along their screenshots - which are automatically populated on the Posterous site.  The end result is a very neat live stream of app moments, sort of like the “pulse” of the app.

It seems like the native screen capture functionality of the iPhone makes this particularly easy, though I don’t know if any other phones do the same.

Has anyone else tried anything like this before?

You always hear about people doing A/B testing “out in the wild” (as well as examples of how it can be misused) but it’s rare that it is ever noticeable (which is kind of the point).

So when my colleague Aaron and I were working next to each other and happened to visit Salesforce.com at the same time, we were surprised to see the following:

and this…

Notice the difference? Someone at Salesforce is testing out whether people will sign up for the free trial (top menu, red button).

Does anyone have any other examples of A/B testing you’ve come across out in the wild? Would love to see examples.

Much of our work results in our clients having to make changes to an existing product or service.  It’s kind of the point of usability and design: unless everyone loves your product, careful research and testing will be sure to raise a few things that could be changed. Whether it’s the color of an icon or the entire product concept, design leaves no stone unturned.

One of the common refrains we hear from clients is this:

“But how will users know what we’ve changed??!”

(implication: they will hate it…)

We have lots of answers to that question, but here’s an example of my favorite (and perhaps the simplest) answer:

The lesson, it would seem, is to just tell them.

A recent post by the folks at Nielsen from their AlertBox service titled “Fresh vs. Familiar: How Aggressively to Redesign” talks about how users tend to prefer incremental UI changes (i.e. familiarity) to something novel and unique.

The theory goes that a more aggressive redesign will force a user to relearn and re-familiarize herself with a new visual layout and navigation, thereby reducing the overall usability of the UI in question.  I think that in principle this makes sense - assuming we still live in the 1990s!

I can’t believe how traditional usability seems to design for the lowest common denominator user, assuming that any little change, anything that will make a user have to - god forbid - actually modify their behavior (gasp!) is a bad thing.  I call this the “1990s approach” to usability, because back in the 90s it made sense to design for novice users: the interwebs was barely hitting the road (and not yet the mainstream), and web designers the world over were just starting to figure out how to design websites and UIs that didn’t confuse people with conflicting colors, black backgrounds, and hideous layouts.

But we’re in the 21st century, people.

This means that for the first time in UI design’s short history we are able to create designs that delight while also serving a broader functional purpose, rather than worry too much about making something purely functional and usable. Sure, there’s a place for functional design that hits all the right usability buttons, but I get frustrated when I see the usability profession, my profession, getting pigeonholed as stodgy and uptight.

A friend of mine who used to work at Apple, someone who I thought understood that usability involves both function and (sometimes beautiful) form, drove it home for me: “Usability? That’s boring, there’s no creativity or design innovation in that. You guys just make sure things are usable.”

This isn’t because he doesn’t understand usability, and more serves to illustrate that usability overall has a slightly stale rap - one that I aim to change.

Who’s with me?

One of the biggest gripes among usability professionals is that their client/boss waits until the end of a product or service’s development life cycle to start worrying about user experience.  This is like slapping a nice paint job on a jalopy, or building an entire stack of Jenga before checking to see if the table has a wobbly leg - in the long run it’ll bite you in the rear and all come crashing down (literally).

This is all very well when applied to a tangible product, a visible service, but what happens when it’s applied to something a little more fuzzy, say, like team building?

A friend was recently describing his attempts at building his team within a larger organization.  His goal, he explained, was to build out his team so he could then more effectively tackle larger organizational problems beyond his unit.  By hiring product managers, designers, marketers and the like, he was desperately hoping to buy himself the space - organizational and mental/emotional - to think about how to engage in larger scale change management.

To me, this seems like a dangerous game.  Sure, building out your team might buy you more time as you delegate to others, but with delegation comes responsibility, which itself takes time.  Indeed, much more time than we all initially think.  Furthermore, a bigger team makes for a bigger target within the organization, so there is the potential that any gains will be lost in the bigger organizational chess game.

My advice? Start with the connective tissue, the core usability and user experience. Don’t build out a team when the core is rotten, and risk creating a silo whose walls will need to be broken down anyway.  Start with the human-t0-human interactions that define the basis of the organization, no matter what size it becomes.  And don’t stop until you feel it in your gut.  Think you have it down? Tear it all down and start again, and again, and again.  Conversely, don’t drag it out for months - set the ball rolling and maintain momentum into the future.

Call it office “culture”, a philosophy, or whatever; slap guidelines into a pamphlet if you like, or conduct executive seminars during lunchtime; whatever it is, make sure you deal with the baseline usability and connective tissue first, and that you’re not just putting lipstick on a pig.