Comments on: Foundation Series: The Difference Between Correlation and Causality

By: Roger L. Cauvin

Roger L. Cauvin — Thu, 18 Oct 2007 15:05:26 +0000

Well, at the root we want customers to buy our products. So we want to foster repeat business and positive word of mouth. But I don't think measuring those things lies in the realm of requirements. I generally recommend stopping once you hit a basic need (a la Maslow's hierarchy).

By: Scott Sehlhorst

Scott Sehlhorst — Thu, 18 Oct 2007 00:47:21 +0000

Thanks Roger!

I chuckled that you’ve defined a “hyphenated requirement.” Not disagreeing – just grinning.

Yeah, this usability measurement stuff is hard. I don’t know that we understand enough to generalize things yet – we have to anecdotally tackle the problems situation by situation.

Frustration is a tricky one. Hadn’t really thought about it before. Polling may be the only way. But as you say, it’s all about first principles – why do we care about frustration levels?

By: lightkeeper54.com » Blog Archive » The Difference Between Correlation and Causality

Wed, 17 Oct 2007 14:21:18 +0000

[...] Foundation Series: The Difference Between Correlation and Causality | Tyner Blain One of the most common mistakes people make when looking at data is to jump to conclusions about the data. We all live in a world of cause and effect. It is only natural that when we see data that appears to show cause and effect, we assume that it does. But it often doesn’t. This article shows the difference between cause and effect relationships and correlated data. [link] [...]

By: HR Measurement: The Difference Between Correlation and Causality » KnowHR Blog

Wed, 17 Oct 2007 09:40:36 +0000

[...] The words correlation and causation get flung around casually in some HR circles, which is why when I read this simple summary of both terms this morning I thought it should be required reading. Here’s what Tyler Blain writes in the opening paragraph: One of the most common mistakes people make when looking at data is to jump to conclusions about the data. We all live in a world of cause and effect. It is only natural that when we see data that appears to show cause and effect, we assume that it does. But it often doesn’t. [...]

By: Roger L. Cauvin

Roger L. Cauvin — Wed, 17 Oct 2007 02:48:20 +0000

Good points about the trickiness of measuring usability.

It’s true that, in some cases, we’re not so much interested in reducing time or effort for users as we are keeping them from being frustrated or from abandoning the session or product. Depending on user psychology, it’s even conceivable that adding steps to a user task could decrease frustration.

If we’re willing to commit to solving the larger problems, we can instead specify “frustration level” and “abandonment rate” metrics.

A frustration level attribute might constrain the frustration measured by a certain neural indicator (I call this “neurorequirements”). In practice, we might indirectly test the constraint by polling users about their frustation level.

An abandonment rate attribute is relatively straightforward to measure if set up a test with representative users and scenarios.

Either way, I like the emphasis on first understanding – and thinking about how to measure – the problems we’re really trying to solve.