In software projects, whether they be waterfall or agile projects, there is a development lifecycle of some form. For Agile projects, usually, these lifecycles are broken up into tiny versions of the waterfall model.
At some point before you're release, what you need is a feature freeze. No more new features will be added to the release. This means design improvements, additional features, and you must hold all stakeholders accountable and be prepared to say "no", even to the client. Don't actually say "no" though. Instead say, "We are planning to implement that for you in the next release. We want to stay on target for release 1.0 and want to be sure to provide you with a quality deliverable."
With that said, this is then your time to focus on bugs. Again, bugs aren't new features, and bugs aren't design improvements.
However, bugs are defects in the software that were introduced that were not part of the spec, and the spec includes both functional bugs as well as bugs in the usability of the software or the designers original design.
First, consider that part of a Web designer's job is to think about how the user is going to interact with the software. The best designers put quite a bit of thought into every minute visual detail, and they engineer the user interface the way they do for a reason. Their goal is to make people want to use the software, and I've personally seen the same product sit stagnant, with poor usability, or throttle its number of users into the stratosphere with good attention to detail.
In my experience, developers don't always see this perspective clearly and sometimes don't implement the UI correctly. Therefore, it's up to the project manager to work with the team (designers and developers) to determine what the highest priority is for the immediate bugs, the ones that must be fixed prior to release, and the bugs that, when fixed, will help ensure success of the release.