Design for Context Part I – Introduction

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.

  • memphis p.

    Flarps, carps and geese. Great post, can’t wait for the rest of it.

    Hmmm, so if I really get what you’re saying, then just because Google or Amazon or doohickey.net does it that way, then we should too? Yeah, been there doin’ that. My guess is that business customers will be business customers, at least until they get hit where it hurts (most often in the bottom-line). Trouble is, it’s at that point where they misplace the blame: on the poor developer trying to keep braces on his kids and the lights on at home!

    I believe that the user experience must be elevated to the boardroom: in other words, usability testing must be viewed/experienced (preferrably first-hand) by those in charge of the big bucks and our pink slips. From their lofty towers of ivory, if exposed to just such reality, they may (and I mean may) just change their mind and realize that there is no single profile of a web user, a widget customer or anyone else who interacts with the company….

    Ah, but I digress, what I really want to know is why the goose is selling pet medication and not nursery rhymes?

  • john

    This is a great post. I look forward to many more like these.

    This post is so true of many of my customers. We must work with the same customers. The customers just don’t realize that if Amazon or Google does something that is not very user friendly, they will not loose that customer. They may not make that sell but they will not loose the customer. Their brand is ingrained into us and we (the user of well branded x) will continue to return and shop or search or use them.