Why MIR Researchers Should Care About User Experience

I’m at NYU for a couple months to conduct a rather large user study on an interface that I’ve developed. I talked about my PhD work and my current work with a gathering of PhD and MS students last week. I’ve included my slides below, though we didn’t really go through them. It’s an updated version of a talk I gave at a couple universities last autumn.

On a related note, if you look around and find that it’s June and that you seem to be in New York, why not contribute 2 hours towards science? You’ll even get a shiny $20 bill in return. Go here for more information.

Some good discussion ensued and it helped me solidify my own thoughts, particularly as to why MIR researchers should care about user experience. To people within HCI or UI/UX or design fields, to not consider the end user seems like a ridiculous notion, but it’s unfortunately an issue that’s only beginning to be addressed.

I talked with a couple researchers that are working on an interface for a library’s music collection. As we discussed ideas and played the game of “oh, have you heard of ______, let me google that and find it for you,” it was admitted that they didn’t actually know why or how users use would the interface they were creating. They didn’t know what are the most common tasks that a patron of the library’s music collection is trying to accomplish. They said the librarians weren’t even sure. One of the researchers I was speaking with said that in his undergrad he spent a lot of time on ethnographic study and user-centered work, but that the work he was doing now was much more focused on the engineering. Unfortunately, I think that means that they’ve developed a piece of software that might not be useful to anyone.

If every researcher has a platform that they like to shout from, these are the main placards I would display around my soapbox:

  • The data should not dictate how people interact with that data, people should dictate how people interact with that data. My pet peeve is that just because you can project a multidimensional timbre space onto two dimensions doesn’t mean you should. At the very least you shouldn’t force a user to interact with it.
  • Don’t kill new products by letting the first release be your first user testing. Genius had negative reactions when it was first released, and I don’t think I’m the only person that abandoned it after some poor recommendations. Google Music is now facing very public discussions of poor performance that perhaps could have been addressed through some private studies before a semi-public release. If something doesn’t work right away for a user, then you may have lost them forever.
  • Users can tell you which 1% problems to focus on. If the end user can’t perceive any difference in the 1% increase in the performance of your algorithm, perhaps it was a wasted effort. There could be a 1% increase in another aspect of the system that would actually improve the system as a whole.

My current work is attempting to address how a small collection of music (e.g. a list of search results returned from a query) can be best presented to a user. I’m doing this without considering a specific MIR backend – I want to separate how the user interacts with the data from how that data was collated. It’s a very specific use case, but because of that I think it’s one that can be easily improved. I’ll certainly be posting more about it as the work is completed.