> Theoretically, there shouldn't be any such thing as technical debt either, though, right? But then again, the repayment of technical debts might be a good way of distinguishing "done" for a release, from "done" for an iteration.
> Interestingly, the timing for repayment of a ux debt has to be different. Refactoring the design in a prerelease iteration, say, will only get in the way of refactoring code, right? So you can really only repay ux debt in the next release.
I don't think that's necessarily true.
For a start there are environments where the distinction between story-finishing, iteration-finishing and release-finishing aren't distinct in that way (e.g. continual deployment).
Second - if I am in an environment where there are several iterations between releases, there is no reason I can't address a ux debt I took on in iteration N in iteration N+2 before we release in iteration N+4. It just depends on the team's priorities.
Thirdly the relation between the code design and the ux design is a complex one in my experience. Sometimes they're highly interdependent (and a bad ux design often implies a bad code design - and vice versa). Sometimes bad ux issues are trivial fixes. Sometimes trivial ux tweaks are terribly hard (often because of the wrong code design). It's tough to make generalisations.
Finally - Uncle Bob's recent post on technical debt comes to mind:
I think there's a useful distinction to be made between a ux debt that is taken on mindfully vs. bad design that people just let happen through not having UX folk involved. The latter often involves a lot more work.