Hello Jane, tell me a bit about yourself.
I’m the Head of UX Research for Zapier, which is an all-remote company that’s dedicated to helping anyone and everyone offload the repetitive parts of their work. You’ll sometimes hear this referred to as workflow automation or app integration or a number of other terms, but the way I think about it is that we help humans spend time on the things that humans do best, and let computers take care of the rest.
My main focus is building out the UX Research program at Zapier and getting my team the resources they need to keep doing stellar work, informing company strategy. I love the place we’re at right now, because we have a huge amount of talent and capability, and we’re rapidly creating infrastructure to democratize research internally and start pushing our limits as a research team when it comes to producing foundational work.
The reason I got into management is because I’m driven by solving problems that are too big for a single person to take on themselves, and I design my teams with that in mind. Each person on the team might be working on a different research project, but they all ladder up to a single, overarching goal that will help Zapier make the best possible decisions as a business. My passion is building and leading teams that contribute meaningfully (and in measurable ways) to company success by helping align our product decisions directly to delivering value to our users.
Tell me about your design journey. How did it all start?
This was entirely accidental - I was actually going back to school to get my degree in Library Science. Hilariously, I managed to live in the Bay Area for four years without learning anything about design as a career option - I didn’t really know anything about tech, and I didn’t know that many people who worked in the tech industry. The ones I did know were people I knew through big art projects or weird street theatre, so we didn’t really talk about our work. I realize how strange that sounds to be writing in 2019, but it was 2007 - the Mission was still mostly full of hipsters, and I could still afford a studio apartment on a non-profit salary. I had no idea that there was a way for me to make a living that let me combine all the different aspects of my previous jobs that I liked best. My journey to design, and to research specifically, is really a story of some very lucky forks in the road in my career path.
So, back to how I got here: before I went to get my Master’s degree, I was working as an event planner, but prior to that, I spent several years working in libraries, starting in college, and continuing in my adult life. After four years of working a ton of nights and weekends as an event planner, I was ready for a change, and I really loved a lot of aspects of the library work I did, particularly book preservation and cataloging work.
However, as luck would have it, I went to the University of Michigan School of Information for my Master’s program, which has a lot of different specializations you can choose from, rather than just being a Library Science program. I started taking courses in Human-Computer Interaction and realized it brought together a lot of my disparate interests in a single field. If you look at my career history (librarian, event planner, design researcher), the thing all those jobs have in common is the organization of information in the service of human goals. There are skills from both event planning and librarianship that I use every single day of my life, like putting strangers at ease or categorizing information.
I also didn’t initially plan to go into research. My first job in design was as an interaction designer. I started as an intern at JSTOR, and they kept me on for the rest of my time in Michigan. Once I graduated, I was up for two roles at BitTorrent and had to make a choice between them: either an IC interaction designer or the UX research lead. That choice made me reflect on what I did (and didn’t) like about the different roles, and made me realize that research is where my heart has always been - I’m at my best when I’m operating in a complex problem space and helping others translate that knowledge into implementation. Once we get into solutions, I’m just not the best person for the job. And I like to have at least a shot at being the best person for the job.
Before being a Head of UX Research at Zapier, you were the Design Research Manager for Growth at Dropbox. Tell me about that.
While I spent most of my years at Dropbox managing the Growth Research team, I actually started there as an IC, which turned out to be invaluable for building cachet with product teams. There are many ways to do this without actually conducting the research, but it was early in my career, and I think it was the best way for me personally at the time. Being able to speak with authority that derived directly from experience in the field with our users was crucial to building bridges, and it laid the foundation for extending that cachet to my team once I moved into management.
My main focus was to create a working model for the team that enabled us to work on high-level, strategic questions that were relevant for all of the Growth while still ensuring that individual product teams had the access they needed to research. We went through multiple iterations of this before getting to a place where it was starting to work the way I envisioned, but I am pleased that throughout it all, we managed to tackle high-impact, foundational questions that informed a lot of future work.
The project I always love talking about is one that blended IC and management work for me. A couple of years into my time at Dropbox, Growth went through re-alignment of our strategy that entailed looking at crucial points in the user journey and developing a more complete understanding of them, with an eye towards redefining our key metrics based on our users’ goals. I led my team in conducting four separate streams of work that rolled up into an overall picture of our user journey and the key moments in it. We were able to uncover insights that immediately unblocked teams but also provided a well for them to draw from for years afterward. Even as I was leaving Dropbox, teams were running experiments based on ideas that they generated from that research from two years earlier.
There are a lot of reasons to move on to the next thing, but the one that always gets me is when I feel like I’m no longer solving new problems. Towards the end of my time at Dropbox, I felt like I was solving the same problems over and over again, without really developing new skills. And right around that time, Zapier reached out to me with this absolutely incredible opportunity to come to lead the UX research team at a time when it was producing amazing work but needed someone to come in and help the team turn its huge amount of potential into a well-oiled machine.
You’re now leading the UX Research team at Zapier. What kind of challenges do you face with your team?
At this moment, I’m actually managing both UX Research and Content Design, although we’re still deciding whether that’s the right structure in the long-term. I’ve got two IC researchers, as well as a Content Designer, all of whom are the kind of high-performing, exceptionally talented people that you have to be wildly lucky to inherit as your team. I had backfill for another researcher available when I started but made the argument to our Chief Product Officer (my boss) that we needed to hire an Operations person before we scale the team any further. To that end, I just hired an incredible Research Operations Program Manager to come in and develop infrastructure and help us scale our work.
In 2020, I’ll be hiring another 2-3 IC researchers, another 2-3 writers and content designers, and another research operations person. In short, we’ll be more than doubling in size over the course of the year. That’s why I was so adamant about bringing on Research Operations now - it’s the only way to scale that rapidly while having an ongoing impact at the level of company strategy.
At the moment, a lot of my day is spent building bridges between UX Research and other functions, as well as ensuring that UX Research and Content Design are focusing on the highest-impact projects. One of the key things I was brought on at Zapier to do was to help bring together all the different insights functions from across the organization so that we’re leveraging each others’ work and collaborating on the big questions. As part of that, we’re working on rolling out something called “Insights Pods,” which are a malleable grouping that consists of, at minimum, a Decision Scientist, a Data Engineer, and a UX Researcher, with other functions like Support Specialists, Content Designers, and Product Marketers joining as the work requires. These pods work together on key company initiatives. In an ideal world, these pods will ultimately be creating a shared insights roadmap aligned directly to the initiative they’re working on, with all the different insights functions contributing to each item on the roadmap. Of course, it’s easy to talk about ideal worlds when we haven’t rolled it out yet, so we’ll see what happens. 😁
What projects are you currently working on?
We just released Zap Sharing in beta to our paid users. This lets users share their Zaps with others via a link. I love this project because it gets to the core of one of our company values, build the robot, don’t be the robot, and takes it further by letting users leverage work that’s already been done. So now, users only need to build the robot once, and everyone they share it with can benefit from it.
The next step in this is public Zap Sharing, which will let users make their Zaps findable not just through Zapier, but via a search engine, as well. We’ll be releasing that in 2020, and I’m really excited for what it opens up for our users, and for the new channels into our product, it creates for potential users.
You’re the expert in UX design research. How do you conduct user experience research for maximum value?
Something I say to my team with probably annoying frequency is that the purpose of a research team isn’t to conduct research, it’s to have an opinion. More specifically, it’s to have an opinion that helps the company make better decisions than it otherwise would. Over the years, I’ve shifted my teams entirely off conducting evaluative work. We focus solely on producing research that teams can draw from for years to come — like the insights on the Dropbox user journey that I mentioned earlier. My team at Zapier embeds directly on our key company initiatives, which span multiple EPD zones and product teams. Our work all rolls up directly to Zapier’s long-term goals, which is how my team can ensure we’re producing the most value for the company.
Research that in-house teams conduct should have a lifespan of years, not weeks or months. That means focusing on the complex, foundational questions. If you create that well of insights, teams will be able to return to it over and over again. Contrast that with evaluative work, which takes almost the same amount of lead time, but has a lifespan of a few weeks.
This isn’t to say that evaluative work isn’t a necessary part of product development. Product teams should be conducting as much of their own evaluative and even more generative work as possible. Not only does that ultimately speed up the product development process, since teams aren’t sitting there waiting for research to come back with usability findings, but it also connects teams more deeply and directly to their users, meaning they’ll have a stronger sense for what users need and want, so they’ll make better design and product decisions as they go.
This shift to only conducting foundational research means two things:
- Research Operations is a must-have function because we need to democratize and scale the ability to conduct research to everyone at Zapier.
- We need to develop some way of bringing more junior folks in and training them up.
I’ve already spoken about Research Operations and how important it is, but let’s spend a little time on that second point. Research is a relatively small discipline, and it’s important to me that as I’m building a senior team, I’m finding ways to create opportunities for people with little or no research experience to get into the field. The normal way that would happen is to hire junior researchers that partner with senior researchers in one of our product zones and have them take on the less complex, more evaluative projects. But since my team doesn’t take on any projects that aren’t complex, we need to find new ways to do this.
I’m going to be piloting an approach to this in 2020, where we have a centralized junior researcher on our team. They’ll embed with a product team for the duration of a project, and then move to another team that needs some specialized research support. That way, they’ll get hands-on experience while still be part of a larger team that provides mentorship and helps them build their craft skills. Ideally, this will eventually turn into a kind of in-house apprenticeship program, where we’re providing opportunities to the next generations of researchers and creating a strong internal pipeline for our foundational research needs.
The other thing I’ve been thinking about a lot along these lines is building a team not based on methodological expertise or even the level of the researcher, but instead thinking about the jobs that research teams do that aren’t conducting research. I’m pretty sure there are researchers out there who would glare at me for saying this, but the least important thing that in-house researchers do is actually conduct the research. What we do is help companies translate the information we get from research into better decisions, and we do that in a lot of ways: through socialization, facilitation, thought elevation, subject matter expertise, and user connection.
There are a million different ways to get the same information in the course of a research project. I’m not concerned with finding one researcher who’s expert in one methodology, and another researcher who’s expert in a different one. I’m concerned with finding people who know how to get the information the company needs, and ensuring that the company is able to use it effectively.
As I’m building out my team, rather than saying, “I think we need a mid-level researcher here,” or “We could use a diary study expert here,” instead I’m working with my existing team and Zapier as a whole to understand what strengths we already have, and what additional ones we want to bring on board. To me, being able to conduct high-quality research is the baseline we start from. I take that as a given for anyone I’d hire. So I’m interested in how researchers ensure that their work has an impact, how they help the company translate it from ideas into action, and how they give it longevity.
I can teach anyone to talk to humans. What I want from my team is to be told how to think about them. How they get there is up to them. It’s what they do with it afterward that I care about.
How do you conduct your research and user testing?
Right now, we’re an all-remote research program, which has fit well with our company’s strengths as an all-remote workforce and has enabled us to move incredibly quickly and do a lot with very few resources. As we’re evolving the discipline at Zapier, we’re going to be spending more time in the field. There are certain things you get from fieldwork not just from a research perspective, but from a product development perspective, that is incredibly valuable, and that I want to make sure we’re equipped to do when it makes sense.
One of the most wonderful things about joining Zapier has been getting a crash course in remote synthesis (and all other things remote). My team is genuinely exceptional at this, and they have been patiently bringing me along. So much of my experience as a researcher has been with in-person synthesis, so this has been a chance to get outside of my comfort zone, push my own abilities, and learn a new skill.
A lot of apps become bloated with features in time. What would you recommend such products if they want to simplify/improve their UX?
“Simplify” is such a loaded word these days because it can get conflated with “go minimal” or “remove things.” Simplifying the UX isn’t a good end goal, in the same way, that efficiency isn’t a good end goal; they’re tools for achieving an end goal. But there are definitely situations in which the purpose of the product has been convoluted, or the UI is trying to do too many things at once. Once a product has found themselves in that situation, I start with a single question: How is this helping the user achieve their goal?
I like this question for a few reasons: it forces you to have a very clear understanding of your users, the value your product is supposed to be providing, and whether or not the feature is contributing to it. You can ask it at multiple elevations, from the overall product down to each individual interaction. And asking it every time you’re considering a new feature or a product change can help you stay true to your original purpose and ensure that you’re making good on the promise you’ve made to your users, and avoid feature bloat that dilutes or even entirely removes the value you were originally provided to users.
It’s very easy to “value add” your way straight out of product-market fit, especially when you can make a case for a feature “adding value” to users. The question when you’re adding new features shouldn’t be, “Is this potentially useful to someone?” It should be, “How does this contribute to our users achieving their goals?” A lot of good products have gone sideways by trying to be too many things to too many people, while not ever actually nailing the one thing people wanted them to be in the first place. So you have to get crystal clear on what people need from you and ensure that everything new you put into your product is part of delivering on that original promise.
That doesn’t mean that you need to stick with a single job or a single product forever. But the way to innovate is to steadily add to your original values in ways that are adjacent to it. If you’re a note-taking app, the way to add adjacent value is to look at the steps in the workflow that come before and after the act of taking notes, and see if there’s an opportunity for you to support those, as well. It’s not to decide to also provide video conferencing because you noticed that people who take notes also have a lot of remote meetings.
Do you use any personal time management techniques like pomodoro?
I don’t use time management techniques per se, but I do keep a gloriously detailed, color-coded calendar that blocks off not just meetings, but project work, reading and writing time, and anything else that needs dedicated attention. This isn’t just for me, and it’s also for the rest of my company - any time that looks open on my calendar is genuinely open, so there’s no need to check with me first.
I’m also a pretty efficient context-switcher, so interruptions don’t actually bother me. This is great for my productivity, but it means I have to be mindful of how and when I’m messaging my team. They’re the ones doing the deep thinking work, and need to not be inundated with messages from me on a million different topics. Part of my job is to protect their time, both from others and from me, so while I make myself available for interruptions as much as possible, I work hard to avoid interrupting them.
The only other tool I consistently use for staying on top of my time is actually just keeping multiple browser windows open, each one dedicated to a different context. I have three main windows: one for my basic work tabs (Google Calendar and Trello), one for personal (Gmail, GCal, and Mattermost, which my husband and I use for our household chat), and one for whatever things I need to read that day. When I’m working on a project in a heads-down way, I’ll pull out just the tabs for that project into a new window and minimize everything else.
How do you manage your projects?
I manage my personal projects with Trello since most of them don’t have formal outputs beyond documentation. I keep both running to-do lists on it as well as project-specific boards. Other than that, Coda is the tool I use most since it allows you to sub-divide your documents and keep all the relevant materials in a single, visible location that’s easy to navigate around. It’s particularly great for research projects since you can keep all of the related work in the same place - research plan, interview guide, recruiting screener, notes, findings, etc.
What excites you the most about design in 2020?
What a great question! There’s a lot I’m seeing in terms of the developing maturity of organizations’ understanding of what design can do. I’m particularly amped about the attention that Design and Research Operations are getting as disciplines, and am excited to see smaller and smaller companies starting to invest in them.
I’m also starting to see a growing desire on the part of designers and researchers for measuring their impact and really understanding the business side of things. The impact is my jam, so I’m very excited about this, especially having spent so much time working directly on growth. Design is about how we deliver value to users, but it’s important to do it in a way that aligns with the success of the business. I’m seeing a lot more about growth design out there in the world, which indicates to me that design is undergoing a healthy shift towards understanding and measuring how it contributes to business goals. While it’s not design-specific, this piece from The Margins is probably the best thing I’ve read on the topic in quite some time.
What is Avocode?
It’s an all-in-one tool for teams that want to code and collaborate on UI design files 2x faster.
How do you educate yourself?
I try to read whatever’s getting passed around on Zapier’s design Slack channel at any given moment, to see what’s resonating with designers.
This is going to be a telling glimpse into my background in growth, but most of my daily and weekly reads aren’t design-related at all; they’re business-related. I’m hugely fond of Matt Levine’s Money Stuff, and I try to make it at least halfway through the Economist every week.
I read a ridiculous volume of management books, but the hands-down, best-ever book on management is Michael Lopp’s Managing Humans. This is the “if you only read one book on management, read this” recommendation I give everyone. I also love The Toyota Way, especially now that I’m working at a company whose product is automation - that’s one I think anyone working on integration or automation should learn from.
Erika Hall’s Just Enough Research and Donald Norman’s Design of Everyday Things are the ones I’d give to anyone. For deeper cuts, I like Christopher Alexander’s Timeless Way of Building and A Pattern Language. And The Responsible Communication Style Guide should be read by anyone who puts words in front of users, in any context.
Where is the best place for people to connect with you online?
I gave up on Twitter a couple of years ago, so the best place is LinkedIn. I’m also technically on Instagram, but it’s mostly pictures of soufflés I post as humblebrags.
What’s an interesting or fun fact about yourself we wouldn’t find on your social media?
I spent the summer after my senior year of high school canoeing in the Arctic Circle with a group of 5 other women. We were charged by grizzly bears and wound up getting airlifted out by the Royal Canadian Mounted Police.
What do you like to do when you’re not working?
My husband and I have a one-year-old daughter, and we’re working on introducing her to the things we love, like hiking and cooking. I’m also a voracious reader and something of a crossword puzzle freak.
Bonus Question: When was the last time you ate avocado, and how was it made?
This afternoon! I gave my daughter half an avocado as a snack, and shamelessly ate most of it after she crawled away to play.