5 Things that Usability is NOT

My usability team, like most others, is situated in a development environment where there is pressure to perform by providing actionable recommendations and deliverables with practical substance. Providing value often involves setting reasonable expectations for what we do and provide.

I like to explain what a usability team does by describing what usability is NOT. This list is not comprehensive, but has been successful for getting my point across. A usability team is like a tool for a software company - there's a right way to use it. While you can use a knife to eat peas, a lot of your dinner is going to remain uneaten.

1. Magic.

Doing usability work does not necessitate having special *magical* abilities or talents. There are some skills and principles that are learned, but most good insight into usability comes from observation and research – from users, not UX professionals. People often look to my team as being able to "wave our magic wand" over some UI, and make optimal recommendations to achieve this ephemeral quality called Usability. There is no magic here; just hard work and in-depth observation. Similarly, unlike a magical spell, that provides an instant result, doing usability work takes time. Research is resource intensive and hard. But it has real ROI and is the smart approach to take.

2. Icing.

Usability is not the frosting on the cupcake that you brush on at the end. You can't first build a piece of software and then spread some glittery pink sweetness over the top of it and expect to have anything remotely meeting real users' needs. A usability team should be brought in from Day 1 of a new product's development. We should be helping to define the requirements in MRDs and PRDs, helping refine the alphas and betas. We should be part of the cake batter, baby!

3. About you, or me.

Look at the guy in this picture. This is a real user in a usability study I ran some years ago. See his face? He is expressing confusion and uncertainty at a design that I had no problem with (in fact, it's something I designed!).

It's a mantra we UX professionals should repeat to ourselves (and to the stakeholders we work with!)... "You are not your user!" It's constant discipline to keep reminding ourselves that just because we see something some way, or want some feature, or have no problem with an interaction flow, it isn't really relevant! We need to keep bringing in real users and testing concepts with them. Users will always, always surprise you. Staying objective means talking (a lot!) to other people besides internal constituents.

4. Completely novel.

About 90% of usability design involves drawing on design patterns and interactions that users have become familiarized in their previous interactions with technology (and the physical world - think buttons and tabs!). We use radio buttons when the information structure suggests it, we don't make up some completely new rule or behavior for interaction just because we want to inspire or delight. So, if we have to keep our designs consistent, where does innovation come from? I'd say that's the remaining 5%. In general, avoid the temptation to over-engineer – or over-elevate things to the interface that a software engineer put behind in the code. Keep it simple and consistent, and trust me the beauty of a smooth interaction will outweigh any desire a user has to want to "decypher" your clever, innovative UI.

5. The Holy Grail.

Ultimately, a usability team is situated in a business environment and needs to operate fluidly between many arms of a company. While user needs should be important for setting priorities, sometimes creating a product involves compromise, and iterating on a design until you get it as good as you can.

For instance, I've done a LOT of usability tests involving registration of a software program. Users always say that they would prefer not to share their email address when creating an account! Marketing would balk (and they have) if I tell them to remove this technical requirement if they want to improve UX. In the end, it doesn't matter. That's the way it has to be because the comprehensive marketing plan relies on email marketing campaigns. My job, then, becomes asking for email addresses in a way that is as painless as possible. It's a compromise. It's our job as UX professionals to stay nimble to competing constraints, discover what other teams are working with, and keep coming up with creative solutions given those constraints in place.

Crafting an argument in the age of 140 characters

I promise this article isn’t going to turn into a lament about the demise/downturn of Tribe.net. True, we regular users were all sad to see it go, and most of us sold out and migrated to Facebook reluctantly, once the rest of the “herd” moved south. After all, we are social creatures, and we follow the pack. I’m a digital anthropologist, and I’m interested in how adopting technology changes and shapes our social practices. Design always involves tradeoffs. Tribe, Facebook, or Twitter are built with a set of design constraints, and these design choices have real implications about how we use these differing media to think and communicate with one another.

The premise of Tribe is to build a profile and join certain moderated groups (“Tribes”) where discussions take place. Anyone can create a Tribe, and they range from a subject area, to an event, to a location group. As Tribe member, you are alerted when new posts have happened within Tribes you are affiliated with. Users can create threads and respond to them. Posts within a Tribe can range from short comments to long paragraphs of text. An advantage of the Tribe.net format is that discussions and replies can be any length, and some of them actually involve in-depth debates where people actually create and build an argument. A disadvantage of Tribe.net’s design is that information is locked away from the surface (i.e. like any other discussion forum site, all you see is that new posts have rolled in, not exactly what they entail).

When I was an avid, active Tribe-er, I spent a lot of time checking on the latest discussions and contributing my thoughts and commentary. I think I was actually a better writer back then, having to string together a cohesive, coherent paragraph or two, rather than the “one-offs” I post to my friends’ Facebook feeds today.

Although Twitter’s hashtag convention allows users to argue/discuss/comment on a particular conversational topic, all we get are groupings of single sentences. How much of an argument can one construct in 140 characters? Most of what seems to occur in Twitter discussions seems to be “shouting into the void” rather than substantive discussion. Similarly, Facebook groups our conversations based on someone’s status update or post, but again, we’re severely restricted on string length. And though we have email capability on Facebook, conventions seem to have shifted towards posting short blurbs and messages directly on a friends’ walls.

The conversations we have on Facebook and Twitter remind me of a depressing dinner I once had with some girlfriends. We’d tried 3 or 4 times to find a date that matched everyone’s schedule, and I was excited to find a time to catch up with everyone. However, the restaurant was loud, we were all high strung and stressed, and I felt like the entire meal we were simply shouting at each other about our big, urgent problems and complaints. No one was actually listening. We were too busy with the chattering in our own head. I felt a little sick when I left, like I’d hastily eaten the entire meal without tasting it.

This comic is so symbolic of my years on Tribe. I think I love this image because I see myself in those clenched hands flying furiously over the keyboard. Oh we waged wars of words on those discussion threads! It was dramatic, and it was fun. We practiced a craft together, an art that I fear is dying as our communications grow shorter and more piecemeal. I guess I should be thankful for blogs– one of the few remaining outposts for these aging paragraphs and drawn-out arguments.