What is your UI debt?
When developers are up against tight deadlines they introduce the concept of “technical debt”. It is a short cut to delivery; quick and dirty code that will have to be refactored (or fixed) at a later date. Inevitably they will pay the price in the future if this is not done.
So why does no one talk about “UI debt?” When projects are up against tight deadlines and scissors are applied to scope, the first thing that the team will look to cutting are any UI “bells and whistles”. They don’t talk about UI debt – we’ll have to refactor (or fix) the UI at a later date. Yet the price to be paid for UI debt will inevitably be far greater than any technical debt. If the UI is hard to use, and satisfies the technical functionality, not user goals, the users are more likely to shun the software. And isn’t the object of software for people to use it?