There’s something to be said for the ‘just ship it’ mentality, where you focus on core functionality and get it out the door and in front of eyeballs. But the often-neglected skill is going back to what’s been done and adding those subtle bits of nuanced UI improvements.

When I’ve been working on an interface and catch someone using some aspect of it that wasn’t explicitly explained (and, as is often the case, was never directly asked for) because they inherently thought it would make sense and just sort of expected it, I love that. Or if they didn’t expect it but were pleasantly surprised to find it already there when they needed it, even better.

Paying attention to small details is something I’ve always done. Even when reading a book from a seasoned author, if I find a typo, I let them know about it. Similarly, I try to develop and encourage that type of behavior in new/junior team members as well. Do the field names match the modern jargon or do they use older/deprecated names? Is there anything visually that seems out of place, like a difference in font or alignment? My general philosophy on that sort of stuff is that if I notice it, someone else probably has (or will), too. And even if they aren’t consciously aware of it, I’m just they are at least slightly aware of it on some level… A lot of it comes down to judgement calls, which is often a weak area for less-experienced team members. But making the wrong choice and learning from it is a much better way to gain experience than just doing nothing (or simply being oblivious to it completely).

Ideally, every project or task being done should be treated like it is the only thing you will ever be judged by. Even the most boring and tedious of projects can be made more interesting and challenging that way.