The Perils of Reverse Context

Once in a while, you need to come up for air.

I am one of only a handful of Asians living in my small Northwest Indiana town. In fact, there are very few minorities at all in Crown Point, Indiana (the town made famous by John Dillinger and his soap gun). There are many bizarre situations one encounters when one is a yellow M&M in a sea of Tic Tacs, and most are hilarious rather than malign.

Feeling lazy as the sun set on a hot August evening, I decided to order Chinese takeout. I didn’t even want to drive the half-mile to get there, but sheer hunger motivated me to get in the car. Apparently, a few other miscreants had similar ideas; there was a bit of a line at the register. After about 15 minutes, I got to the head of the line and paid for my food. As I turned around – food, wallet, receipt, and keys in hand – the woman who had been standing directly behind me in line for a quarter hour looked up and exclaimed, “Dammit! I didn’t know they delivered!”


When designing a system, be it site navigation, applications, or even supply chain, it’s important to look at established standards with fresh eyes. Iconic “best practices” can easily lose relevance or context when introduced into a cutting-edge system or unintended environment. Usually, though, these issues appear as a result of what I call reverse context. Here’s a short example:

When I worked as a contractor, I was tasked with building (I was “building” because I was billing under $50/hr…at $100/hr, it becomes “architecting”) the flow for a system that would, at a very high level, pick out issues in data for vetting.  It was a very large system, and after the first pass, I had 8,000 business and technical requirements. And no, it could not be broken down into its constituent components. Obviously, I relied on a lot of standards – ISO/IEC is your friend, believe it or not.

One requirement concerned the mandatory presence of a human being to view each record. This is how the requirement decomposition meeting went:

Me:  So this requirement says a person needs to eyeball each questionable record.

Suit: Yep. To make sure it’s not an obvious false positive. People are real touchy about false positives.

Me: Makes sense. But it will reduce performance from 3000 records per second to about 1 per second.

Suit: Well, wouldn’t you want a real, empathetic, live person to make sure your data wasn’t falling through the cracks or unjustly scrutinized?

Me: Sure. Good point. So what can the person do if they detect a false positive?

Suit: They can send it along.

Me: What?

Suit: They can send it along…nothing else.

Me: So all they can do is hit send? And this will reduce throughput by a factor of 3000?

Suit: Yes.

Me: Why would you do that?

Suit: It’s a requirement.

Me: Why not let the person at least divert the questionable record or reject it?

Suit: …That’s not a requirement. Anyone want sushi?

In flow diagrams, having a person in meatspace as a gatekeeper looks funky and sexy to clients (particularly to bureaucracies with exposure to the consequences of public perception). As a requirement, it’s hard to imagine removing it in any case, especially with sensitive data. But when context is reversed and one realizes that, due to poor requirements, the person could effectively be replaced by one of those little bobbing drinking birds hitting a mouse button, it becomes clear that the road to Broken UX is paved with orphaned requirements like this.

Whether you have a statement of work scrawled on a napkin or thousands of requirements in Rational, a good UXA will look at each requirement both individually and holistically. Just because some button is in the same place on every site doesn’t mean that it should be that way on your wireframes.

View every element both in and out of context, or you may mistake a continue shopping button for the delivery guy.

Tags: , ,

One Response to “The Perils of Reverse Context”

  1. TomE →
    May 10, 2012 at 1:44 am #

    Am I a tic tac in this analogy?