“Design polish” is ruining your software. All those details that are being de-prioritized and placed in the backlog are the leading indicator you aren’t delivering magical user experiences. They also indicate your team would rather ship incomplete design than miss a deadline. They indicate that the small things don’t matter to your team, that craft is not a priority and that the most outward appearance of your software’s quality should be ignored.

“Design Polish” is a phrase that shouldn’t exist in any development/product/designer partnership because it immediately degrades the relationship between the team by trivializing the discipline of design.

Believing in design “polish” is another way of saying “I don’t care about design” because it brazenly and incorrectly relegates visual design as ornamentation. It places more emphasis on technical function instead of holistic customer experience and usability which is the form and function working harmoniously.

“Design polish” is ruining your software because it gives your team an excuse to ship unfinished work. It encourages them to accept the incomplete implementation of design and place items in a backlog that will not be picked up.

Would you ship a product that is knowingly missing 12 lines of code? No… no, you wouldn’t because it could potentially break the experience.

Would you ship a product that is knowingly missing 12 lines of code? No… no, you wouldn’t because it could potentially break the experience. That is what you are doing with design polish in your backlog — breaking the user experience and affecting the usability of your software.

You can turn this around. You can ban “polish” all together. You can do this by implementing design QA, not accept user stories into a sprint that do not include specifics, encouraging better relationships between Dev and Designers and leading through example.