We have a problem at work. A few years ago, everyone in the team spent several hours each week talking with our users. This might have been at our offices or, if we were lucky, it was out at theirs. This 'talking with users' wasn't completely aimless, but it wasn't strictly structured either. We wanted to find out about their work and about their life. About their typical day.

This open-ended, conversational research gets called many things. At GDS it's 'Discovery'. Where I work, it's called 'Customer Discovery. Whatever it's called, it's about identifying opportunities, finding unmet needs among potential customers. As Cindy Alvarez says in Lean Customer Discovery: "find out what customers need and what they're willing to pay for". What are the pressures, challenges, and emotions that customers have in their day. What are their 'Jobs to be Done'?

The problem we have at work is that we're not doing this so much anymore.

That's not to say that we're not talking to users, though: We're a good product team that reads the right blogs and the right books and thoroughly believes in a user-centred product development process. We have a research lab in the building and talk with our users all the time. The problem is in what we talk about.

Instead of talking about their problems and challenges and emotions, we talk about a thing we're showing them. We test ideas we have by building light-weight prototypes and putting them in front of users.

Prototype-and-test

Leisa's absolutely essential newsletter this week had links to two articles that discuss exactly this, and I suggest reading them both:

Alan Cooper calls the put a prototype in front of a user kind of research that we've been doing: 'Prototype-and-test'. Simon Roberts sums it up:

“Research has become less about questioning underlying assumptions and engaging with the complexity of culture and more about testing and validating objects and artifacts.”

I've not worked in the industry long enough to declare the 'UX-ification of research' a trend, but I find it reassuring that Cooper and Roberts have experienced the same thing. We also all agree on the reason for the diminishing importance given to Discovery-style research. It's: the fashion for Lean Startup and build-measure-learn loops; the attractiveness of 'Delivery is the Strategy' and 'Show the thing'; the pressure of agile iteration.

Open-ended research is necessarily slower than agile teams are used to working. It's not going to result in user stories ready for the next sprint, or at least not new code.

That's not to say that the prototype iteration is not important - I think it is, because we do need to iterate on what we've built - but it can't exist on its own, or be the only kind of user interaction the team has. We need to give some effort to looking ahead just a bit, to see what might be coming next or to reject potential ideas, and continue with renewed confidence that we're already working on the 'right' thing.

We need to occasionally come up for air, to check we're still swimming in the right direction.