What happened to R&D?

Sometime during the 1980s, I believe, a shift happened in corporate America. Slowly, companies began to embrace what has now come to be known as "user experience" or "UX." Jakob Nielsen (et al) pushed heuristics into the lexicon. Apple and Microsoft each disrupted various ways we do things with the introduction of the Mac and Windows, respectively.

My research hasn't been able to pinpoint a specific date or event of when it happened, but businesses forgot that research comes first in a successful product. Ford had forgotten this with the launch of the Edsel, but surely companies had learned that for some things, there is a natural, logical order. Or, perhaps not.

When Agile emerged and took the development community by storm, many technology companies simply ignored both research and design. Agile was never meant to be a tool for non-engineers, and R&D were always features that were well upstream of development. It is ironic that a development model that granted developers the freedom to state what they could and could not accomplish in a timeframe wound up removing the very processes that filled the pipeline of work that they needed to develop.

Slowly, as horrible products began to ship and fail, companies tried to incorporate UX designers into developer "scrum" meetings. The developers really didn't care (nor should they) what the designers were up to, and likewise, most designers didn't have any interest in when the next "merging branch into master" was going to happen. I recall countless lost hours of my career spent waiting my turn to list "what I did yesterday, what I was doing today, and if I had any blockers." These three questions are critical for a team of developers working in parallel, especially if they're not collocated, but not of much use to a researcher or a designer whose work could take weeks to complete.

For about a decade, I observed, the world was taken with what I call D&D. While it may sound like a role-playing game, instead, it was "develop and design" which typically meant designers trying to rework screens developers had produced and then hoping that the developers could redo screens to be usable before the end of the sprint. (This also required faith that the business partners would prioritize "fix designs" high enough in the backlog to get done - which often didn't happen.)

The agility in agile was meant to correct the "waterfall" environment in which engineers (now developers) were told to ship a product by a deadline, and they had no input into the feasibility of that. What happened, however, was that people assumed that nothing had a static order, and what followed was yet another realization that products continued to be shipped that nobody wanted.

Around 2010, I saw my first role for a "UX Researcher" appear on a job board. However, the description was largely a UX design role with the addition of skills in research methods. over the intervening years, a small but measurable number of companies started bringing formal product and service research back into their product lifecycles. However, they had flipped R&D into D&R, or what I call DNR.

In medicine, DNR is the acronym for "do not resuscitate," and that is an apt description of many of the products that were handed to me as a researcher, already developed, and I was asked to "test" them. While I applaud any research efforts as better than none, far too often when testing revealed deficiencies, researchers were told, "We'll fix it in the next release."

Fundamentally, the solution for this is simple - allow and encourage agility in the development process, but recognize that there is a hierarchy in a product or service lifecycle, and it begins with research - always research. Whether it's an existing or new product, there are fundamental questions that must be answered:

• Do people actually want the product or service being offered?
• Are people willing to pay for the product or service being offered?
• What are the targeted demographic's minimum requirements to pay for the feature or service?
• What thing(s) are non-starters for the people you envision using the thing you're trying to create?

This is but a small fraction of the questions that research can answer, but I would argue they are critical data points to have in building a product roadmap or a service blueprint. Similarly, research feeds into design, whether it is a product or a service. R&D is a separate cycle from development. Automakers don't bring finished cars up to a researcher's office and say, "See if this thing is safe on the road." Companies like Boeing don't build an airplane and then ask a researcher, "Will this thing fly?" Yet that's exactly what seems to happen in many IT organizations today.

To fix this cycle and ship products that are both viable and desirable, executives and product owners need to embrace that R&D comes before and is a separate process from development. A funded, structured research and design studio will yield tremendous ROI. The cost of development rework has been rehashed so many times that detailing how to calculate the ROI of UX is redundant. (Jakob Nielsen and Don Norman have a suitable summary in that link.)

I do believe it's time to update the equation, however. It's no longer R&D. It's R+D = P, where P is the product, developed. Researchers no longer can and should not sit in cloistered towers. Designers do not require Art Deco office spaces to thrive. And to be fair, development should have a say in the timeline of the output of the R + D deliverables. But that is different than having veto power over said deliverables. Most importantly, executives and product owners must be willing to have sometimes difficult conversations with their stakeholders on when a product or service with desirable features can be delivered.

The dissociation of R&D from development has led to a cycle of unstable or unusable products being released to market under the guise of "MVP." Again, N&N Group has a video that covers this in detail, but in summary, MVP is generally the antithesis of good UX. For progress to be made in delivering "human-centered" products, R&D must again be brought to the fore and utilized to drive down development costs and increase desirability. While R&D may lack the sexiness of newer terms, it has been the foundation of humanity's greatest discoveries and achievements, and the savvy executive or product owner will insist on leading with R&D.

Note: Some people have lumped "research" and "design" into the term "design." Others call it "design research." Researchers are trained in the discipline of understanding humans and their needs. Designers are trained to turn those needs into things that can be built. Psychology is a critical and crucial component of the work that they do. Researchers are not designers, and designers are not researchers. A seasoned "UXer" likely has had to do both but has specialized in one or the other.