You're designing a web page, building a table or painting your house. Whatever the task, it's tempting to focus on a small part of it until it's as good as it can be and while this might be possible in some cases, a lot of the time, it's unrealistic to always expect a flawless end product. Often, the key to realising a task is done isn't so much about it being perfect, but "good enough".
This mentality is what separates perfectionists from shippers, a comparison I've borrowed from a TechCrunch article on getting people to do what you want. But I'd rather look at how you can improve your own productivity by teaching yourself to stop a task and move on when it reaches that "good enough" stage.
"Good enough" doesn't inspire confidence, I know. It suggests a phoned-in or half-hearted effort, a lack of enthusiasm or work ethic. But that's exactly what the perfectionist in you is going to say and it's this persistent nagging by your inner muse for an impeccable performance that will trip you up. Really, it's the pragmatist you should be listening to.
It's important to understand that in this case, "good enough" is not synonymous with "average". You can work on something until it's functional, serving the purpose it was intended for but missing some bells and whistles. You can move onto the next task with the intention of coming back later to polish. It can mean delegating the task to someone with more time or experience, when the opportunity arises. It's realising that your task will often be one part of a larger project, and by trying to get it right the first time, every time, you're actually compromising the productivity of others by eating into their time. This last point I feel is the most important.
I worked as a game designer for two and a half years where these demands were constantly in conflict. Obviously, you want every game mechanic, every level to be perfect but, with milestones to meet, budget constraints and other people waiting on you so they can get their piece of the puzzle done, you don't have that luxury of endless tweaking. Ultimately, you have to find a way to do your best work in the time provided.
A solution on one project I worked on was to break up level design into two parts — the greybox (rough layout) and polish stage. It sounds straightforward, but knowing that you'll have a second chance to get things right means you can focus on getting the core parts done — the gameplay and pacing, say — and then nailing power-up and enemy placements later. In the time between these stages, artists were able to place textures and correct visual inconsistencies, while the designers moved onto another level.
In software development, a "vertical slice" of the product is a common request, and is essentially a way to see all the elements of a project — in rudimentary form — working in concert. I'd suggest this approach to any project with multiple components — get the framework or skeleton up or running with all the pieces plugged in. Suddenly, it's easier and faster to spot problems that would be obscured by passing a critical eye over the individual parts. You'll also be able to better judge how long each part will take, based on how long it took to get the basics going.
Being a "shipper" requires good time management, multitasking abilities and the capability to make that "good enough" call. It also means understanding that the phrase means many things depending on the situation. It's not a cop-out, just a realisation that we don't live in a perfect world and doing the best job you can in the time provided and delivering something usable at the end is better than turning up with nothing at all.
How To Get People To Do What You Want [TechCrunch]