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)?

  • 6
    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. – Majo0od Dec 19 '17 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. – Andrew Martin Dec 19 '17 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 Dec 19 '17 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 Dec 19 '17 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. – Andrew Martin Dec 20 '17 at 9:17

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

  • 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 Dec 28 '17 at 7:49

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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