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?
- Time and budget constraints
- Diminishing returns
- Deadlines
- 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?
- Delaying some features for a future release, or dropping them completely.
- 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?
- The first rule of design is that you should always throw out your first attempt. The governing reality is that you rarely can.
- 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.
- Sometimes the best way to get to “really, really good” is to go through multiple revisions of “good enough”.
- Accept the flaws of the final product. There is almost no construction of mine that I wouldn’t radically overhaul if I could.
- 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.
- “You can’t always make what you want, but if you try sometimes you might find you make what you need.”
