We’re back on the ground with our Research Lead Ki Aguero and they distill lessons from their early challenges in a massive new role.
We’ve made it to the final part of our three-part series about establishing a UX Research discipline within a transforming company. (If you need to catch up, here’s Part one and Part two.)
As you may remember, our product team is responsible for creating a more seamless, interconnected experience for our auto manufacturer’s car buyers and owners. Instead of relying on multiple agency partners, we’re standing up an in-house team of product managers, UXers, portfolio management, analytics & experimentation—all that fun stuff.
I’m the sole resource for all things UX Research, and I have been in the role for 90 days now.
Here are my two goals for our budding UX Research department:
Devote time to provide UX Research insights throughout the product life cycle, not just when it’s time to test prototypes
Educate the product organization as a whole about when they might need UX Research, because I simply can’t be everywhere at once
At the 60-day mark, I hadn’t really felt like I was making much progress on the first goal of providing UX Research insights throughout the product life cycle.
I’m proud to say that as of the 90-day point, I’ve got seven completed projects under my belt: only one of which was a user test of a prototype. The other projects have been focused on what to label new features/site areas, card sorts, and evaluations of live site experiences preceding redesigns—far more proactive than reactive.
My backlog of product requests is twice as long, and I know this because I’ve got my project management board set up! With some portfolio management support, it’s now the place where I drop requests, notes, links, and files related to each request. I’ve used the board to showcase what I’m working on to my boss (and the broader team, if they’re interested), plus I’ve flagged some items that fall more into the realm of content strategy (can’t wait til that role fills).
One of my favorite requests so far has been to investigate a live pilot that’s having trouble taking off. I get to partner with our product strategy team to uncover hypotheses about the pilot’s performance and ultimately determine what lines of inquiry need to be pursued to make the product better in the future. Obviously, it would’ve been nice to sort out any major UX issues before launching, but the team was operating without a research resource at the time.
Despite the progress, looming deadlines are starting to arise and prevent the incorporation of research as consistently as the UX team would like. Some stakeholders balk at the idea of letting a whole sprint go by while their designer digs into research findings.
I understand the pressure, but I’ve also emphasized that sometimes research can (and should) happen in the background to be revisited once the initial designs have been passed along to development. I’ve reminded designers about the range of test types that can address their concerns quickly (think click tests or single-task sessions that take users literally moments).
And finally, I’ve come to terms with the fact that a lot of initiatives tied to my first goal are “late bloomers.”
For example, I’d like to set up a regular cadence of customer listening sessions—an hour every two-to-three weeks where team members are able to observe a live customer interview, with potential to share their screens and perform a few tasks as well.
However, there are a number of challenges that could make the initiative fall flat: technical issues, no-shows, and difficulty moderating and cataloging the findings afterward. The idea of a single person managing all of that, on top of juggling other research projects, is daunting.
While I could probably lean on a colleague in another discipline (design or strategy, most likely), I’ve decided to wait until we have a second researcher on the team. That way the whole thing doesn’t come to a halt if I’m out sick or I’m passionate enough about creating opportunities for listening and empathy that I want to ensure quality over speed.
The other long-term play for our team is going to be benchmarking. It’s been up in the air whether our strategy team should own it or UXR. Personally, benchmarking has always felt like a lot of effort for minimal impact, but it’s requested by leadership.
While it probably can scale up to complement strategy’s goals over time, I’ve agreed to start a lightweight benchmarking initiative (executed by an external vendor, not our team). In a year, if we want to prove we’re providing a better experience, we have to have that initial baseline data in place. Right now, that feels like my latest bloomer of all.
On to my second goal: Educate the product organization as a whole about when they might need UX Research, because I simply can’t be everywhere at once.
I’ve continued sharing out a research artifact each week in our team channel. It might be a link to a video, a data graph, a quote, or a full deck. No one’s expressed anything negative about these posts and apathetic team members may ignore them, but the team members who are research junkies love them. It’s a consistent opportunity to educate the team about how UXR supports them (plus what users are telling us).
Product leaders and our org leader (my boss’s boss) have dropped into UXR office hours to chat or provide heads up on future lines of inquiry. We’ve brainstormed research ideas on the fly, and I’ve used it as a chance to introduce new team members to our materials.
I alternate early mornings one week to accommodate UK folks and afternoons the next week for my west coast teammates. And of course, I don’t know if this helps, but I always remind the team via chat when office hours start and drop the link in for easy access. It’s only been two months, but I haven’t had an empty office hour yet!
Truthfully, I’ve been neglecting my goals to assemble more training content for team members and broader stakeholder groups. It can be difficult to create materials with no audience requesting them or a clear deadline to deliver them. However, I’ve made it clear that I’m happy to spend one-on-one time with anyone who has questions, and that’s led to introductions across the team as well as the entire company.
In fact, this spirit of collaboration and support has inspired a new, third goal that is probably a no-brainer but deserves to be articulated: build and maintain healthy cross-functional relationships.
I’ve mentioned before that the team is small, but growing. This means I’m interviewing candidates for hire—sometimes several a week. While it’s been nice to get to know the candidates, it’s also given me and the other Ford-side interviewees opportunities to connect with each other in a different setting. Through our back chats, their questions, and our post-interview follow ups, I’m learning more about what they look for, their concerns, and their ultimate hopes for our team.
The less-fun part of being on a growing team is that there’s a lot of change, and it usually hits fast. Multiple times now, our designers have had to shift from supporting one product branch to another. There have been “fire drills” and early-morning/end-of-day sync calls arranged last minute. Our entire team is about to undergo an org change and roll up to a different executive.
There have been lots of questions. Second-guessing. Stress. As a lead on the team, I’ve made a point of checking in on people’s well-being. I’ve made sure people take sick time when they feel crummy and helped others talk through their hesitations about a design direction. I’ve reminded people of their own expertise and assured them that everything will be fine
And that’s not just feedback I’m handing out—it’s made its way back to me on multiple occasions. When I fall behind, my coworkers respond with grace and don’t mind moving a meeting or a deadline. If I’m not feeling well, I’m encouraged to shut down the computer for the day. I’m encouraged to speak up when my “spidey senses” are tingling. I tell a coworker they’re kicking ass and another one reassures me of the same thing a few days later.
I want to mention one more thing I’ve done to ensure healthy working relationships, and it might sound a little odd at first: I shared my quarterly goals with the UX team.
I’ve always thought of quarterly goals as very personal, but I’ve also worked within teams where the “mission” wasn’t clear. That sucked. I’ve found out too late that my work has overlap with someone else’s, or I discovered I was working at cross-purposes against someone else’s vision for a project. Given how nebulous things are (and will likely continue to be for a while), I thought it best to be transparent with my immediate coworkers about my ambitions and plans for contributing to the company’s success, the team’s contributions, and my own personal growth.
There’s a lot more growing to do in the coming years. I’m looking forward to returning to these posts someday and seeing what I’ve learned since I first began this journey. I hope I’ve planted an idea or two in your own mind, and that it’s able to take root in your own work.