12/28/2006

Two heads

I have two heads… and so do you.

When I’m making a decision to buy or use a product, I use my buyer head. I try to look at the product I’m considering objectively.

I identified this product because I have a problem, need, or goal, and I think this product will help me solve that problem, meet that need, reach that goal. I might imagine myself using this product and reaching my goals.

But, I’ve got choices… sometimes an uncomfortable amount of choices. And making a decision is tough. I consider the other products that also meet my goal. What features do they have? What features does this product have that they don’t? What features do those products have that this one doesn’t? And how much does this product cost relative to my other choices? Considering features with respect to cost might help me narrow down my choices. In the end, I’m left with a smaller field of choices based on my budget and my measurement of features against my goals.

I’ll admit it: sometimes I’m a bit of a sheep. I’ll follow others I trust, respect or admire. (Would Lance use it?) When I’m considering a product that I know others use, I’ll seek them out. I’d like their opinions – their recommendations. I’ll weigh that in with features and cost to help me make a decision.

There’ve been times when I just couldn’t imagine why people chose a particular product. It seems expensive, and has features that are not all that interesting to me. But, someone I trust or respect swears by it. So, I’ll give it a shot. It’s only money. After using it, I then often understand why it was recommended so highly. This product is great to use, and I didn’t realize that the benefits it delivered would be so valuable to me.

It’s my user head that engages when I start using the product

I put the product into use on a daily basis. After using the products I take a quick internal temperature check. Is my problem solved – or closer to being solved? Are my needs or goals met – or does it at least feel like I’m making progress towards that?

If this is a product that I use frequently, how do I like using it? Is it easy to accomplish what I set out to accomplish with it?

And, how do I feel when I’m using it. Does it make me feel competent? capable? effective?

Do people notice when I use it?

“Hey – nice widget! I was thinking of getting one of those. How do you like it?”

“Yeah, a good friend recommended it. It was a little expensive, but worth every penny.”

Sometimes my user head doesn’t like decisions made by my buyer head

My buyer head looked at my needs and goals, considered the features and price, and made what looked like the best decision. The product had good reviews. At least twenty people gave it four stars or more on amazon.com. Consumer reports recommended it. But… the product just doesn’t work that well – not for me.

Maybe I don’t get it? Maybe I could use some help learning how to use it. I don’t need half the features in this thing. I just wish I could figure out the couple features I really need. Were the other products this bad? I thought I really considered everything before buying this product. How did I end up with something that I dislike so much?

I forgot I have two heads.

My buyer head is considering different things than my user head. My user head often aggressively chooses the best value. But my user head is saddled with using this thing every day. It’s the one that really knows if my goals were met.

Two heads, two bodies

This story might sound familiar to you. If you’re in the business of designing and writing consumer software, you might be very aware of your customers’ two heads. But, some of you in the business of writing software for use by large organizations might relate to this story on a personal level, but not so much on a professional level.

With software, and lots of other products, sometimes the buying head and using head have two different bodies.

For example with [[http://www.oracle.com/applications/financials/intro.html, enterprise class software] the executives in the meeting room or at the trade show that make the decision to buy a product based on the perceived benefits to their organization won’t actually use the product. The people they employ or manage will.

Those actual users may not have been involved in making the buying decision. They, however, must use the product to reach their goals.

But, their goals are often a bit muddled. They work for a living, and really their goals are to be effective at their job. For instance, they may not really be passionate about using SAP to enter accounts payable vouchers, but their job performance is important to them. Being good at their jobs may be their real goal. They want the software to help with that. Oddly, in some organizations, mastering very difficult software is a way of protecting one’s job or status.

Separating buyer head from user head results in different design processes

In many organizations, usability is an afterthought. They spend a lot of time focusing on packing more features into the product. Sales or marketing people rush downstairs disrupting schedules with urgent requests for new features that will help close the big deal with the new customer.

No one’s happy about the complaints that come in from customer service. It may be that our users don’t think all that much of our product, but it sells well. It keeps our company in business. And, it’s no worse than our competitors’ products, right?

This is a company driven by the buyer head. Attractive featuresets with poor usability often happens when the buyer head is separate from the user head. It’s common when the buyer isn’t the user. It’s common when the act of buying takes lots of time, money… and commitment. It happens when it’s difficult to reverse a buying decision. It happens when people and time separate the user experience from the buying experience.

In organizations that design and build software for consumers who both buy and use their software, they know that the user experience is critical. Users with bad experiences will tell their friends about that poor experience. If the consumer purchased the product from a company with liberal return policies, they will return the product. Poor usability and user experience hits the organization’s bottom line more directly.

The design process in these sorts of organizations reflects this reality. There you’ll find processes driven by interaction designers supported by usability testing and lots of other direct customer interaction.

This stands in contrast to other companies that have lots of “buyer interaction” but less user interaction. Or maybe it doesn’t. Companies making more consumer-centric products do have buyer interaction – but coincidentally their buyers are their users.

When considering the requirements and design process the profile of the product you’re building matters

When we talk about design processes, we need to consider buyer head and user head.

One term in software development that makes me twitchy (for reasons I won’t go into now) is non-functional requirements. One non-functional requirement on most lists is usability. Let’s add one more: buyability.

If we consider usability and buyability on a matrix we find some interesting product profiles.

 

high buyability, high usability

Commercial websites have to cater to buyer head and user head almost continuously. In many cases, there’s little or no commitment involved in buying. I don’t really pay for google maps. If I don’t like it, I can surf over to yahoo maps. In fact I often do.

Organizations that build this sort of product likely have design-centric cultures. They’re both aware of usability, and of buyability. They’re concerned about the features and experience that attract people, and the experience that makes the product sticky. They’re more likely to consider many design alternatives. They’re likely to release software more frequently. The process they use will support these concerns.

high buyability, moderate usability

If I’m looking at Quicken, I might have to make a buying decision based on the features on the packaging, product reviews, and recommendations from friends. But, then I’ll lay out the cash and buy the thing. I might decide after a few days or weeks of use that I don’t like the product. I might return the product if I really hate it, and the store I bought it from will take it back.

I may find after buying this sort of product that it has more features than I’d ever use, or that the features I use most could be better. But, I spent time and money deciding and buying the product and I don’t want to go back to the drawing board. I’ll put up with a little inconvenience as long as it meets my needs.

Organizations that build this sort of product consider the product’s buyability, and usability. They likely have processes that consider both. If their product is a high ticket item – one where the dollar amount the customer puts out to buy the product is high, they know their customers spend a lot of time with a buying head on. The product may likely have more features than it really needs to in order to compete with other products – in order to win over buying heads. If other products in the market have feature parity with their product, the organization building it may spend more time on usability and user experience to enhance that aspect of their product. Their process incorporates these concerns.

high buyability, low usability

These are high stakes products. Large enterprise class products worth millions to purchase and millions more in professional services to install, customize, and train people to use. Executives who will likely never use the product make buying decisions based on product ROI. Usability matters… but it’s often considered in the context of worker productivity.

Organizations that build these sorts of products often have sales and marketing driven cultures. They’re driven by feature counts, and key features requested by key customers to help close big deals. Usability matters when end-user complaints rise to a noise level that disrupts sales. The design and development process in this sort of company supports sexy features first, usability second, and the process they follow reflects that.

low buyability, moderate usability

Correct or not, I’ll classify software built by a company for internal use as low buyability. If my organization is building it for itself, it may not need to consider other products. It will focus on the features it needs to meet its business objectives. It’ll spend the least amount possible to get those needs met – after all this is an expense. If the one who makes that spending decision won’t be a user, usability may not figure highly into that decision.

However, if the return on investments is based on some measure of usability often because the software supports key business processes, then usability will be given some attention. Products such as software used in a call center, or software used to automate shipping and receiving operations for retailers might fit that profile. Usability considerations will be built into the product to make sure the software meets its goals… but we don’t care much how sexy it looks doing it. This process to build this type of product is structured to support those considerations.

low buyability, low usability

This is software built for internal use and built to support less mission critical processes. We want this stuff cheap. We want it to accomplish what we bought it to accomplish. If I’m the business stakeholder paying for it, and I won’t be using it, I won’t pay for much attention to usability unless you can show me clearly where it hits the bottom line. Internal products such as time and expense tracking software or utilities in corporate intranets fit this profile.

A hydra fulla heads

I’ve been talking about buyer head, and user head, but there’s even more heads than that to consider. Think of these heads as a set of goals or concerns at play at the time we’re considering the product. When I’m trying to learn a new product, I’ll consider its learnability. When I use it daily, and I’m becoming proficient, then I’ll put my efficient user performance head on and look for advanced features that help me use the product faster. If this is a recreational product I’ll focus on the enjoyment I get from the user experience.

Heads with blinders

The trap to watch out for when you’re evaluating the quality of a product is to evaluate from the perspective of just one head. These heads, or bags of concerns, we have in place when we evaluate will sometimes blind us to other concerns. I picture blinders like those on horses whose job is to keep their eyes focused on the road in front of them .

Sometimes when we’re concerned that people will not adopt our product, we pile lots of features into it. This is buyer head with blinders.

Sometimes when we’re concerned with usability, we’ll fail to consider features or characteristics of our product that make it attractive to buyers. This is a user head with blinders.

Consider multiple perspectives when making design decisions about your product.