Verifying 911 service in VOIP

I work from home full-time and I recently decided to switch my second phone line (my business line) to VOIP to save the company some money. I'd been avoiding it because I'd heard negative comments from co-workers about the quality, but the money I was being charged for my nearly constant teleconferences finally made my decision.

And I'm delighted with the change. I haven't had ANY connection quality issues, even when I'm screen sharing at the same time. It's been crystal clear and reliable. And everytime I make an hour-long long distance call and remember that it is costing me nothing, I smile a little. It's wonderful.

Except for one thing. Every couple of days I'll make a call and a voice will tell me that before they can connect me I have to verify my 911 service is still the same number that they have on file. First, I have no idea why they need to keep asking me this. But even worse is that it won't register my keypress until it has spoken the entire message AND all the options. I've heard this message so often I've started hearing it in my sleep... and yet I have to wait to listen to the whole thing, everytime, before it will let me press "1".

I still love VOIP, but somebody needs to fix this.

Proof of the difference between survey results and truth

CNN.com had an article about the recent results of JD Powers' survey of recent car purchases, and which cars consumers liked the most. Here's what they had to say about the VW Passat, the winner of the mid-sized car category:



Huh? "The Passat's drivetrain was a particular high point among owners..."

They should have followed that statement with "... which proves that our survey is so poorly constructed that the results are completely meaningless."

Now, I freely admit that no one would describe me as a car wonk. I don't spend weekends rebuilding carburetors or swapping engines out of 1968 VW bugs. I've made it 39 years without ever changing the oil in my car myself. But c'mon... how many people, when asked how much they like their new mid-sized car, will respond, "Oh, I love the drivetrain! It's flipping sweet! Wanna see it?"

My guess is JD Powers asked people to rate their cars along a standard set of dimensions, but didn't ask what dimensions actually mattered to them.

Explaining UX to 3rd graders

| View | Upload your own

Here's my presentation. It turned out that the biggest challenge was forcing myself to leave out all the things that someone needs to know to REALLY understand user experience and only leave in the few things that a 3rd grader would be interested in... and can understand in 20 minutes.

I'm not sure the prez will make complete sense without my talking points, but I think the flow is fairly self-explanatory.

I gave the presentation this morning and it went really well. Not surprisingly, the idea of designing video games was a big hit with the kids.

BTW, "Tyler" is my son, "Ms. Stephenson" is his teacher, and "Easley" is the name of his elementary school.

Abject terror!

I'm still not sure how it happened, but somehow I found myself volunteering to go and tell my son's 3rd grade class about what I do for a living. Why did I inflict this on myself? How do you explain user experience to a bunch of 8 and 9 year olds? I can't explain it to adults. My mother still doesn't know what I do for a living. Heck, at this point in my career I'm not sure that "user experience" is a big part of what I do... I'm more of an "Opportunistic Firefighter". There's a bunch of fires raging all over the place... far more than once person can tackle... so I look for ones where we have the best chance to put the fire out, then I wade in with my firehouse and see what we can do. Yes, I concentrate on "user experience" related fires, but as I've mentioned before, if you squint enough, everything is user experience-related.

But I don't think I'm going to explain to them what I really do for a living... that would be far too boring and I wouldn't want to embarrass my son that badly. Instead I think I'll explain something about what a software designer does. These kids are computer savvy, so I think they'll understand the concept that a human being somewhere has to create the websites they visit and games they play. And I think they'll like the part about talking to the human beings that will use the software before it's actually done - game testing is something they "get".

But it's going to be a real challenge to keep the conversation at the right level while still doing a reasonably good job of explaining what design is all about. I think I need some good analogies (like building a house). And I need to avoid completely geeking out (which is an obvious challenge for me) and using professional jargon that they won't understand. It's easy to forget how useful jargon is... but try living without it for an hour.

If I come up with a presentation that isn't awful, maybe I'll post it here via Slideshare so people can make fun of it.

Minimal personas

I wonder if there is some minimum set of information needed before you can really call something a "persona".

Do you need a "person name"? Do you need a photo? Do you need any non-domain personal information?

Obviously one of the challenges with personas is that they can be rejected by uber-geek developers on the grounds that they are egregiously cheesy. One way to avoid that is to remove the cheese. Replace the person name with a job title. Don't mention anything about how many cats they have. Include personal information that is directly related to the design of the product, like, "So-and-so clocks out at 5:00 sharp and whatever he's working on gets forwarded to the next shift," because obviously that might impact how easy it is to forward work.

But one of the goals of personas is to ease communication and make them more memorable by talking about a "real" person. Without the cheese, can this be done? Is it still a persona?

Is "consumability" another useless buzzword?

"Consumability" is a term that appears to have been coined within IBM. I'm not sure who coined it or when it first appeared, but I started hearing it thrown around about 5 years ago. At first I groaned and thought, "Oh, great, that all we need... yet another term for user experience." Whoever coined it must have been an executive because it didn't die (grin) and I started hearing it more and more within IBM.

I've since come around and started to really appreciate the utility of talking about "consumability". But what is it? Is it different than user experience?

Carl Kessler, an IBMer who writes the outside-in-thinking blog and wrote Outside-In Software Development (which I reviewed here), has the best definition of consumability that I've seen:
"Your stakeholders primarily want to perform the tasks with your software that directly relate to their business goals. But when they use your software, they'll have to also address some additional tasks that aren't in their direct path toward accomplishing those business goals... We call these meta-tasks... We refer to this impact of meta-tasks as consumability; the more the meta-tasks distract from your product's business value, the less consumable it is."

In other words, consumability is the measure of all the crap you have to go through outside of using the product to directly accomplish your goals.

Is user experience a subset of consumability or is consumability a subset of user experience? Well, the problem I've always had with "user experience" is that it's so ridiculously broad that anything could be claimed to fall under the user experience umbrella. In practice, I think there's a lot of overlap between the two, with a few things that are only in one space and not the other. For example, lowering the price of your product will increase its consumability, but doesn't have an impact on user experience (other than 7th order effects). Likewise, improving the usability of your core business value doesn't increase consumability, because consumability is what you do before you get to the business value.

But there are two reasons I like the consumability term. First, consumability has a very different impact on your product depending on your industry/context/market. For example, consumability is not a big deal anymore for MP3 players. When they first went on the market, consumability mattered more because consumers weren't sure how to get music onto them - or even get music on their computer. Nowadays consumability for MP3 players is little more than identifying the "on" button (which in some cases, like the iPod, is harder than you'd think). On the other hand, in the area of enterprise middleware (my area), consumability is enormously important. Enterprise customers are trying to manage installation and fix levels across huge numbers of servers and development machines. When things get out of synch, bad stuff happens. But they don't buy middleware products because they want to manage installations - that's just something they have to do to reach the business value. As hardware costs shrink and people costs rise, consumability is more often becoming a critical business driver.

The other reason its a useful term is that there's a natural, understandable tendency for teams to want to focus on adding direct business value to their products. During release planning, a common and obvious question is "What's the business value for this feature?" Well, what if your goal is to dramatically improve installation? Obviously the product could be installed previously and (as just stated) customers are not buying your product because they want to install it. So the business value of simplifying install is, um, well... not there. When you simplify install and the new product releases, you don't get to put a bullet down for something new that the customer can do. Sometimes this can be a hard sell, which results in products that are constantly adding new features but over time it gets harder and harder for customers to actually get value from the new features because they have trouble getting to them.

Talking about consumability changes the conversation. Improving consumability means less staffing is required for things that aren't adding business value, it means faster time to value, and it lowers the skills required to get things up and running... and maintain it afterwards. These are things that both planning teams and customers can get their head around. User experience isn't focused enough to make the same points.

I'm not sure whether "consumability" will make any headway outside of IBM, but I think there's a place for it.

Boxes & Arrows: Building the UX Dreamteam

There's an interesting article on B&A about Building the UX Dreamteam by Anthony Colfelt. Worth the read.

I've added my comments about the article on the B&A site, rather than here.

Explaining your products to your customers

This video illustrates some useful Best Practices from a UX standpoint.



(Thanks to my colleague Tim Francis for pointing me to this video)

Top 100 UX blogs - I demand a recount!

Virtual Hosting Blog has compiled a list of the Top 100 User-Centered Blogs. Shockingly, my blog did not make the list. This is an outrage!! I blame the hanging chads!! Stalin was right!!

Okay, so I only have one reader (Hi, Mom!), so maybe it's not a complete shock. (I'm just kidding -- my Mom doesn't actually read my blog)

Regardless, this is a really useful list of sites, and unfortunately highlights to me just how hard it is to keep up on everything that is going on.

Time to update my feeds.

37signals doesn't like personas

Jason at 37signals has an interesting post about why they don't use personas:

Every product we build is a product we build for ourselves to solve our own problems. We recognize our problems aren’t unique. In fact, our problems are probably a lot like your problems. So we bundle up the solutions to our problems in the form of web-based software and offer them for sale.

We recognize not everyone shares our problems, our point of view, or our opinions, but that verdict’s the same if you use personas. Making decisions based on real opinions trumps making decisions based on imaginary opinions.

I’ve never been a big believer in personas. They’re artificial, abstract, and fictitious. I don’t think you can build a great product for a person that doesn’t exist. And I definitely don’t think you can build a great product based on a composite sketch of 10 different people all rolled into one (or two or three).

In addition to the post itself, the comments are really well-written with good points made in both directions.

For me, what's interesting is that I am known for not being a big fan of personas, and yet I think Jason is completely off the mark in his criticism. Or, to be fair, he highlights good reasons why 37signals doesn't need to use personas, but doesn't seem to recognize that those reasons don't apply to many other teams - 37signals is not a representative company. They are the exception, not the rule, because they strongly believe that they are the users of their own products. Not only is this unusual, in my opinion it's also not sustainable.

The other mistake he makes is that he thinks personas are meant to replace talking to real people. Of course, the truth is the opposite - personas are the output of talking to real people. For most organizations, it's just not feasible for every person in the organization to talk to real people and have the skills to successfully interpret what they actually mean and not just what they actually say. For the people who do talk to people and do have those skills, we need a way of communicating the results of those discussions to the rest of the team. Personas are one way to do that.

(Of course, it goes without saying that like any technique, there are teams that do personas poorly, but that is a reflection on that team, not the technique)