Rebuilding Research and Making Wine

Sometimes it takes a perspective external to a discipline, company, or team to innovate and freshen an approach, find new efficiency or simply make things "better."

For Dave Hora, founder of Dave's Research Company, those "non-research" perspectives include wine making and architecture. As Dave started and grew in the field of experience thinking, moving from HCI to design and ultimately to research, he routinely bumped into issues of focus, process, and structure.

His interests outside of research started to creep in and offer insight to the work he did inside. He started noticing ways other thinkers were wrestling with similar problems, albeit in much different contexts like urban planning, construction, and grape growing and harvesting.

We caught up with Dave to discuss some of these new perspectives, the ways they might support a customer-centric research practice in today's organizations, and how we can keep our eyes tuned to the new perspectives we might use to rethink and improve our workflows.

dscout: Describe your path to being "Dave" from Dave's Research.

Dave: It's a little bit silly, I didn't know that you could be a researcher until I was offered a job as a researcher. But I was trained in a classic discipline for researchers—Human Computer Interaction and Cognitive Science.

My first job was in database management, which showed me how much I didn't want to be a database manager so I moved from Washington D.C. to San Francisco, and used some portfolio work to land a contract design gig.

I didn't do a very good job at being a designer. I kept asking questions like, "Well, why is it like this? What are these people trying to do? What's happening?" Here is where my training pushed me to always try and understand the context of work and made it hard to be confident in my design work.

As my contract was ending, they said to me, "We don't think the designer thing is working out, but if you'd like, we could create a position and you could be our first full-time user researcher." And I said, "I think I would prefer that to being fired."

I’ve been researching and product-strategizing ever since then. As a repeat “first-researcher,” I’ve hit a lot of barriers and obstacles in making the work effective. Like any good researcher, you have to ask yourself: okay, why? At some point, if you get stuck and you struggle, you have to step back and say, "What's really going on here? How does this business operate, and what's my role in it? How do I operate effectively as a researcher?"

And as your perspective widens, you realize that what seem like obvious, simple changes might be six months to two or three years of work and capability-building. That was the beginning for me of the organizational and influence side of my interests.

I came to find that I loved doing that work, figuring out how an organization should adapt and change, so that user insights could be an effective driver. And I also found that I didn’t have the patience to stick with one organization for two, three, or even four years to shepherd that kind of change. I was restless for new contexts, new challenges, and a life that wasn’t tied to the schedule of an organization for the long term.

I left San Francisco in 2019 and first moved to Denver, establishing “v1” of Dave’s Research Company, trying to figure out how to work as an independent research consultant.

When I announced my new company, my peers reached out to me about some potential projects, and that’s how Dave’s Research Company got off the ground.

A few years ago you and the ReOps Community published a research skills framework. I hope we might start with how you became interested in and involved with that project.

When I first had the opportunity to hire and build a team, I had to ask myself, "What is the path that a researcher goes through? What does level of seniority mean? How do I figure out what to look for if I'm hiring somebody?" I didn't know how to make sense of that.

And so the answers started with this article, the Researcher's Journey. It was a lightweight model of the research process and the growth of a researcher. It helped me ground my understanding of research and potential traits of different seniority levels and began some interesting conversations.

But over time, I could see that the Researcher's Journey model wasn’t giving us the level of fidelity we needed to deeply understand what research was, how we could make it work in the organization, and what skills and sensibilities people needed to become effective researchers.

At the same time, I was getting steeped ever more deeply into the work and ideas of Christopher Alexander, participating in the public reading seminars on his work through the Building Beauty program every year. I was especially interested in the application of pattern language as an embodiment of craft skills and sensibilities, as a means of generating projects and buildings from the ground up. I started trying to sketch out the little “patterns” that make up the core of user research work.

In the fall of 2018 I shared this rough sketch into the ResearchOps Community Slack, saying that I’d like to dig into research skills. Emma Boulton created a channel called “#skills-framework” and invited a number of people she thought might be interested in pushing on that work. And the idea of the project started gaining momentum.

Tomomi Sasaki joined me as a primary co-conspirator, and a huge portion of the community helped us through the work over the next couple of years. Nobody knew what it would end up like, but everyone was excited about trying to nail down and make sense of what skills researchers need to succeed.

Two years later we had the Research Skills Framework in place on researchskills.net. And then the next phase started, making it work. If this was an industry project, I would have started with a much more applied lens, but it was really fueled by passion and curiosity, so the scope was a lot more open.

There’s always a tension between deep modeling vs. quick applicability. The framework is fairly comprehensive, but for that reason, takes some work to get into. As we’ve run workshops and socialized the project, you can see the light bulbs going off, but it really does take a bit of effort to pick it up and get going.

We built guided activities that gave researchers and their teams a clear sense of how they could dig in, start to work with the larger framework. Those are in the “Tools” section of the site.

And my favorite articulation of what we’ve built is in the talk on Learners called “The Research Skills we Need to Succeed.” I think that’s a strong overview that also shows the elegance and future flexibility of the model.

Now it’s really in the hands of the community. It’s open-source and ready for anyone to build on. For me, going forward, I see it as a prototype of a new way for us to break down our work, of how we might decompose and reconfigure product development at large.

You’ve been drawn to architecture as an influence for organizational operations. In what ways do you see those spaces merge?

I’ve spent a lot of time reading and thinking about the nature of patterns in architecture. Again, this comes from work by Christopher Alexander, an architect, design philosopher, builder, and mathematician who was interested in conceptualizing the design of spaces like houses, villages, and towns.

He first worked with the idea of a strict hierarchical decomposition, like an equation of sorts. His approach was to start large—say at a neighborhood level—and move down incrementally, from street to house, and house to room, and even room to window, to unpack how a design can be seen as a functional representation of the needs of the people using and living within it.

But he found that a strict hierarchical decomposition of user needs upfront wasn't truly possible—or even desirable.

The design itself had to unfold smoothly over time to ensure well-built outcomes: some decisions can never be made well until other aspects of the design are fixed into the real world. (How can you determine the best possible size and location of the kitchen window if you don’t know where the house is located, how the sun moves throughout the day, and the seasons?)

So he created a pattern language: a network-like representation of the kinds of problems one has to solve when building something well, and the sequence in which these decisions would turn out the best.

These patterns were derived from decades of study in how people live and what they want, how they want to feel in various aspects of their neighborhoods and towns and houses and rooms.

All in little problem-solution packs of work that a designer or builder could use to construct a thoughtful and human-centered living space, no matter the size or location of the project. Extremely interesting to me is that the sequence of decisions itself can convey deep craft knowledge.

We treat insights collection as a sterile process: we go out, we get “the insights,” we make a report, we bring it back and put it into the design process. It starts to feel like a false notion of iteration and feedback.

We can lose sight of the larger context when we look at research as just the insights collection part of the work. Alexander’s architectural perspective emphasizes the shaping of the process itself, of the sequences of decisions we need to work through so that each decision provides feedback for the next choice.

And what might this look like in practice, organizationally?

We can zoom out and use this idea of process. We need this kind of philosophy to drive the process so that we can be intentional about what concrete steps we’re taking. To know upfront how and when we’re going to engage users in our work.

It's a different mindset—planning out the sequence of specific decisions we imagine we need to make for the project and understanding what will inform those decisions upfront. I think it’s a much more productive approach than just injecting the research when we think you need it—often too late in the process to drive real change. It forces us to have harder conversations about how the work is going to go.

This, for me, is where we can develop true agility: recognizing what we’re trying to accomplish, which stage of work we're at, and the shape of that stage is in the larger process of product development.

Then from there, how we need to operate—on what time cycles and what our schedule is, what the activities will be. We in the experience and insights realm often use the double diamond or the six-step design thinking model as a means for guiding the process.

But the problem is that they're context-free and sterile. They don't suggest what specific activities should be done at a given stage, or how to go about doing and learning those things.

On the whole, we don't talk much about the arc a project follows, no matter the size. We don't talk about that a lot, and I think that's why we have more sterile—yet popular—approaches to integrating research into agile product development.

Agile is wonderful, but it might not be the approach to fit all the phases of a project. Do we approach a new product development the same way we do a small add-on feature? When it’s working well, the organization becomes more process-aware and understands the logical sequence of steps required for any scope of work at hand.

You live in Porto and recently finished a wine harvest. Describe the motivation there and what it taught you about experience design.

I worked at a restaurant during school, and I wasn’t so keen on wine. Until we had a wine training week, tasting over 140 wines, and one for me was a bit of a shock to the system: a Chateauneuf-du-Pape that tasted like rust, dirt, and mineral, in the best possible way.

Wine could be more than heavy, juicy, fruity hangover water. I was hooked, and I came to find a fascinating diversity in the regionality and the culture and expression of wine

In France, for example: the difference between a red Beaujolais Cru, like Morgon (made from the gamay grape), versus a red from the Northern Rhone Valley like Crozes-Hermitage (made from the syrah grape) are extreme: you learn to recognize them quite quickly.

These places are only 140km apart, you could drive from one to the other in less than two hours. Something about the land and the grape varietal creates these unique signatures. But we also find a rich diversity of styles produced within these distinct regions, a whole range of expressions.

It begs questions. How much is it a function of the grape, climate, and specific geology of that vineyard—the terroir? How much is the producer marking the wine in the procedural choices they make—the craft? And how does that process work? They’re dangerous questions for a curious researcher without a full-time job.

I felt, especially living in Porto, where there’s wine production in any direction you can drive, that I had to learn how it really works. I needed to see what these wine producers are doing in the vineyard and in the winery, and how wine evolves throughout the process.

It exposed an interesting juxtaposition: what we create is genuine and has value, but in the process of doing our work, the material is ephemeral, the unfolding state of what we create is so nebulous. I love the idea of the more manual, physical, and “real” operational work involved in agriculture and wine production.

I took six weeks this fall and worked in a winery with a top-notch Portuguese wine producer named Luis Seabra. I met him at a local wine bar, through a mutual friend, and got to go visit his winery in the spring.

Eventually, I asked him if I could learn from him as a harvest intern, and he told me that I could, as long as I was prepared to suffer. Which I did. It was the hardest work I've ever done in my life…I think during the peak week, we slept one to two hours every night.

I've never experienced and felt so clearly these physical operational constraints. There are grapes in the winery that haven't been sorted and put into the tank, we know absolutely what must be done…even if there are 800 boxes of grapes and it's already 7:00 PM and we can tell we're going to be here until 7:00 AM.

What that pushes me to ask, as I reflect on this experience, is about where our hard constraints exist in the process of creating software. To reflect and improve on my research work, I like to chart out and write out notes from my prior projects. And so many of the activities that I've done are so superfluous.

You go back and look at what you did, what mattered, and why and find that in the course of our work, and so few of the real constraints and drivers of product outcome were clear.

So I'm trying to take this approach now to future projects and future work, a harder logistical lens: in our projects, what are the grapes? Where are the grapes? What kind of wine are we trying to make? And what is the throughline that we need to draw from our starting conditions and input material to our final output?

That's what I would like to help us see in research, what the wine making experience has added to my perspective. There's a pure physical, visceral reality to the operations in the wine realm, and a lot of times we don't have that.

We can create a report or put our insights in a repository and feel like we've done something, but did anybody take them, did anybody use them? Did they really shift what we needed to do? Are we preparing the grapes to become wine, or re-organizing empty barrels that aren’t even going to be used?

It’s always coming back to this: zooming out and understanding the larger course of our work, to figure out what must be done, what really matters. Also, it's just nice to have a good glass of wine.