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?
I see the best solution to this is to be including user testing for every iteration. If the user test fails, there’s no argument. There’s a lot of argument if UI decisions are made based on opinion.
My pattern for dealing with this is to make UI debt technical debt. Don’t talk about it separately – otherwise it can get prioritised badly.
Also – UI debt is often a symptom of more traditional “technical” debt. If the UI is hard to fix that probably means the code is missing the abstractions that the UI represents.
Oye.. stop pinching my thoughts..lol !!
Phil Crosby’s definition of quality is very much prevalent in the software world – we set out to satisfy requirements as a mark of quality. The world has moved on since then.. but you can still see the remnants of this whenever we talk about either the project requirements or usability.
Usability is not a condition to be met, it is a differentiator.
Also, I think the proper term to use here is not “User experience debt” – but “User experience underinvestment”.
[…] dancingmango » What is your UI debt? (tags: toblog usability UI agile softwaredevelopment process) […]