Tent Talks Featuring Lindsey Latiolais – User Research Team of One

[00:00:00] Chicago Camps: Lindsey, tell us about your background, how you got started, and how you got to this point and where you are in UX and research.

[00:00:07] Lindsey: So I got an undergraduate degree in psychology. It was just something that I was interested in. Brains are fascinating to me. And I didn’t really do much with that degree right outta school. I actually lived up in Seattle for a little while, so I worked at tech companies, but mostly doing, Admin work.

[00:00:23] And I was like, all right, I’m gonna need to get an advanced degree, , let’s see what see what they have. And the University of Washington had a program, they called it technical communication at the time. Now it’s Human-Centered Design and Engineering. It actually switched over. When I was there, so you got to pick which name you got.

[00:00:39] So I got a master’s degree in Human centered Design and Engineering and was definitely drawn more to the research side. Some of that I think came from psychology. The research is very similar style. And I just liked the idea of using the data and exploring things. Rather than the actual sort of problem solving piece, I like diving into stuff.

[00:00:58] So I got very lucky in that they had a job fair at the school and I got a UX research job right out right after I finished basically pure UX research. So I think that set me on the right path. So staying in UX research rather than being like a researcher slash designer, I definitely wanted to have research be a component of what I was doing, but it was great to be able to do it full time.

[00:01:23] So I got a job doing out of box experience testing on mobile devices. And I actually right when I graduated, I just gotten my first smartphone. Cause I was like, all right, I. I need one of these this is obviously the future . I think it was like the third iPhone or something. But I was like, all right, it’s time.

[00:01:40] So I got a job doing outbox experience testing on mobile devices. We primarily worked with the equipment manufacturers. So like Samsung I think we did, we actually did a little bit for Blackberry. They were still around at the time, And that was that. Really quite formal research. We had, test scripts that we did.

[00:01:59] We were doing it in a formal lab with one way mirrors and everything was filmed. And so that was cool to do the very formal testing. It was 12 hour test days, we did them back to back. So that was a little bit brutal . But that was really cool. And I think getting in on mobile devices early also was helpful.

[00:02:14] So from that job I went, that was a very tiny company, about eight people consulting company. I went to work for Tata Consultancy Services, which was about 400,000 people. So that was a big switch, still a consulting company. And I was in house I worked down in San Jose. They had a small team there.

[00:02:29] And that was really cool because they’re an international company and although we primarily did work on with American companies and Amer products, I did actually get to go to Tokyo for about six weeks to do some research there. And that was super fun. I got to do it in ethnography, in a Starbucks there.

[00:02:46] We did usability testing with with people, so that was fun. I got to learn all the challenges. Translating, trying to translate designs, from very different languages English and Japanese. Turns out. And just designing for sort of very different needs and very different cultural expectations.

[00:03:02] And then also the cultural expectations in the office were very different especially being Americans who worked for an Indian company. In Japan, like all three of those have very different business cultures in very different ways. So that was really interesting. We actually had a Japanese Australian man who was like our mentor in the business side.

[00:03:24] Like here’s how to work with Japanese companies, basically. It was really interesting.

[00:03:31] And then from there I decided I wanted to do something more. In-house. Consulting is fun. You get to work on a lot of different stuff but you don’t really get to see projects all the way through. We had a lot of projects where we would do research, it’d be really cool, or we’d, do research and design and we deliver it, and then six months later, like nothing, maybe they’d use one little tiny piece of it.

[00:03:52] So I figured in-house maybe I could have a little more long term lasting impact. So I got a job at Orbitz in Chicago right before they got acquired by Expedia . So I was there for about a year. But it was great to be in-house. It did, I did have the ability to just have a little more sort of lasting impact working on projects, like different iterations of a project.

[00:04:12] It was really nice, you can see your research going back into the design and then doing more research. So that was really nice. That was when I first started doing sort of video clips which is, that’s how I learned that. Like stakeholders love video clips. So I used that throughout.

[00:04:25] And then Expedia decided they didn’t want UX folks in Chicago unfortunately . So I went over. The post startup world. I became, that’s when I became truly a researcher of one. They had never had a researcher before, but their designer had worked with a researcher. So that was really cool to build the research from the ground up.

[00:04:41] I could Use the tools that I was familiar with or find new tools. Used user testing.com a lot, not necessarily a plug, but just one of the tools that we used and they were, they were a smaller company under a hundred people. And then one designer, so just me and the designer. So that was really great.

[00:04:56] And then from there I went over to a company called neighborhoods.com. That’s where I work now. And they. Same thing in that I was a research team of one. They had a researcher before, but it had been a little while. And they had more designers. I think they had four or five designers at the time.

[00:05:11] So that was fun to work with more designers. They had more products, they were backend products that they work on. So they had their front insights and then they have a lot of like a pipeline for leads that sort of a lead generation company. So that has been cool to work on front end stuff and back end stuff.

[00:05:25] Front end I feel is where a lot of the research, the UX jobs are because people think that sort of, oh, it’s for users, it’s for customers, like it’s gotta be right. But the back end has tons of UX needs to right now I actually work on the pipeline tool and I work with the CSR team, so I’m, creating stuff for CSRs to use and that needs to be usable.

[00:05:47] They have to be able to train on it. When things go wrong, there’s people troubleshoot. It’s interesting problems to solve there. And then, when people are calling them, it’s usually when they need help or when they’re, not sure what to do. So the information we provide at CSR needs to be helpful to the person on the phone essentially.

[00:06:01] Chicago Camps: That sounds really great. You’ve been talking about how you’ve really been a research team of one, and you’ve done that a couple of times now. Are you able to explain or describe what you think happened? At those companies you worked at that made them realize, Hey, we have to start with even just one researcher.

[00:06:20] Do you know what I mean? Like what was the trigger for them to say, we need this and we need this now.

[00:06:27] Lindsey: Yeah, so for at the two companies where I’ve been a research team of one, it was always someone else advocating for the position. So at the first company it was the designer. The designer was really like we need a researcher.

[00:06:38] I’m making these assumptions when I’m doing these designs and I’m just not sure if they’re true or not, and I want to be able to validate them essentially. And I was able to come in and very quickly noticed. There was an assumption that everybody at the company was making. So Brad’s deals was the company and their website is around of hand curated deals that they post on the website.

[00:06:59] So they have actually an editorial staff that is finding these deals and writing up a blurb about ’em and posting ’em on the site. And I did some, I did a it’s called a five second test, where you show ’em the page for five seconds and then ask ’em questions. Nobody had any idea that these deals were curated, they thought it was a bot they thought it was a scraper

[00:07:17] nobody understood the, like primary value prop of the site from the sort of leadership perspective. So being able to come in and of show that value right off the bat, I think definitely helped convince them like, oh, a researcher actually, yes, we do need one of those. We need to keep this person around a little while.

[00:07:35] Chicago Camps: Did you ever observe any challenges where maybe the company wanted a researcher who does design or a designer who does research instead of saying we want, or we need a researcher. Period.

[00:07:52] Lindsey: I would say, I think in my perspective, and maybe it’s because I’m a researcher, I do think there’s a difference in the mindset as a researcher, I am a designer because I’m designing the research.

[00:08:03] That’s ultimately what I’m doing. I’m designing the research to answer a very particular question. Whereas a designer is solving a problem that’s been identified, and I think it’s it’s a little bit of a different design exercise to me. You have to think about different variables when you’re doing it, essentially.

[00:08:18] I think I would have been okay. As a researcher who does design, I’m okay at tweaking things. I’m not great at coming up with things, whole cloth. If you were like, design app that does this, I’d be like do you have one I can use to like, make it better ? Like it’s easier for me to make things better.

[00:08:34] And I definitely I’m better with on the research side with oh, how would we like get this information in a way that’s like valid and Repeatable and and useful rather than how do we design this interface in a way that sort of allows people to do X, y, Z more easily.

[00:08:49] So I do think it’s a little bit of a different like. Different skill, if that makes sense. Different mindset. Absolutely.

[00:08:58] I think the big thing about being a research team of one is that you have to have to evangelize the research and advocate for it. That like a big part of your job is convincing them that the research project that you wanna do is going to be valid. And one of the great ways to do that is by showing ’em that the research project that you just did is valid.

[00:09:17] And so learning how to present the data in a way that not just designers want to use, but that stakeholders can underst. The designers want a list of the issue by priority stakeholders. A product manager maybe wants what’s gonna happen if we don’t fix this problem, if it’s usability testing, for example.

[00:09:34] What’s gonna happen if we don’t fix this problem? and then your sort of higher level leadership folks, they, that’s where clip is are great or word clouds, visual things. But definitely how you communicate findings is huge in convincing them that this was useful research that we did.

[00:09:51] Please let me do more research . And that’s definitely something where, when I was on a team of researchers that was handled by the team manager or maybe a UX manager that sort of balance workloads or things like that. Whereas a research team of one, you like to make that yourself, what are you gonna research?

[00:10:08] And then be like, I need the budget.

[00:10:12] Chicago Camps: What are the most important artifacts and deliverables to you currently, especially as a team of one and why?

[00:10:20] And then what got you to this point of knowing that those are the ones that I really need to

[00:10:25] Lindsey: use? Yeah. I would say there’s two. So my audience, when it’s designers or engineers that’s when I’m using like a confluence page most often. And it usually has a table in it. And I’ll have, here’s the title of the issue.

[00:10:38] Here’s a description of what did I see, how many people did it what exactly was it that they did? And then I’ll have okay, what, why was that a problem? And then after that I’ll usually have a severity reading. I’ll usually keep it color code. Red means definitely fix this.

[00:10:53] I also like to throw positives in there. I think positives is a great thing to have in there, just so it’s not, here’s a bunch of reasons why you’re a bad designer. , I think that’s, that could be a little hurtful . And so I like to throw positives in there at the top, and then have severity ratings for things just so they can see alright, this is you.

[00:11:11] Yeah, this may be difficult to fix, but like one person did it and it didn’t really impact their experience too much. So like maybe we leave that one off and we fix the super high priority one, where like the button needs a different name cuz that’s super easy. So definitely like a Confluence page.

[00:11:26] The nice thing about Confluence pages too is they’re easy to find, they’re easy to search. You have a record of it you can go back to. I’ve looked at some of the research repository tools. A lot of ’em were just a little too powerful for a research team of one . But I like something more like a wiki than a Google doc.

[00:11:40] A Google doc is brutal. You can’t find anything in them. It’s just, yeah, it’s painful. . And then, . And then when it’s a sort of when the audience is like the leadership team or a VP level, then I usually like to go clip videos keep ’em, you super short, two to three minutes, just hit the top three issues that I saw.

[00:12:01] Grab at least two people who saw that issue because then they’re really experiencing it in the user’s. They’re hearing the user’s voice, they’re seeing what they’re doing, and that can be so much more impactful. . When I was at Orbitz, we had an issue where there was this you could get caught in an endless loop if you didn’t realize that this particular page was like confirming that you’d done a thing because it would show you the exact same fields.

[00:12:25] And they were blank. And so if you weren’t necessarily paying attention, you would get caught in this weird like infinite loop. And so I had a video of a woman who must have done it eight or nine times, just filled out both. And she was like, I don’t understand what’s happening right now. And so just being able to take that and just throw that, shoot that off to people, they were like, wow, that is very bad

[00:12:45] And also I understand how they did that thing. , cuz I could say like, all this woman did it nine times and someone could be like, maybe she’s not super technical. So it’s easy to dismiss users sometimes and the issues that we see in testing, whereas if they’re seeing it themselves, they can go, oh yeah, no, I see why, see what happened there.

[00:13:01] I would’ve done the same thing. Or something like that. So it really helps tell the story to higher level folks.

[00:13:08] Chicago Camps: Love that. We are down to the last question. Are you ready?

[00:13:12] Lindsey: Yes, hit me.

[00:13:14] Chicago Camps: All right. What’s the biggest piece of advice you have about tackling qualitative research?

[00:13:21] Lindsey: I think right now probably the biggest piece of advice is to team up with the quantitative data team and like work together to really provide interesting insights on both sides.

[00:13:37] So sometimes I might see something in testing.

[00:13:39] I go to the qualitative or the quantitative data folks and they go, Hey I saw this person, they were filling out this form and they got to the footer and they thought the footer was the like, submit button, and so they clicked on it. How many people are clicking on the footer on this page?

[00:13:52] And they were able to say, ah, you know what, it’s 20%. And on every other page it’s 2%. But it was like, we probably need to fix that . So I saw one person do it, but I was like, Ooh, ooh, I wonder if that’s happening a lot. And then it can go the other way. Our quantitative data tells us what people do.

[00:14:08] We have, we don’t really know why. We make a lot of assumptions about why. But I will say that in every single usability test I’ve ever done, one of my assumptions has been proven wrong. Sometimes it’s a tiny one, sometimes it’s a big one, and I’m like, oh, no, . We totally got that wrong. So I think it’s important to make sure that those sort of quantitative data measures are really being validated.

[00:14:30] That the reason that people are doing, we think people are doing that thing, is actually the reason that they’re doing that thing. And because quantitative data is just so big right now. Companies are making decisions based exclusively on the numbers. I think that’s a place where qualitative research can really move the needle, make a difference.