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.