Tuesday, March 11, 2014

Even developers have feelings. (Rolf Molich)

I’ve always found it ironic that usability engineers, who are so centered on “the user,” often neglect to keep their own users in mind.  I’m not talking about the end users of some system or website, but the usability engineer’s own clients, the people who receive the reports and pay the bills.

This problem seems to be most evident in usability reports.   I’ve seen a number over the years that just aren’t very friendly.  And so has Rolf.  In fact, one of his main interests is helping usability engineers create better, more usable reports.  

So, what are Rolf and I griping about?  Now, this is by no means something that is the problem that it was years ago, and probably only applies to a small minority of usability engineers these days.  I guess I put it all down to two things…

One is that we are engineers, right?  So, it’s an engineering report then, correct?  And we all know that engineering reports are long, and boring, and have plenty of data and tables and appendices.

The second is probably simply a hangover from academia.  God knows there are an awful lot of PhDs in this field.  And we all know what journal articles are like, right (and how long, boring, and full of data and tables and appendices they are)?  

Well, as it turns out, our actual audiences cannot typically get as jazzed up about the traditional usability report as we can.  Our audiences are usually not other usability engineers or editors of academic journals.  Our audiences are typically information architects, and interaction designers, and marketers, and execs, and graphic designers, and content specialists, and – can you imagine – even developers!  

There are plenty of things we can do to make our reports more usable for our actual readers, but one thing we can do to help developers (and any person, really, who had input into the look and feel of what we are testing) is simply to be nice. Now, there are several ways to do that.  

One that I have fallen in love with over the years is to simply include some positive findings in my report.  I have heard other usability engineers balk at that, saying that we’re all adults here, that we’re not getting paid to stroke egos, etc., etc.  I find, though, that responding well to positive reinforcement is simply the way that most humans work – and that includes developers as well.


Monday, March 3, 2014

Personas are the bright lights under which designers do surgery. (Kim Goodwin)

There are three ways to design a website or piece of software.  One, you can just code it up and throw it out there.  Or, before you throw it out there, you can run it past some real users.  Or, if you really want to do this user-centered design thing, you can do some user research upfront.

That last piece, in my mind, is what really separates the men from the boys (the women from the girls, the adults from the children – you know what I mean).  It allows you to bake in usability from the very beginning.  That said, I’m often surprised at how little it’s done.

So, what does that actually involve?  It might be as simple as interviews, or as complex as a field or diary study, or something in between, like a focus group.  It’s what you do with that data, though, that’s really crucial.

And that’s where personas come in.  Upfront research can generate a ton of information.  What the researcher’s real task becomes is how to take that fire hose of data and turn it into a nice, quick, refreshing drink.  And, for that, personas really can’t be beat.

I think we all know what personas are by now.  You take all that information you uncovered, then distill it into several user types.  What really makes the persona, though, is how we can turn each one into a real person – with a name, a picture, a place where they live, a job they go to, a family …  

Humans are social animals.  They also love a good story.  What personas do is take those two very important human characteristics and turn them to your advantage.  Instead of designing for a complete abstraction (or, worse, with no one or yourself in mind), how much easier it can be to keep the user in mind by thinking of Phyllis with her fear of technology, or Bill with his impatience, or Julie who is trying to juggle family and job and caring for her elderly parents.

Over the years, I have gotten some resistance to using personas.  It’s often a little too touchy-feely for computer science or MBA types.  What’s gratifying to see, though, is how readily personas are adapted, when given just half a chance.  It’s so nice when developers start talking about Ben or Carol or Leah.  To me, though, that’s just human nature.

Kim Goodwin has a pretty good background in personas, having worked for Alan Cooper, the creator of personas, for 12 years.  She’s also the author of Designing for the Digital Age.