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?

Fatal error message in a terminal window

While I understand that command line interface programmers don’t feel like they need to adhere to the same rules as UI designers, I think it would be best if they reconsidered.

Under no circumstances is it necessary for an error message to tell me something was “fatal”. It evokes feelings of panic and makes me feel as though I’ve done something irreversible. In the example above I simply called “git pull” (grab the latest code from the repository) on the wrong folder.  Because that folder wasn’t tracked by git, it doesn’t do anything… it just exits.

Consider using another response, such as “Not a git repository, nothing has been pulled. Are you in the right directory?”. I don’t need to hear about what process was killed or how it died, I just want to know what happened and what I should do about it.

Thanks

A rainy day, in SF town

I went to my first TED(x) event this past week.  I’ve never been to TED or a TED affiliated event before, so it was a real treat to see it live and in person after hours of watching luminaries on my laptop.  Hosted by the cool crew at Parisoma, the venue was far more intimate than I thought: about 45 people in attendance - including a few speakers - in a nifty loft space on Howard; not a bad way to spend a rainy day, IMO.

So how did TEDxSoMA compare to the TED we all know and love through the videos? Other than the world’s most uncomfortable chairs, I spent 4 solid hours totally captivated.  I was lucky enough to get a front row seat (literally) next to my new friends Simon and Ted, which let me see the talks up close and personal.  Overall the speakers all seemed well-versed in TED-style speaking: clear, very little reading, and lots of pictures if they chose to have a slide show. From Phil Libin at Evernote, to Heather Fleming at Catapult Design, to the intense Damon Horowitz from Aardvark (who reminded me vaguely of Gene Wilder in the original Charlie and the Chocolate Factory), it was a great lineup, and when you add in a great duet with the stunning Solenn Seguillon and beer from the folks at 21A, it was a recipe for success.

Common thread?

The only gripe I have is this: the talks, while fascinating, didn’t cohesively tie into the theme of the event, “Interactivity in Different Realms”. Sure, it was great to hear Libin’s theory on why man’s brain has changed little in 20,000 years (hence why we need Evernote), and Howard Roffman’s well-versed (and read) story of Star Wars over the years, but I found the common thread tenuous at best. But with an eclectic mix of people in the room we had little trouble brainstorming and chatting during the intermissions, and overall it was a great time.

One of the interesting consequences of working at a start up is that we all get to wear many hats. My role at EchoUser has always been part designer, user researcher, programmer and software development manager.

I thought it might be nice to share some of the blogs and sites that I frequent lately that help keep me somewhat sharp in these various disciplines:

Design / User Research

• Konigi
• Boxes and Arrows
• UXMatters
• http://johnnyholland.org/

Software Developer / Manager

• http://www.agile-software-development.com/
• Slashdot
• Signal vs Noise
• Ruby Inside
• RailsTips
• Ruby on Rails API

Feel free to add suggestions to my list in the comments!

When San Francisco banned plastic bags 2 years ago, my whoops of joy could be heard across the Golden Gate in Marin.  Having grown up in the developing world I grew accustomed - sadly - to seeing plastic bags everywhere they shouldn’t be: the streets, clogging drains, polluting rivers, the ocean, even stuck on phone lines. Everywhere except in garbage cans. You can be sure that I for one wasn’t going to miss their absence at all.

So imagine my surprise when last week my local Delano’s bagger put my groceries in one of these:

That’s funny, I could have sworn that plastic bags are illegal in San Francisco. So unless I’m missing something, this shouldn’t be allowed.

On second look, the makers of the bag have done their utmost to convince everyone that this is anything but a plastic bag with the liberal use of clever marketing copy.  Phrases like “no trees were harmed in the making of this bag”, and a cute little “nutrition” box highlighting exactly how it hasn’t hurt trees are nice tries - but belie the fact that eventually this bag will no doubt end up in a dump, where it most certainly will hurt a tree.

I get what the folks behind the bag are getting at: we have so many bags in production already that it certainly makes sense to train people to reuse them, thereby preventing more bags from ending up in landfills. Indeed, these particular bags do seem more durable than their crappy white plastic counterparts, so I could definitely imagine using them for more than one grocery run - but let’s face it: I can count on one hand the number of people I know who bring eco bags to the store every time they go.  Heck, I have 3 such bags in the trunk of my car, and I still manage to forget them each and every time.

As luck would have it, these bags have an answer for our laziness, too - a message nudging us to take them to “participating stores” for recycling. Good idea in principle, until my roommate tried it: turns out our local Delano’s isn’t one of those stores.

Go figure.

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.

…so why am I testing in a cave?

I’ve spent the last week conducting user testing on a top secret product ::: shhhhh! ::: from one of the tech majors down in Silicon Valley, and as a result have spent a lot of time in doors. Actually, so much in fact that I totally missed last Thursday’s glorious weather, only to emerge at 6pm with rings around my eyes, sallow skin, and a distinct fear of sunlight.

Joking aside, it did get me thinking about how we test participants with products.  Ideally we’re trying to recreate a lab environment for focused testing.  The theory goes that a dark, windowless room will help people focus (or keep them from being distracted, which are totally different things), or that it accurately approximates an existing work environment.

But everyone knows (here, here, and here) that the windowless, cubicle-warren approach doesn’t do anything for worker productivity, creativity, and ultimately, happiness. And yet Ux labs the world over have to adhere to the lowest common denominator, because let’s be honest, Ux labs that look like this are a long way off.

So if we agree that we should be moving toward a more open work environment, and it’s something we’re striving for in our day to day work, how does this translate (if at all) into product testing? And if we do agree to push the open workspace revolution, is the Ux lab as we know, love, and hate it: dim, confined, and with that cool two-way-glass, on the way out?

ATT logo

I love it when companies ask for customer feedback.  I’m that idiot that responds with an exuberant “YES!” whenever someone says “Would you like to fill out a survey/answer some questions/provide some feedback on your experience today?”.  Not surprising, really, given that studying and understanding experiences is my day to day. Besides, I consider it good karma - since we test a lot of users for our project work, it’s only fair that we return the favor!

Anyway, moving on.

I decided to give AT&T customer service a call the other day because my voicemails aren’t showing up on my iPhone.  I’m the only one of my friends with this problem, and after trying all sorts of quick fixes, as well as simply waiting (for AT&T to magically work - not a good idea, in the end), I broke down and called in.

There’s no need to go into the details of the call, though I will say that I got through to a person almost immediately (which is always nice), and even though “Marilyn” couldn’t fix my problem, she was very bubbly and earnest throughout the process.  It was more the end of the call that got me all riled up:

Marilyn: “Would you like to answer a quick survey about your experience today?”

Me: “Sure!” (note my excitement)

Marilyn: “Would you say I succeeded in trying to answer your questions today?”

Me: ::: silence as I tried to figure out the correct response :::

“Sure?”

Puh-lease.  My first thought was, “well, duh, why else would I call the customer support line other than to get you to try to help me?!”  The next thought that came to mind was the poor sod deep in the bowels of AT&T who will get all the “data” from this “survey question” and have to come up with a pretty chart to explain it to his higher ups. “But sir, we succeeded in trying, doesn’t that count for something?”

Not really, no. This example illustrates exactly why surveys are tough to get right: it’s all too easy to ask biased, misleading, or confusing questions - and sometimes, as with the AT&T case, all three at once!