The Principle of Good Enough

Joshua Porter recently commented that “development processes .. aren’t always design-friendly”, that designers are “forced to work within schedules that aren’t always conducive to the way they want to work”.  This is a real problem for almost anyone doing intellectual work; generally, there are more unknowns than knowns at the beginning. Forcing unknowns into a predefined schedule and/or work structure can be maddening.

In the context of the everyday workplace, almost every design is compromised from the outset by time and resource pressures. This means that designing is often better thought of not purely as “solving problems” but as “solving problems in a certain amount of time without exhausting the resources available.”  This is antithetical to the way the many of us like to work, which is to have the time and space for tinkering, exploration, and inspiration to do something really, really good. We are routinely, and frustratingly, forced to abandon the “really, really good” for the “good enough”.

In the everyday workplace, the principle of “good enough” governs most of the time.  Why?

1. Time and budget constraints
2. Diminishing returns
3. Deadlines
4. Actual operation

Time and budget constraints

It is very, very difficult to estimate the time and effort needed for design, or most any kind of intellectual work. The two worst parts of many jobs are 1) developing estimates and 2) exceeding them. But that does not mean estimates aren’t important and necessary most of the time. An organization has to have expectations and limits or it cannot function. Frank Lloyd Wright could badger his clients to cover the cost of massive overruns for the sake of an ideal result; most of us can’t get away with that. When hitting the budget ceiling, something has to give and a good percentage of the time, it is the project, not the budget. Short, agile development bursts - great for adjusting design along the way and reducing the risk of large overruns - can actually exacerbate the issue by adding the number of constraints placed on project members over the project lifetime and creating mismatches between time allocated to a task and time needed to complete it.

Diminishing Returns

Working on the last 10% of one problem is often less important and/or less productive than working on the first 90% of the next one.

Deadlines

Deadlines are often more important than perfection. For example, it is generally preferable to have a good product on the shelves in time for the holiday season rather than having a great product released afterwards (the Kindle Fire release of late 2011 - full of glitches and design compromises - is an excellent example).

Actual operation

No matter how diligent the process, a good number of design strengths and weaknesses will not be revealed until after a product is released for use. A productive strategy for many products is to simply “get it out there”.  “Beta” testing is formal acknowledgment of this practice of “good enough”.

What does good enough look like?

1. Delaying some features for a future release, or dropping them completely.
2. Meeting requirements instead of exceeding them, or downgrading existing requirements. For example, getting a working registration page up on a web-site might be a “good enough” requirement, even if a more desired goal would be a registration page that successfully converts a designated percentage of visitors.

So what does this all mean?

1. The first rule of design is that you should always throw out your first attempt. The governing reality is that you rarely can.
2. Limits aren’t necessarily a bad thing. Five “pretty goods” may be more productive than one “really, really good”. Sometimes, perfection is the enemy of good.
3. Sometimes the best way to get to “really, really good” is to go through multiple revisions of “good enough”.
4. Accept the flaws of the final product.  There is almost no construction of mine that I wouldn’t radically overhaul if I could.
5. Accept, critically but respectfully, the flawed work of others - because we understand the constraints thrust upon them, or more commonly, because we don’t know the constraints thrust upon them.
6. “You can’t always make what you want, but if you try sometimes you might find you make what you need.”

Similarity confusion

Similarity confusion

When a user mistakenly initiates the wrong operation because objects with different functions are presented in a like manner.

Design flaw in iTunes that produces similarity confusion (see picture below)

Two controls are presented in a like manner:

• Controls are side-by-side.
• Controls are "sliders", operating in the same manner. A user drags the button at the end of the line to the right or the left to change the state of the current podcast.

The controls have very different functions:

• The left-hand control manages volume.
• The right-hand control manages placement within the podcast (beginning, middle, end).

Unintended result

I, several times a month,choose the wrong control and manage to lose my place during a podcast session when my intention is to alter the volume.

Solution

The solution is to change the manner in which one of these controls operates. The questions are: which one and how? In this case, screen real-estate issues aside, the nature of the operations helps present suitable answers. When presented with a song or a narrative, we think linearly. A horizontal line - a time line - is a natural way to present something that has a beginning and middle and end. So, the placement control can stay as is. We tend to think of a volume in a different way.  We think of louder as more, softer as less. Flipping the volume slider from horizontal to vertical gives us a natural analog of higher=louder and lower=softer, which a stronger correlation than right=louder and left=softer.

A volume control like this one from Microsoft Windows (sorry Apple) would eliminate the similarity confusion created by the current iTunes interface. [Note that this volume control, like many others, uses both height AND width to marry visual volume - overall visual size- with audio volume.]

Take advantage of the hand

Remote controls for TVs, DVRs, and DVD player are often used in low light. Typically, I like to watch movies in a darkened room. This means that a well-designed remote is one that provides non-visual cues. See the picture below. Which is the better shape? The one on the right; it widens at the top. By feel alone, one can position the remote in one's hand correctly.

Form obliterates function

The reigning chic in kitchens seems to be large stainless steel panels. That's OK, I like the look myself. But what happens when the tyranny of cool won't accommodate a blemish? You get an appliance that is very annoying to use.

Look at the beautiful, sleek, clean, and simple front panel to a KitchenAid dishwasher - marred only by the brand name (of course) and (heaven forbid a useful visible object) a handle - and ask yourself the question: "Is it on?"

I answer that question routinely, by accidentally opening the machine up in the middle of a cycle and uttering a string of unmentionables.

To start the dishwasher one opens the door, pushes the start button on the control panel that is only visible when open, and closes the door.

Is it on? How soon will it be done? The best you can do is bend to the height of dishwasher and look for LED lights in the 1 inch gap between the top of the door and the underside of the counter. Information that should be instantaneously conveyed requires body contortions and the interpretation of lights whose labels are, at that angle, invisible.

Many years ago I visited a trendy Manhattan night spot. I've long forgotten the name but not the bathroom, which was the height of hip. Everything was hidden - urinals, the doors to stalls, spigots (this was long before hands-free faucets). It may have been a beautiful, stylish room but what is the most important thing about a bathroom?

"USING THE BATHROOM" or possibly "USING THE BATHROOM"

Solving puzzles is not what you want to be doing when feeling the call of nature.

Staring at a blank door is not what you want to be doing when wondering if your dishwasher is still running.