Archive for the ‘Design for Context’ Category

 
Jul
02
Posted (Brandon Satrom) in Design for Context, User Experience, Web Usability on July-2-2005

“Bad design cannot be patched up with labels, instructions manuals, or training courses.” - Donald A. Norman, The Design of Everyday Things

A couple of weeks ago, my wife and I ventured to Home Depot for a couple of items we needed in the midst of renovating our master bathroom. What started as a simple job of laying porcelain tile where once there were carpet pieces and linoleum has turned into a complete repainting of the walls, new tile on the counter, new fixtures, etc. That is a story for another day, though.

Our purchase from Home Depot was a typical case of “Going back after the initial trip to get the things you either forgot or didn’t think you actually needed.” So we didn’t have a large number of items, maybe 4 or 5 things. When I make a trip like that, I tend to use the self checkout that Home Depot offers. It’s a staple of any grocery shopping experience for us, so I usually gravitate there at Home Depot if I’m purchasing a small number of items.

On the evening in question that my wife and I were there buying 4 or 5 items, we encountered the following:

  • We waited 2 times for human visual verification of items.
  • The system told us 3 times to replace an item in the bags that it felt we had removed when, in fact, we had not removed anything. Human intervention was required to “reset” the system so that we could continue.
  • One item would not scan and required the self-checkout employee to take the item back to her station, scan it for us and then bring the item back.

Keep in mind that we had small items no bigger than would be in your basket at a grocery store. Unfortunately, I’ve found this kind of experience to be typical when I’m buying more than two items at the Home Depot. In addition, it wasn’t isolated to us. The couple next to us was encountering similar issues requiring human intervention. That means that, in addition to not being able to checkout without human intervention, we each were required to wait while the employee helped the other couple. It would have actually been faster for each of us to get in a typical line rather than attempting self-checkout even though we were “ideal” users of self-checkout as far as the Home Depot is concerned.

While our self checkout experience on this particular evening wasn’t overly painful in that it still took less than five minutes, it also wasn’t swift like a self-checkout experience at a grocery store tends to be. That, combined with the couple next to us who were obviously “muddling through” their checkout experience, got me thinking about self checkout and design for context.

The difficulties in the self-checkout at Home Depot seem to center around the business rules they used to “calibrate” the system. More so than a typical grocery store, Home depot offers products that vary vastly in size, dimension, weight and price. You can purchase anything from a single nut to a pre-built aluminum shed and you can do so through self-checkout. As a result of this “shopper must be able to purchase any item at self-checkout” business rule, the system is set up to do some funky things that the person buying spray paint and drywall screws sometimes gets frustrated by. Similar to the experience above, I’ve been through the line buying 180-degree caps for my sprinkler heads and had to wait for approval from the warden of the self-checkout that hovers from station to station.

While enabling customers to purchase anything from self-checkout is a noble goal for the Home Depot, ask yourself what you think a self-checkout system should be designed for. Now, I could be wrong about this, self checkout could have been designed for the amusement of the employees that work at the stores where it is used, but I surmise that the intention of self-checkout was designed to accommodate the “in and out” shopper. It’s the Amazon.com 1-Click of the brick and mortar world. It was installed in grocery stores and the Home Depot alike to accommodate one of the two types of shoppers both venues get: the “I need a few things and I want to be on my way” group. One could argue that this also helps the other group, the planners who load up on a weeks worth of groceries or a project’s worth of supplies and aren’t (or shouldn’t be) in any kind of hurry. They don’t have to wait behind a line of 6 people each getting one item while they block the front aisle with large sheets of plywood and 2×4s.

The problem is that the business rules tend to hamper the demographic they should be targeting by setting up just-in-case rules for people buying abnormal items that won’t fit on the weight-sensitive bagging tray or high-priced items that require visual verification. The just-in-case idea is admirable for the Home Depot because they try to accommodate every shopper they have, but it damages the experience of the in-and-out shopper when they are affected by business rules that don’t apply to them.

And thus, this is a problem of failure to design for context. I’m not suggesting that the Home Depot failed to consider their context altogether; the fact that they calibrated their system with so many rules suggests that they did. The problem is that they designed for one context and assumed that the “out-of-the-box” system would work for the other.

Doesn’t that sound a bit like the original query from my first post: “Take a look at widget.com and let’s do it like that?” The moral of this story is that the context of your business and of your customer base is important. There is no such thing as an out of the box solution for either unless it’s your box to begin with.

In my next post, I’ll continue this discussion with a bit about where this kind of context breakdown occurs: ideas vs. implementation.



 
Jun
29
Posted (Brandon Satrom) in Business, Design for Context, User Experience, Web Usability on June-29-2005

Have you ever been in a design meeting with a customer and been told something like this:

“We need to add [a cool new feature, content, functionality, etc.] to our site. Take a look at [Amazon, Google, Microsoft, or any other oft-compared-to website.] and let’s do it like that.”

I’m sure you have. If you haven’t, you haven’t been in many design meetings.

Most of us probably get a deer in the headlights reaction to this and simply say “I’ll take a look” or, “That’s an option,” when in reality, that statement should prompt us to direct a barrage of questions back at the customer.

What questions, you ask? Questions about context and usability. More on those in the next few posts…

Here is what is happening when a request like this is made: Your customer wants your site to look like the site in question with the goal being to have their traffic and do their business. There is this nice trend on the web these days towards homogeneity (for a number of reasons) and, while I think that uniformity equals usability to a fault (read: on a site-by-site basis), I do not think the entire web needs to operate in the exact same way.

And I don’t think anyone is saying that out loud. I just think that internal customers for those of us that create and maintain a corporate web or webs are starting to ask for and expect that.

“What works for the goose, works for the gander,” they think and say. But what if the goose is selling pet medication and the gander is peddling over-priced duvet covers?

In all honesty, if I’ve determined that something is very effective on my site because I’ve taken the time to conduct user testing, do I really care if it will work for yours? Conversely, just because you’ve done something on your site that enhances my user experience doesn’t mean that it will work for my site.

Notice one key thing I said in the last paragraph. “I’ve taken the time to conduct user testing.” That is the biggest IF on the web. It’s also the caveat to any evaluation of something working for you in your context. Remember the old logic question that went something like this:

“If all snarps are flarps, and some flarps are clarps, are all snarps clarps?”

Meaning: Some users on my site may use widget.com a little or a lot. But I can pretty safely assume that some don’t, so why would I design aspects of my site to pattern widget.com just because widget.com does it and some of my users are familiar with it.

In addition, what guarantee do I have that widget.com actually did any of their own user testing on this functionality? They could have stolen it from doohickey.net. And who knows if they actually tested it on their site. And so on…

My muddled point is this: I think that we’re in a world where our customers will supplant their own user testing with something that works for another site. The flaw in that reasoning is that we don’t know how they decided that it “works.” They could mean:

  • It looks nice.
  • It works… for me.
  • My son uses this site all the time and raves about this.
  • My admin suggested this to me.

Our challenge is to reverse that thinking by asking questions of context and championing user testing for everything we design.

My next couple posts will spend more time expanding on the concept of context. Then I’ll wax a little on user testing. Finally, I’ll look at consequences of our current path and what we can all do to work asking about context and user testing into our daily lives.