“Other side of the table” is a series featuring user researchers, their work, ideas, and challenges along the way. This week we’re featuring Lorie Whitaker, Lead Design Researcher at Rackspace.
Currently I live in the Dallas-Ft Worth area, but I hail from Southwest Louisiana. I’ve got a 1-year-old Scottish Straight Ear cat named Fergus. When I’m not busy chasing him around the house, I love to travel and recently started a business dyeing yarn for knitters and crocheters.
My current title is Lead Design Researcher at Rackspace. I get to work remotely (the rest of my team is in Austin and San Antonio), which is great. Since we’ve got wonderful video conference software, it seems like I’m in the office all the time! I’ve worked in UX for a variety of companies over the past 10 years, ranging from consultantcies to large and small companies. Before that I was a teacher, focused on technology skills for kids in Kindergarten through 8th grade in Seattle.
I had no idea this could happen! I mean, how do you even get rid of it?
Since I’m not a teacher any longer, it doesn’t really matter that I can get a class of 26 to recess on time and make sure they don’t talk in the lunch line. Although I still do work with stakeholders….
Well I’ve got a few, but the latest one….I do all my user research remotely since our customers are all over the country. I had this one guy who left his computer camera on (most participants turn their cameras off during the session because I’m recording it) and proceeded to change clothes. I mean all of his clothes. On camera. Luckily I wasn’t exposed to anything unseemly, but I ultimately had to shut off his camera (I had that power as the meeting organizer) so my note takers/stakeholders could concentrate.
Anything that will help people to understand how to get to the heart of an issue, including unknown influences on that issue, is alright by me. Too often I see people hone in on one issue, but ignore the processes and thinking that got them into that issue in the first place. Design thinking encourages you to think through and around the problem at hand, leading to a holistic approach to a solution.
If you have a passion for learning the whys of user behavior toward a product or situation, you can succeed without an advanced degree in UX. This passion will drive you to make sure you ask questions the right way to avoid biasing your participants. It will also drive you to understand where your product managers and other stakeholders are coming from.
Thinking they know how to ask unbiased questions. They often don’t. I’ve seen countless product managers ask the equivalent of ‘We’ve been working on this feature for months. It’s supposed to help you do your task. What do you think about it?’ I’ve also seen people assume they know their users because some research was done years ago and perhaps they go and visit a few customers each year and make faulty assumptions based on that and then, because time, money and resources have been invested, they refuse to challenge or validate their hypothesis.
There’s more psychology in UX than people are willing to admit. Your demeanor with your participant will decide if they are at ease with you. If they aren’t at ease, you’ll have a tough time getting feedback. Your reactions, if your participant can see them, are important to note and control as much as possible. Participants want to provide useful feedback, and if they think they are pleasing you, they could continue with feedback that might not actually be entirely true for them. But it’s also important to not be too clinical, as you need to establish a rapport to get great insights. When it’s time to present findings, psychology comes into play again. Who is your audience? What’s most important to them? What are they afraid to find out? You need to understand them so you can structure your presentation/report accordingly.
I’m a planner. I make sure I have my discussion guide handy and I review the participant information to ensure I understand who they are in relation to the research topic. I also fill up my water bottle and make sure my pen has ink, since I like to take notes sometimes during the session. Also, I like to give myself 15 minutes in between sessions for a break and/or time to talk to stakeholders to see if they have any changes in the script or design which we need to implement before the next participant.
For interview guides, notes, recording, prototypes, etc. Word to build my discussion guides, Excel for notes if I’m not in person (Put the questions in the far left column and each participant across the top, that way you can scan the answers once it’s time to write the report).
When I’m in person, I’ll jot some things down on a notepad or the discussion guide. For recording, I’ve used Morae, but with so many stakeholders and customers being located around the country, more and more companies are switching to Webex, Zoom or GotToMeeting for recording.
I don’t create prototypes, but I’ve used PowerPoint, Invision, PDFs, and Axure to showcase prototypes. I’ve also used my phone for SMS with stakeholders while I was in the room with a participant. It’s a good way to get additional questions in real time.
My main trick is to start relaxed myself. I tell them my job ‘User Experience Researcher’ and how that’s just a fancy word for someone who talks to people, like yourself, all day. I also make sure to tell them I’m not aligned with the product in any way other than to tell the product managers what I learned during the sessions. Also I tell them to share the ‘good, the bad, and the ugly’ with me, because I not only want to know what isn’t working, I want to know what is working so we don’t mess with it when we are trying to improve things. I make sure to ask them if they have any questions or concerns before we start with the test. During the session, if they are quiet and there’s not a lot to read, I like to ask ‘So what are you thinking?’. That usually gets them talking a bit more.
Since we are distributed, we use an Office 365 Excel document to take notes during the session. We encourage all our stakeholders to add their notes as well. Once the study is over, I take those notes and put together a PowerPoint presentation that distills our learnings. Sometimes, we present at our weekly design meeting (open to all in the company and attended by many stakeholders) and field questions from them. We always present the findings to the immediate stakeholder team, though. The next step is to archive the report and all associated study documents (notes, videos, prototypes, discussion guides, etc) on Sharepoint so anyone in the company can access it. We have started our own insights library where we use GitHub to store insight bites. We tag each so they are searchable. We are hoping to use this to make it easier for our stakeholders to answer questions about previous research as well as help newcomers to understand what we already know about our products and customers.
If you'd like to be interviewed for Other Side of the Table, reach out to email@example.com.
Want to contribute in another way? Check out our guidelines here.
Ready to launch a research project and easily recruit quality participants? Get started here.
Get "Fresh Views," our weekly newsletter, delivered to your inbox. We feature interviews and point-of-views from UXers, product managers, and research nerds of all stripes.Subscribe
Research sessions don’t always go according to plan, but having backup plans and a user focused attitude will take you far
It's 2018-going-on-2019 after all