I’ve always enjoyed watching things grow. 

I loved the bean sprout experiments in biology class, and I’ve always appreciated the color and life that houseplants bring. 

I finally dedicated space in my backyard last year to growing my own garden, and I reveled in walking up and down the rows and watching the plants thrive. 

I get the same kind of geeky delight when I think about my job right now. 

I support a product team that’s responsible for the dot-com experiences of a global automotive company. The company is undergoing a multi-year transformation to create a more seamless, interconnected experience for car buyers and owners. That means they can’t outsource their designs to a bunch of agencies anymore; they’re bringing the product teams in house. 

Two months ago, I joined a team of about 50 people, and I’m their sole resource for all things UX Research.

I have two overarching goals for our budding UX Research department:

At the 60-day mark, I’ll be honest: I don’t feel like I’ve made much progress towards these goals. But I’ve planted some seeds, and–I’ll be damned–they’ve started to sprout up out of the earth! 

Let’s look at some of the initial shoots of growth and see what I’ve learned. 

I assembled my first report—a single slide summarizing a two-question survey. The project gave our global navigation product manager the confidence to move forward with a massive A/B test. 

While the project was tiny, it ended up building a lot of goodwill with the product manager who talked me up during a weekly team call. It was an awesome message to the product team that if they’re not totally confident about the direction of something on their roadmap, maybe UX Research can help (goal number two).

Each product leader also hosts a weekly meeting with their team (and usually the supporting crew is there, too—someone in analytics, project management, etc.), and I’ve been able to share a UX Research introduction deck multiple times (another win for goal number two). 

The content is tied more to the product team than to UX Research; I focus on how I help them answer the key questions their leaders are asking, and where in the product life cycle a UX Researcher can bring insights. It also emphasizes that they’re among my primary stakeholders, and that they don’t have to know exactly what method to apply; if they need more confidence in their approach to a solution, they can set up time to chat with me and we’ll see if UX Research can help. 

Another educational tactic I’ve continued is sharing a research nugget each week in our team chat. I ran some proactive tests on the dot-com site, and I can pull a clip from those sessions in a pinch, but I also monitor the tests I’m running for my product and design teams, and I try to pull a clip for each study that showcases what UX Research can do or what can be learned. 

Clips and infographics get a lot of emoji reactions from team members. It’s also led to follow-up questions, sometimes from senior leaders. When you’re a new resource and you want to be embedded into the product life cycle, visibility is so important! Sharing just one research nugget a week keeps the option of user research top of mind for my team.

My introverted side cringes at the memory, but part of me is absolutely thrilled that so many teams are reaching out! My product and strategy stakeholders are out there trying to solve problems, and sometimes they get a little stuck. I’ve made it clear that UX Research might help them, and they’re coming to me for help. The message is sinking in. Big wins for goal number two!

Things are more sluggish with goal number one.

User testing prototypes is important, of course, but that testing feels very reactive and comes towards the end of the product life cycle, when a solution is already established.

In my mind, a healthy UX Research discipline should also be proactively testing what’s live today, through benchmarking and customer listening sessions. There should be concept testing while solutions are still being considered and mind mapping exercises to help inform solutions. 

Nobody’s really clamoring for that, and all of my awesome outreach efforts have seriously limited the time on my calendar to design those more proactive approaches. Whoops. I’ve got to block out more time for those efforts in the next 30 days. 

I did support a prototype user test, which the designer then analyzed. 

At my last job, the UX Researchers tended to help designers during the planning phase of their tests. But then we shoved the videos at them and had them fill out a report template, and there were two big problems with that:

To avoid this, I created a super-basic spreadsheet where literally everything about the project lives, and we fill in the test planning sections together, including instructions for the designer to complete during analysis. It threads together the original goals, the tasks/questions addressing each goal, and the eventual learnings tied to each goal. 

It’s a little extra work to set up, but it gives the designer some “rails” to stick to while they’re watching sessions, and it serves as documentation for what was done and what we learned, without eating up too much more of the designer’s time (or the researcher’s). 

The one wrinkle in this approach is that there’s no easily-digestible summary for the designer to communicate findings to his product partners. One of the longer-term product leaders clearly expected something more polished, maybe because she was used to seeing readout decks from agencies. 

That mismatch in expectations reminded me that I need to be extra clear about end results, and that I need to remember to be flexible if the team has other expectations in mind. 

The hardest part about supporting an entire product organization is that I have to do a lot of context switching. The product teams are split up into five different parts of the customer journey, and each team has about five product managers, each of whom own a little slice of the experience. It’s difficult to keep track of who owns what and where they are in the users’ overall journey.

I’m also struggling to manage the incoming project requests, and I’m going to have to create a backlog of projects. I’ll have to work with partners to prioritize, and I worry about projects slipping through the cracks or my teammates deciding not to trouble me with more requests.

With help from our portfolio team, I’m setting up a UX Research space within our project management tool. It was originally built for the engineers, and it’s taking more time than I’d like to adapt it for my purposes. 

When it’s up and running (hopefully by the time I start writing part three of this series), I’ll have a view of the work being done and what’s coming up next that literally anyone in our organization can check out. I can use the information to facilitate planning conversations, provide better timeline estimates, and make the case for more research team members. 

In other words, I’m establishing roots and getting ready to bloom.