It’s All About the Persona(s)

cisg — Fri, 12 Sep 2008 09:38:54 GMT

Birm here…

Has this ever happened to you? It’s happened to me. You sit down to write an application that looks great and works even better. The UI you’ve designed is a model of esthetics and efficiency. You’ve demo’d it to the developer in the next cubicle and she’s loved it! Then you hand it off to a real-life user and it falls flat. Like a run-over pancake.

When we sit down to code an application somewhere, somehow there is a person who’s eventually going to be using it. Usually that person starts out as -- and too often remains -- a figment of our imagination. What we’ve done is what Alan Cooper calls in his book, The Inmates are Running the Asylum, “bench development.” That’s where the “user” we’re coding for resembles the guy sitting at the next bench. A guy who may be writing another part of the same app as you are, and likely with a vastly different user in mind. Instead of developing applications for one or more well-defined and well-understood personas, that guy and we each go our separate way, never taking the time to communicate and agree on what and who our true user is.

The major malfunction is that we as developers and designers have forgotten a basic, immutable fact: we are not our users.

Enter Personas

When a problem arises that lends itself to a computer solution, there’s usually a specific business need underlying the problem. It follows that there must be a diverse and yet specific constituency for that solution. A computer program useful to a mechanic will be useless to an animal trainer…and vice versa.

A persona is a representative archetype that models the kind of people who will be really using our application. An archetype which is qualitatively and quantitatively validated so that we know that we can rely on it. An archetype described in such detail that every developer on the team feels like they had lunch with that persona just last week.

The first step in creating a persona is to unambiguously decide on what kind of person(s) would be included in the constituency for your application. Then you go find several of those kinds of person and talk with them. You ask them about all the things that would be helpful in designing an application that would be useful for them. For example, what exactly do they see as being their occupation? What are their goals as they perform their work? What information do they need to do their job, and in what form? What are their day-to-day frustrations and pain points? How, and with whom do they communicate to get things done? What you end up is a list of characteristics and attributes that you consolidate into one or more personas.

One final thought: to create a persona and to create fiction are two disparate things. For a persona to be reliable and actionable, it must be a truly representative archetype, with nothing about it pulled out of thin air. You can consolidate characteristics and attributes, certainly. But they must first actually exist in the group of people you interviewed to get the data to create the persona.

Doing What You Want, Not What You Have To!

cisg — Fri, 05 Sep 2008 18:22:17 GMT

Birm here.....

As I go about my daily routine, I talk a lot with people directly involved in software design and development. It’s become clear that based on their training and experience, each person has a different take on what constitutes “user experience.” And while they have an idea of usability, they’re not well schooled in how usability is achieved.

Usability – good usability -- is a concept which is at the very heart of a great user experience. That being the case, and given that we’re just getting started with our blogging on user experience, it seems the right thing to do to step back a moment and agree on its definition. I’ll try not to be too tedious as we go about this…but we’re laying a foundation here, and it’s important that we all really understand usability in the same way.

The International Standards Organization (ISO) published back in the early 90’s a standard having to do with the ergonomics of first visual display terminals (remember them?). ISO 9241 has evolved from discussing simple VDT’s to present-day computers. It now includes standards for the usability of software. To be specific (pun intended), ISO 9241-11 says that usability is “the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use.”

They expand on this in another part of the standard. Notice the three words I italicized in that paragraph. “Efficiency” refers to the accuracy and completeness with which a user achieves their goals. “Effectiveness” has to do with how much effort the user has to do so. Finally, “satisfaction” is about how happy a user is with the tools they have to employ to get to their goals. In each case, it’s all about how well everyday people are able to interact with the products you design and build.

The Usability Professionals Association (UPA) – a group of which I am proud to be a member– says usability is, “an approach to product development that incorporate direct user feedback throughout the development cycle in order to reduce costs and create products and tools that meet user needs.” Here we see a point of view of people who are trying to get across to business decision makers the value of incorporating validated usability into their products. Turns out that the argument is actually a fairly easy one to make. There is a demonstrable ROI to usability, and we’ll be talking about that in a later blog.

Back around the turn of the century, Steve Krug wrote a really great book called Don’t Make Me Think. His definition gives a more personal perspective to the concept. Krug says, “Usability really just means making sure that something works well: that a person of average (or even below average) ability and experience can use the thing – whether it’s a web site, a fighter jet, or a revolving door—for its intended purpose without getting hopelessly frustrated.” Not a lot of us have flown fighter jets. But I’ll bet that more than once you’ve pushed on a door that the builder expected folks to pull open instead.

I’ve saved the best definition for last. In his book, User Centered Web Design, John Cato defines usability as “…being able to do the things you want to, not the things you have to.” And that friends, is what usability is all about. If with our applications, our customers get to do what they want how they want to do it, then they’ll have a great user experience.

It's just as simple -- and just as complicated -- as that.

The Connected Information Security Group : UX

It’s All About the Persona(s)

Doing What You Want, Not What You Have To!