Pay Down Design Debt with Polish Day

Spend enough time in any large app or website and you’ll discover interface design inconsistencies. This design debt accumulates as we ship new features, react to customer feedback and run experiments. Seemingly small details add up to reduce user confidence and trust. Debt can grow to an unmanageable size — unless you have a plan for steadily paying it down.

Anyone at Optimizely can (and does) submit polish issues to our design backlog. People typically include a helpful screenshot and short description about how to reproduce the problem. Once the issue is fixed a JIRA+git integration automatically closes the ticket when our changes land in production.

The Whack-a-Mole Problem

At Optimizely we struggled to address design debt. Designers and product managers were noting inconsistencies nearly every day and our backlog quickly grew to more than 50 issues. These issues are difficult to prioritize — most UI bugs seem small and insignificant when there are new features to ship and customers to please. We needed to focus, so we created a special day of the week to do just that: Polish Day.

Our list of issues including time estimates ($) where $10 is our smallest fix. We aim for about $100 worth of tasks each polish session, prioritized by the designers.

Polish day helps address these problems in three simple steps: 1. Create a list of the work to be done; 2. Prioritize together based on effort and impact; and finally, 3. Make time to focus and execute.

1. Fix Your Leaky Bucket

Before you start polish day, have a complete list of problems to sort. Design debt is a leaky bucket; an organized list can help you feel less overwhelmed about the steady amount of new things to fix. Gather screenshots and feedback in one place and make sure edits are actionable without additional follow-up. Anyone at Optimizely can file a JIRA ticket — designers, product managers and engineers author most of the polish queue.

High priority issues look broken and are fixed first because they are the most obvious and visible. The worst offenders are often elements that overlap (mostly resolved by storing CSS z-index values in one place) and text that doesn’t fit inside a layout (solved with CSS helper classes for text-overflow: ellipsis and flexbox). Problems include:

• Z-index or text overlap/looks broken
• Unreadable or unusable
• Bad empty state
• Unhelpful errors

Overlapping elements and text that doesn’t wrap or truncate looks broken to anyone trying to use this interface. This is a red flag to users that perhaps there are more issues ahead where quality is lacking and details were not considered.

Minor issues tend to involve spacing inconsistencies and include:

• Spacing and alignment
• Icon size and stroke weight
• Button padding, widths, margins

Subtle shifts in size cause users to pause and consider if this change was intentional. It’s your design debt, but it costs your users their time and attention.

Text is a pervasive issue because words are the core interface. Don’t underestimate the value of consistency in things like Title Case vs sentence case, or button text that includes a verb. Without words, users are lost in our interfaces, clicking cryptic icons and arrows. We must spend extra time ensuring a thoughtful experience that reads as well as it responds to input. Word issues involve:

• Title case vs sentence case
• Action-oriented button text
• Clear navigation and link text

Wordsmithing titles and button text is an important step to interface consistency — words are the core of our digital interfaces.

Pixel-perfect issues seem nit-picky but drives designers and power-users crazy. These are a rare category of issues by themselves:

• Hard to prioritize because they are tiny — sometimes just a pixel off!
• Subtle, but details matter

This is a great example of a detail that designers will most likely notice — the shadow with the red arrow is nearly a pixel off. A great user experience is about a holistic approach to design, one that considers the large and the small at once, and adjusts for trade-offs. Issues like this probably won’t get prioritized in a product sprint, but it’s the perfect momentum-building task for your polish queue.

2. Prioritize as a Team

Every Thursday, Product Designers and UI Engineers prioritize polish. The morning of polish day we talk trade-offs in time and execution. It takes fewer than twenty minutes to estimate the depth and potential global impacts of CSS changes and talk through pattern consistency. If more design is required before a solution is ready to code, we assign it to a designer. Then a price is set.

Designers and UI Engineers discuss issues in the polish backlog to fix later that day. This quick pre-polish meeting helps us organize tasks early in the day, then after lunch we have a long, focused block of uninterrupted time for the actual code fixes.

If you’re following an agile process then story points can be useful, but we wanted a more accessible way to estimate time, so we made one up! Designers get $100 to spend for the day. The money is fake, but the estimates are real and based on level of effort. Each ticket is given a dollar amount — tasks that take a whole day to complete cost $100 while our smallest ticket, like a tiny text edit, is $10.

Once priced, designers sift through the list of available tasks and come up with $100 worth of work for the UI engineers to complete after lunch.

3. Make Time

Some polish days have a theme like “account settings migration clean-up!” Other days are a random assortment of very visible or especially irksome issues. Typically everything can be completed that afternoon and deployed to production the next day.

Polish is a small commitment, but requires steady consistency. Make the time. A one-time session isn’t enough, but once-a-month might be enough. Stopping production to spend weeks on refinements is not reasonable, so instead make polish time happen on the regular.

Smallish Polish Adds Up

Our users notice details, even without being fully aware of them. We introduce subtle change which creates debt to be paid later. Don’t wait — pay the costs now by taking small steps. Each polish task can feel small, but the cumulative impact is big. Polish day builds momentum for your design team and increases morale as you celebrate a chunk of work that’s visible and impactful to the whole user experience.