Pits of Success

The Pit of Success: in stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our platform and frameworks. To the extent that we make it easy to get into trouble we fail.

—Rico Mariani, MS Research MindSwap Oct 2003.

For anybody who has designed a system, it can get really annoying when users turn around and do really dumb things with our designs. It can be frustrating, especially when we have made our design perfectly clear (in our minds). I often overhear arguments between some of the programmers around me and our customer about this very thing. (Programmers arguing with the customer—topic for another post.)

One of my big pushes at work is to change the way we view our software. It is very easy to put blinders on and just get the job done. We deal with a lot of very pertinent aircraft data and messing that data up has major consequences. As this system was started in the 70s using COBOL, there was not a lot of screen real estate. As such, there are times when a field on the screen serves double duty, but only has a label for one of its jobs. An example is a date field on one of our screens. It can house a date, or the user can input a command to increment the count in a field next to it. Needless to say, if I find the whole thing confusing and I have access to the programmers and source, I can't imagine how hard it is to be a user.

I have getting into the "Lean Startup" movement and found a term used in Toyota's Lean Manufacturing process: Poka-yoke. It exactly describes my argument for making user screens easier to use and more intuitive. Gone are the days of needing 500 disparate fields on the screen because it is easier than creating a new screen altogether. Much like in writing code, our user interaction points need to have low coupling and high cohesion. I am, by no means, a user experience expert, but if the same situations arise where users are incorrectly using our systems, it is usually because of poor design, not stupid users. We should aim to develop our systems such that users find themselves walking in the pit of success rather than walking a tightrope trying to avoid our mistakes.