How do you know when a design is done?

It’s usually pretty clear when you are not done with a design, but how do you know when you are done? The need for releasing at the right time is clear. Releasing a product in a timely manner is crucial to success—the least successful products are those that release outside their window of opportunity—so your design completion criteria must be release-friendly.  On the other hand, the days when you could release a half-baked “good enough” product successfully into a competitive market are long past.

One way to weasel out of declaring your product finished is to release it unfinished as a “Beta.” Doing so lowers customer expectations and provides an obvious excuse when those lowered expectations aren’t met (“What did you expect? It’s a Beta.”) Some companies have a habit of labeling their products as Beta seemingly indefinitely (called “forever Beta.”) I’ll let you draw your own conclusion about the long-term viability of this approach.

My “design complete” criteria

There is no universally accepted list of criteria, but here is what I like to use:

  • Basic functionality works as expected, doesn’t crash or lose work. This one is pretty basic and obvious.
  • Product users tests well for core scenarios. User testing is the “gold standard” for evaluating a product. This makes sense—after all, we can debate all day if a design is good, but the only way to prove it is if target users are able to perform their tasks successfully. But on the other hand, all user testing ultimately proves is that a product “does the job.” Successful user testing doesn’t necessarily mean the product is good or that users will like it or prefer it over the alternatives.
  • Project goals are achieved. Does the product provide value to its users (especially when compared to the alternatives)? Does it achieve the objectives of the release? Does it solve the problems the release is intended to solve?
  • User mistakes and other problems are rare and easy to correct. This criterion addresses a frequently overlooked aspect of user testing. You can user test for mistake and problem recovery—although people rarely do—but the key is to make sure problem handing is designed in. A design that’s hazard-prone isn’t ready for release.
  • Product upholds design principles and guidelines. The design reflects the established elements of good design and has the consistency required to be “intuitive.”
  • Problems are hard to find. Is quality obviously there? A product doesn’t have to be perfect—successful products always ship with known problems—but those problems should be rare and hard to find. If problems are easy to find, you’re not done yet.
  • Worthwhile improvements are hard to find. Throughout the process, you will get feedback and suggestions to improve the product. Some will be outside the scope of the current release, so those should be postponed (increasing scope is a rookie mistake and not release friendly). But within the scope, there should come a point where most proposed changes make the product different, but not obviously better.

(BTW: This list is in order of fundamentals—most fundamental first. And while the entire list can be applied as release criteria, appropriate subsets can be used as exit criteria for preliminary phases.)

I expected some readers will think this bar is too low, others too high. If there is a reasonable balance between the two, I’ll consider that a success. For those who think this bar is too high, I’d like to explore a few ideas.

Perfection isn’t release friendly

While it should be difficult to find obvious problems or improvements in a quality product, that’s far from trying to be perfect. As Voltaire once noted, “The best is the enemy of the good” and this classic battle often rears into release criterion discussions. People will say “We don’t have time to be perfect!” Absolutely true—nobody does. But that’s irrelevant because perfection isn’t a goal. Don’t let the inability to achieve perfection be an excuse to lower your quality bar.

Avoiding lateral movement: a huge time saver

I’ve seen teams waste an incredible amount of time during the final project phases trying to address feedback by making changes that fall in the “different but not better” category. I believe this is a symptom of lacking confidence, which in turn is likely due to a weak design process. If you consider several design alternatives during the design phase and use user-centered design techniques as a decision making framework, you should have enough insight and confidence to recognize “different, but not better” design changes late in the process. Don’t waste your time with these—they will consume a lot of time but get you nowhere.

Culture is a factor

Some project managers live in fear—terrified that their career will be harmed if they don’t incorporate all feedback, especially feedback coming from management. This fear is not without reason. In some team and country cultures, what the boss says goes—regardless.

When I was at Microsoft, everyone was terrified of executive design reviews. One particular senior executive had a reputation for being obsessed with minor details that had nothing to do with goals of the design review (he had a unique talent for finding text his mother wouldn’t understand). As a result, people preparing for these exec reviews spend a significant portion of their time crafting their presentation to avoid getting his feedback. Not a healthy sign.

Managers can really help here by explicitly communicating how the team is expected to handle feedback so that everyone is on the same page. During reviews, executives should clearly distinguish mandatory tasks from unimportant, off-hand remarks.  While it’s important to take all feedback seriously and perform due diligence, nobody should worry about their career being harmed for trying to do the right thing.

If you do only one thing:
Set criteria to determine when you are done with a project. Strive for high quality in a release-friendly manner. Avoid wasting time on changes that make the product different, but not better. Managers should set clear expectations on how feedback should be handled. Executives need to be clear on what feedback people really need to follow up on.

The comments are closed.

For more information, please contact

All Content Copyright © UX Design Edge