Comments on: Designing for Inaccuracy?

By: Andy Wager

Andy Wager — Fri, 29 Jan 2010 21:52:28 +0000

Interesting point about trying to be too specific or accurate. Designing without limitations can be incredibly frustrating, as can the opposite of designing so incredibly specific that when you get done you have something too rigid. Too rigid tends to equate to short life span and obsolete these days.

A challenge of getting specific/accurate is the loss in flexibility. And trying to “win” in a rigid structure often leads to negative outcomes as much as positives – bad decisions, poor judgement, speeding tickets, family members that hold it over your head forever. Or may in fact be the necessary focus thats needed to win, in which case its more of a question of how long can you win for?.

Maybe a change in thought process to the platform or framework level is what you’re getting at in the article? Maybe a poor example but Apple didn’t set out to create the perfect App, but they provided a platform/framework for which others could get really specific. The apps have the short life span, not the platform.

Platforms/frameworks demand a balance between accuracy and inaccuracy. Its tough to overcome the mental leap because there is an element of ambiguity that remains with being even slightly inaccurate. And as you correctly point out, we’re wired to win.

By: Eric Reiss

Eric Reiss — Wed, 09 Dec 2009 09:06:30 +0000

The easiest way to beat the clock is to turn it off. As most GPSs constantly adjusts the ETA, you cannot win. In fact, my Nokia GPS keeps telling me “Mind the speed limit” if I go too fast.

As to the Microsoft timing structure, I think this is more a “cover-your-ass” kind of solution than an accurate representation of the time needed. I suspect that Microsoft hopes you’ll have a happy surprise when the download goes faster than originally estimated. So this might be a UX thing, not a true metric.

By: Russ

Russ — Fri, 27 Nov 2009 07:52:43 +0000

@Joshua

I think you’re right–still rattling it through, but it seems like designing for inaccuracy isn’t the approach, but it’s the designing while presenting a way to feel like we’re winning, beating or even just somehow competing (or just some sort of “fun” goal in the mix) that can make the difference.

Thanks for that feedback; just the kind of kick I was looking for.

By: Joshua Kaufman

Joshua Kaufman — Fri, 27 Nov 2009 07:37:14 +0000

I completely understand where you’re coming from, but I can’t help but think that directly designing for inaccuracy is just wrong. We shouldn’t be creating systems that present inaccurate information just because we can’t find a better way of presenting it to the user. I think you’ve got something with the “winning” aspect. It’s about designing by using incentives and rewards. There’s no reason why the GPS can’t remain accurate and still make you feel like you’re making good time. And if you beat the time it predicts, well then you’re really on fire! Or what if you come up with a completely different way to get there? Bonus points!

By: Dennis Schleicher

Dennis Schleicher — Fri, 27 Nov 2009 06:18:21 +0000

Russ,

Beating the clock. When I used to drive back & forth between Detroit and Pennsylvania before the days of GPS, I used to keep my mind active by constantly calculated ETA to the Minute based on distance and current rate of travel. And the “beating the clock” goal was always top of mind.