Skip to main content

Posts

Showing posts from 2016

Making People Feel Stupid: A Cardinal Sin in Design

People will go to great lengths and inconvenience to avoid appearing or feeling stupid. A great example of when design makes a user feel stupid comes from Alan Coopers 1999 book The Inmates are Running the Asylum on page 24. Cooper is talking about the keyless entry system on his car keys. "The large button locks the car and simultaneously arms the alarm. Pressing the button a second time disarms the alarm and unlocks the car. There is also a second smaller button labeled 'Panic.' When you press it, the car emits a quiet warble for a few seconds. If you hold it down longer, the quiet warble is replaced by the full 100-decibel blasting of the car alarm, whooping, tweeting, yowling, and declaring to everyone within a half-mile that some dolt--me--has just done something execrably stupid. What's worse, after the alarm has been triggered, the little plastic device becomes functionally inert, and further pressing of either button does nothing. The only way to stop that ho

Hammers and Nails: Technology Push Design

"We need to refine our requirements first, before we look at tools." This is a common phrase that I hear. While I sympathize with the sentiment, I think it is frequently wasteful. I suspect that we'd get to the right requirements faster by looking at tools already available in a given problem space. Pushing the concept further, is it foolish to find a cool technology and then look for ways that that technology can apply to current problem spaces?  What if you don't even recognize you have a problem space? Without a constant search and openness, we'll miss many serendipitous opportunities. Here is BYU professor Larry Howell discussing this issue. I often enjoy doing something ... that is sometimes controversial. In this approach, rather than starting with a need, you start with a new technology and you search to identify a need that it can fulfill. This second more controversial approach is called "technology push design."   You can imagine t

The "True Cost" Phantom in Project Cost Tracking

I want to know if I should wear a coat when I go out the door on an unpredictable spring morning. The temperature from the weather app on my phone isn't going to match exactly the temperature just outside my front door, but it will be close enough to make the decision. If the question at hand is whether or not I should wear a coat, it would be a costly mistake to set up an elaborate system of thermometers around my property to try increase the precision of my measurement of the temperature. The added expense wouldn't yield any better decisions about whether to wear a coat, so why bother? We are interested in tracking the relative costs of the various projects we undertake in our organization. We must admit up front that we will never be able to measure the precise cost of each of our projects. Consider the following things you could include in the "true cost" measurement of a project. Where will you draw the line? An engineer reads an article on the bus that give