This is something I struggle with thinking about too as the founding designer, and generally most quality-driven person, at our company. The simplified version of the spectrum as I see it is:

    1. Shipping quickly with a shitty solution.
    2. Shipping slightly slower with a polished solution.
    3. Shipping very slowly because minor details took over.

The frustrating thing is I can generally feel the difference between #1 and #2 myself, but I'm not sure how to distinguish between #1 and #2 enough to argue my point to the rest of the team. Instead I usually have to result in vague responses about quality and reputation and such, or just go into the UI or codebase and tweak things myself.

But on the flip side, I also know that I bring up issues that, at first glance, I think are must-haves for quality, but really aren't. Instead the scope should be decreased not to include the feature at all. But my credibility each time I bring up something like that is diminished, rightfully so.

I often struggle with this when giving friends advice about their MVPs too. Everyone has gotten so wrapped up in MVPs and they equate the MVP to throwing quality out the door, but MVPs are much more about throwing away scope in my opinion. I actually think quality can actually break or break an MVP, but it's hard to convey this properly to non-design-focused founders because they might not see the difference between certain purely-aesthetically-driven decisions and the more general and important product-quality driven decisions.

We built the Segment.io MVP in two days, but we did it by cutting scope, not quality. We didn't have a settings page, a way to delete accounts, a way to reset passwords, a way to invite teammates, anything that seems like it's necessary to work on a project. We literally had:

    1. A junky home page.
    2. A login page that literally just two inputs and a submit button.
    3. A signup page that was similar.
    4. *The* product page that was a glorified settings form.

Instead we spent that time making sure the core form in the product was as helpful and simple to understand as we could make it. There was an animation that we added when turning an integration on that was completely unnecessary from an MVP standpoint, but it was one of those quality things that made it super obvious how the form worked, and added a touch of polish to the product.

Obviously this is completely anecdotal, so I have no idea what would have happened had we went the other way, but I do really think that some of the things we spent time getting right had an impact on our user's perceived quality of the launch. I'm not sure how successful we would have been had we not done that.

There's a really good article[1] by Ryan Singer (from 37signals) on this topic that argues that it basically boils down to scope. And we've found this to be really true for ourselves while working on Segment.io. Basically you go with the designer's (or close to it) opinion on what quality should be, and the way you reduce time taken to ship a feature is to drastically cut scope. It sounds way easier than it is, but I think finding ways to cut scope is easily one of the top 5 things I've learned since starting the company.

And Ryan also has another good article[2] about how to cut down on design time by focusing on capability instead of styling. I think he's right there, style in the early stages (while important from a first experience point of view for your users) only need to be "good" not "great". Basically most designers can pretty easily decide on a style pretty quickly for an MVP and then execute on it, whether it's amazing or nt. But capability should be paid more attention to because that is where things like "did this solve my problem?", "do I want to share this with my friends?", etc. come into play more.

I don't know if that helps at all, but I'd definitely love to read more people talking about this.

[1]: http://feltpresence.com/articles/9-what-happens-to-user-expe...

[2]: http://feltpresence.com/articles/18-ui-and-capability