The Extra Mile

At any given time in a software project—between design and implementation—there is usually three types of work going on: feature development, bug fixing, and polishing.

Feature development and bug fixing are our bread and butter. They keep the product both fresh and reliable. Polishing, on the other hand, is about taking that extra mile to delight your users—a layout improvement, a meaningful animation when you finish a task, a helpful message that anticipates your next steps, or even a whimsical Easter egg.

Polishing is this continuous act of refining your user experience down to the smallest detail. It is what might ultimately set your product apart from crowd—it is your special sauce.

We all aim to deliver polished products, of course. But as it usually happens with software development, this is much easier said than done. The road between those beautiful design mocks and the product release is a bumpy one. The end result very often diverges from the intended design.

It’s not that we don’t want to take that extra mile. It’s not that we don’t care. It’s just that getting there is hard. Why? The answer to this question—or at least part of it—has something to do with time and priorities.

A solid collection of refinements can greatly affect the perceived quality of your product over time.

Polishing is in the realm of important issues which are not necessarily critical to the product. When taken in isolation, they look harmless, or even frivolous.

So it is very easy to get into a situation where polishing is continuously postponed because, well, there is always something more urgent to work on such as a new feature or a critical bug.

A good first step towards avoiding that is realizing that polishing is inherently systemic. One small alignment fix in the UI might not make a big difference. But a solid collection of refinements can greatly affect the perceived quality of your product over time.

So polishing has to be deliberately pushed into your development agenda as this is unlikely to happen organically. It is important to set your priorities in such a way that you’re tackling urgent matters (e.g. feature development and bug fixing) as soon as possible but, at the same time, always refining what your users have in their hands at the moment.

For a concrete example, see Medium’s Jank ‘n’ Drank weekly sessions:

The motivating idea behind Jank ‘n’ Drank is that “critical activities,” by nature of being essential to product performance, will necessarily get done, but “important goals” can languish indefinitely at the back of your mind and the bottom of your to-do list. Jank ‘n’ Drank is all about important goals.

The Jank ‘n’ Drank sessions are a deliberate effort to keep important goals—UI polishing included—on the team’s radar.

Set the bar too high and you’ll ship too late. Set the bar too low and you’ll be shipping a poor product.

It is a common misconception that UI polish is just about performing quick and easy fixes here and there. Not all polish issues are created equal though. Getting details right can be very time-consuming.

Take motion design, for example. Suppose you want to refine a screen with a transition that makes the interaction with the product a bit more intuitive. It is quite common for an animation to look fine on specs but fail to deliver a good experience in the real product, requiring extra iterations on the design. Furthermore, implementing UI transitions often involve non-trivial code refactorings in order to accommodate the new behaviour—which are likely to introduce new bugs.

So, polishing takes time. But the real danger lies in its open-ended nature. There is always something in the product that could be refined a little more. There is always a tempting extra mile ahead—one that can take you further and further away from shipping.

There is obviously no silver bullet for delivering polished products effectively. It’s a tricky balance to find. One that not many teams get right. Set the bar too high for your UI and you’ll ship too late—or never ship at all. Set the bar too low and you’ll be shipping a poor product.

Most of us can’t afford to have longer development cycles, with extra time for refining the product over and over. So maybe the secret is in keeping development cycles short and focusing on less to go deeper into all those nice little details that are not strictly necessary but contribute to a delightful user experience.