10

It seems like the concept of tech debt is very familiar among developers and programmers but when it comes to research we are still struggling to understand how to avoid a similar problem that arises from doing too much research too quickly without having an overall objective and defined process.

Are there other references and case studies about research debt other than what I have seen written in a different field and my own thoughts on Medium (I mean there are but I am not sure where to find them)?

Improve this question
9
  • 7
    I think also something I've noticed is UX designers take any form of research as gospel without understanding context and how products vary in need. This could also contribute to research debt. Especially when new findings come out that might "nullify" previous ones.
    – UXerUIer
    Commented Dec 19, 2017 at 2:11
  • 1
    If I'm working in for a closed group of users then asking them what they want to see in a new version often only yields an image of what they're currently using. In these cases I will make assumptions about what I think is best practice and go ahead with building a prototype. At this point my assumptions need validation through testing - this validation could be considered "research debt" that needs to be carried out to ensure the product works for it's users.
    – Roux Martin
    Commented Dec 19, 2017 at 8:44
  • What kind of research are you talking about? Some discovery research is done in order to determine overall objective and process.
    – Ken Mohnkern
    Commented Dec 19, 2017 at 14:40
  • @AndrewMartin, that's why we don't ever ask users what they want. I've found it to be more useful to observe users' current processes, goals, and tasks and design to support them.
    – Ken Mohnkern
    Commented Dec 19, 2017 at 14:46
  • 1
    @KenMohnkern perhaps I explained myself in the wrong way - I was talking about researching user needs. For a product with a closed user group (like an in house staffing system for instance) it's difficult to research user needs without ending up with an outline for a product that just reflects the current working patterns regardless of how broken those patterns may be.
    – Roux Martin
    Commented Dec 20, 2017 at 9:17

1 Answer 1

Reset to default
11
+25

To understand debt in UX research, please take a look to some detailed articles about UX debt. I liked this explanation of UX debt, found on "The 3-Step Guide to Erasing Your UX Debt":

If your product suffers from inconsistent behavior or performance, you’ve probably made long-term sacrifices for short-term gains. You’ve accumulated UX debt.

When it comes to UX debt, you won’t know all the answers immediately. And you probably won’t fix it all by the next release. But that doesn’t mean you should give up. If you can create a plan that doesn’t give product management a heart attack, you will eventually eliminate your debt.

Another article about UX debt that has some good points is Juggling Growth and Usability: A UX Debt Primer.

Other resources:

UX debt - image from UX Debt in the Enterprise: A Practical Approach enter image description here

Update: A New article that could help, on Nielsen Norman Group: UX Debt: How to Identify, Prioritize, and Resolve

Improve this answer
1
  • 1
    +1 I am more interested in the research debt incurred in most of the UX related projects I have been involved in rather than UX debt because it encompasses issues with research, design, prototyping and testing so it's not an easy topic to cover. However, these are good references and I will have to look :)
    – Michael Lai ♦
    Commented Dec 28, 2017 at 7:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.