Don Norman posted an article about the realities of design in industry and how going through the ideal process of doing research first, then going through ideation/prototyping/iteration is not necessarily optimal.

Why it is not necessary to start with design research

Here are five very different arguments to support the practical reality of starting by designing, not through design research. First, the existence of good design that was not preceded by research. Second, the argument that experienced designers already have acquired the knowledge that would come from research. Third, the research effort of a company ought to be continually ongoing, so that results are available instantly. Fourth, and most controversial, research might inhibit creativity. And fifth, when the product is launched and the team assembled, it is already too late.

Act First, Do the Research Later

There are a number of comments on the post from the design point of view... but what about from the researchers point of view? Sometimes a user experience person is both the designer and researcher, so the distinction doesn't matter.  However, when there is a distinction, as there is at Microsoft, there can be very different points of view. For me, I'm a researcher and I collaborate heavily with designers. However, I wouldn't be any stretch of the imagination call myself a designer. I've seen these pros in action and can't do what they do.  However, I can do research really well and love that aspect of it.

Some of things that hit home for me on this article was the point of when the project is started, the research is already too late (Point 5 in Norman's argument). I've had numerous occasions when I've started working on a project and they want to know everything about the topic... yesterday. There's no time to carry out a nice, valid ethnographic study or series of research studies that I would want. Lightswitch was one example where we did do the research first, but that is certainly the exception and not the rule. I'll have to write about that in another blog post though.

Planning for Visual Studio 2005 was a time when we pulled together every bit of research we could put our hands on and made it required reading for each scenario team. This was the first time I was involved in an effort like this. There was no time for new research, but we had about 2 weeks to pull out all the research we did on previous versions, what research Office had done on FrontPage (I was working on the web dev tools), all the Expression research we could find, and all the marketing reports we could find. It made for a huge amount of research collected all in one place and got everyone socialized into what we currently knew about web development.

So the point of constantly doing research (Point 3 of Norman's argument), and being immersed in what our customers are doing resonated well to me. Not waiting until a request has been made to kick off research projects is quite necessary. It also takes the pressure off of having to deliver research results in a rushed fashion. It ends up just feeling like intuition with data to point people to if they weren't involved in the project when the research happened. Always Researching. Always Acting.

Norman's second argument that designers already have the acquired knowledge that would come from research is an interesting one.  He says: "I find that in my design consulting, I will sometimes skip the research phase. Act first, then analyze and think about it afterwards. I can get away with this because I did the necessary research over the preceding years: I have a lot of pre-existing knowledge." As an experienced researcher, this happens all the time. Keeping the people I work with constantly informed and having them participate in the ongoing research gives them this ability as well.  Sometimes, I come across newer researchers who are very paranoid about their product team making decisions without the appropriate research done first. I've found that the longer I work with people, I certainly know who knows what's going on and has been fully immersed in the research. We have much better interactions on what the right things are to do for the customer and don't have to put off decisions to get the research done. We also know when we hit something that we don't know the answer to and put together specific research to address those questions. Experience is huge.

For the fourth argument of having too much research... I haven't really seen this happen on my job because we never have the time to do too much. I sometimes wish I had that kind of time! We have ship dates and deadlines and we have to move. We're not crippled by spending too much time researching something to death. Of course, this also leads to why I don't write academic papers... I don't have time for that type of research. Which leads to a tangent point... we have "Ux Days" at Microsoft where we present our research methods and interesting findings to the internal Ux community. These are usually awesome presentations that are cutting edge and informative. But, they would never make it to a professional conference with a rigorous review process. It's a shame, because that's the type of research that helps most to hear about for industry folks.

As for #1, yep it happens; glad it does.