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.]