Translating Usability to Dev-Speak

The standard definition of 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.”

That definition works on my computer! … </tumbleweed>

There’s a lot of opportunity in that definition for “but what does that really mean” responses. It makes sense on its own, but when applied to your context of work, how does it fit? I think the problem is that most people don’t know how it fits. They don’t know who the users are so they can’t be specified. They don’t know what the goals are so those can’t be specified. And how can they make sure something is effective, efficient, and satisfying?

Get someone from Usability to look at it! Of course, you might not have someone from Usability available, or at all. Or have time to do usability testing. Or user research. Or, or, or. Most companies have this problem to some extent. Developers are often left on their own to figure things out and I suspect that’s the impetus of 3 Simple Usability Tips For Developers.

Jesper specifically asked me (and others, I’m not that special) to respond to his post and since I know my response won’t fit in a comment box… here we go…

Everyone Cares About Usability

Everyone cares, to some extent, about usability. “Good” usability means happy customers, silent support phones (ha!), and heaping great wodges of cash in the biscuit barrel. Who doesn’t care about that! No one, that’s who.

The problem, as ever, is no one speaks about usability in the same way. So Jesper boiled down the ISO definition of Usability to something simpler:

A usable system is easy to use, easy to learn, and difficult to make mistakes [with/on].

I have no issue with Jesper’s boiling down-ed-ness, but I think it does just that: boil down. As tips specifically for developers, I think different jargon is in order. Now, now… I know we Usability peeps are supposed to avoid jargon, but when you have a (relatively) singular audience, you design your system with their language in mind. Here’s how I would re-jargonize (man, I am making up words left and right today) the definition of Usability for developers:

I’ll give you a bonus if you make software that meets our customers needs, is coded as simply and securely as possible, has no known bugs, and works the same way on all the platforms we support.

I put the bonus part in there because I believe developers need incentive. The bonus could be doughnuts, not necessarily cash.

Meets our customers needs. You can see this in the current definition of Usability, but I believe when put this way, a developer that you want working for you will ask, “Who are our customers and what do they want.” And by gum if a developer ever asks you that you’d better kiss them (don’t actually kiss them). The easiest way to find out what people want is to ask them. Surprisingly, they usually want to tell you.

Coded simply and securely. You want the simplest solution possible to the problem. Most of the developers I’ve seen tend to write 30 lines of code when 3 would suffice. Create an environment where elegantly coded solutions are more valuable than crap code. But you also want secure code, so no PHP. If you have a situation where you have to choose between simple and secure, make sure you communicate what’s more important given the context. To figure out the context, see previous paragraph.

No known bugs. No bugs is a pipe dream. There will always be bugs in software. If you test all cases you’ll never ship, so go for no known bugs. Shipping with no known bugs means you need to have a good stock of test cases to work from. To get good test cases you need good use cases. “How will people use this software? Let’s test it to make sure it works like that!” To get good use cases, see the paragraph above the one above this one.

All platforms. I throw this one in because web development is becoming so prominent. Companies are relying more and more on the web to make money and get things done. That means more web apps and most of those web apps are being written by life-long COBOL programmers. Choose which platforms (and browsers) you will support and run your test cases on all of them. Listen to your developers when they say it’s not worth testing on anything below IE6. Developers, please start saying it isn’t worth testing on anything below IE6.

What is Usability Really?

Usability is a lot of things and it’s mostly not usability testing.

Bugs in software are a huge problem. Bugs slow down or keep users from completing tasks which costs you money because you didn’t do it right the first time and because the user may not buy your product again. Bugs increase calls to support and even if you offshore this it’s expensive. Bugs are something developers think about.

Now that I think about it, that’s a better definition!

No known bugs.

To get to that point, you have to do a lot of the up front work right. Doing that up front work will often solve (read: not introduce) usability issues.

Shorter Next Time?

Yes, I could have left an, “I agree!” comment on Jepser’s blog.

But I’ve often said I see my job as a translator for all parties involved on a project. I translate what the users want to the business people and the developers. I translate between the business people and the developers. To me, that’s the value of a Usability person. They learn to speak the language of their customers and on a project, everyone’s a customer.

So to developers I say, “no known bugs.” To business people I say, “reduce calls to support,” and “increase sales.” To users I say, “it just works.” To everyone, in some respect, it’s about the end result being useful, usable, and satisfying.

No known bugs are useful because it means you don’t have to fix past mistakes; you can work on new (necessary) functionality. More money is always satisfying. Software, when usable, means your customers don’t even think about your product.

And that’s the best compliment of all.