Anna is a User Experience Researcher working in Berlin for Mister Spex. She was kind enough to discuss the unique UX challenges presented by working for an online optician using an omnichannel approach, as well as her strategies for engaging internal users with her research. Let's dive in:
Sofia: Why don't we start talking a little bit about your background and what you're doing at Mister Spex?
Anna: I have an educational background in psychology and human factors. I've worked in agencies for UX/usability consulting, I've worked in-house, and I've done a little bit of freelance work. I previously worked in-house for a small startup and for larger companies like HERE (a Nokia company). Now I'm working for Mister Spex as a UX researcher.
Mister Spex is an online optician, but not completely online - we have an omni-channel approach. Our customer’s journey also has offline touchpoints that I work with, which makes the whole thing a bit more interesting because it involves more than the usual eCommerce journey, so to speak.
Mister Spex is Germany's largest online optician, and it's also growing throughout Europe which makes my job more interesting because there are different aspects to look at, depending on the country. Mister Spex is considered medium-sized; our UX designers moved into the product teams and all work in agile scrum together. Research is horizontal across all the product teams, but I also do work for other stakeholders in marketing, brands, PR, and the multichannel team, of course. We also work together with the people training the staff in the stores, working on creating processes there because they also impact the customer experience. We also run tests in the stores directly which is fun and a nice change in your regular office life.
Sofia: You manage to supply so much input into not the only product teams, but also to the other departments - what does your process look like?
Anna: When I started here one and a half years ago, I was lucky that I came into a company that was very open-minded and appreciative towards research in general. It's a huge resource to have when you don’t need to convince everyone that your work is valuable and necessary. I know that this is not always the case.
My first step was to get to know all my possible stakeholders. I interviewed my UX designers and POs, asking them about their background, their take on research, their expectations and skills they could bring to the whole process in order to help me with my work. I needed to understand the maturity level of research here, especially because they didn’t have a fully designated researcher in the company yet. I basically did my own research on my internal customers within the company.
As a next step, I sat down with them and discovered a way to make my way of working work with their way of working. And then we just went for it because there were jobs to be done.
I think my advantage was that I already had some sort of routine based on my prior experience. I knew that if I wanted to do a user test in-house, what amount of time I needed to prepare. That also gave me the confidence to talk to my stakeholders, and even push back when necessary. I remember my first day here when people said, "Ok and next week, you will do the user test on this topic.” And I had to politely decline this because it was not entirely clear yet what it was they wanted to find out and I needed a bit more time to prepare. Testing for testing's sake is not the way we should go about it.
After some time we created a research clinic. It's for anyone who has a question or an idea that they want to research, or even someone who already knows exactly what they want to find out. People can come to that clinic and talk to me about their topic, and then we figure out if their question is something that I can answer, or if their topic is something that needs to be tested in one of our A/B tests, which are usually run by the POs.
I'm pretty sure there are different opinions on this, but I don't believe that it's necessary to squeeze research into scrum sprints. It might work for classic usability tests, but not for many other methods. You can’t anticipate the exact day when an A/B test will be significant or when you’ll have enough responses to your survey for instance. I don't see the benefit of fitting work into, let's say, a two-week sprint, which maybe turns out red just because the project finished one day late. But I know that there are different views on this.
Personally, I prefer working with a Kanban board, so people can write me tickets I can pull when I have the time to commit – depending on the prioritization of the tickets, which is determined by my stakeholders. We usually discuss or “groom” the tickets in the research clinic.
I also use this format to share knowledge from previous projects with them. Sometimes it happens that I say "Hey, we already did this or that research. Maybe you can have a look at the old reports first and see if it already answers your question. If it does, we can either focus on another aspect or don’t need to do the same project again."
I also sit together with all POs from all teams individually and let them share their next quarterly roadmap with me. This helps me understand how I might be involved in their upcoming work and also to plan ahead. And sometimes I use this to suggest other research projects on top of what they had planned.
Sofia: A lot of people we talk to feel that research is not being used properly and is not done enough in the development process. How does your team make it work?
Anna: Yeah, I am aware of that problem, and I've dealt with it in the past a lot. Also, here in Mister Spex to a lesser degree, but I think I'm a good way past that. I'm lucky to work with a PO who has a background in psychology, who knows that there are more research methods than just usability testing and surveys. I try to educate the team along the way, but not in a patronizing, "You should do it this way," but just like, "Hey, you know what? We could save ourselves two sprints of creating mockup after mockup after mockup if we just look at it thoroughly in the beginning and do some basic research on this or that topic."
I had a team come up with two ideas for one feature and ask me, "Hey, can you please do a user test with these two concepts?" and I suggested to take one or two steps back and use another method instead because if you need a general idea of where to go with your overall concept, the user test lab isn’t the right place. If you already have a finished flow, that is something you can test in the lab. However, if you have basic questions about the concept then - depending on what it is you need to find out - a workshop, interviews or more ethnographic research in general will bring you much further and can even save you time later in the process. So, in that case, I did a focus group where I incorporated the UX designer and the PO from that team to help me out with because I couldn't do it alone.
This was actually a funny story: I did not introduce them as the UX designer and product owner, but as interns. I told the participants that they're helping us out so nobody would pay attention to them, and they could just be the silent observers in the background. They had so much fun doing that, and I was glad they helped because I wouldn't have been able to do it alone.
It was also a great opportunity for them to see what I was doing because before the workshop both were a little skeptical and curious about how I could find answers to certain questions. In the end they loved it, were so full of input and enthusiastic like, "Oh my god, yes, now we have a clear idea where we can go with this feature." It was a great lesson for all of us.
I think it's important that stakeholders experience the methods themselves, so they get a feeling for what research is able to do. However, you can educate people best if they want to learn. If someone's not that open-minded, maybe you'll find another way to show them. Whenever possible, I try to invite people to result discussions after test sessions so they can see, okay, this is what she's doing, and this is the output, so I can maybe use it for myself next time.
Sofia: How would you save yourself time in terms of learning and in terms of being a more effective researcher if you could go back in time?
Anna: If you're just starting your career, ideally, you're not the only researcher around. Either way, I would recommend getting to know your peers and stakeholders. Get to know the people you're working for and get to know the people around you. Understand where they come from and establish a relationship.
Don't be shy because someone has this or that title. Don't be shy because someone is C-level. Don't be shy because there's a "head of" in the title. They're all just people and they're curious. They’re usually curious about you and about what you do. And if someone is not, that's okay because there will be someone else who is. Then look for sparring partners in your company that challenge your approach because you grow best when someone tells you what you're doing well or what you're doing poorly with constructive feedback.
I also went to quite a few meetups and workshops that were offered for free. But I live in Berlin. It's a big city and there are at least 10 meetups happening every day. If you have the opportunity to do that, do it. If you don’t or are not satisfied with what is offered already and still would like to network, you can maybe start your own meetup. For example, I'm part of a team that organizes something that's called “Usability Testessen” - which means test dinner - in Berlin. It's a mix of usability testing and speed dating. We offer smaller companies and startups that are not as mature in terms of research to just come there with something they’d like to test, and they’re all put to different “test stations”. We also invite volunteers to act as test participants and they rotate from station to station every 12 minutes for six rounds in total. There's pizza and beer which are provided by the host, and they can all try out usability testing for free - and go home with some cool results.
Another thing I found helpful was educating each other if you're in a research team. At one employer we did that every month or so and we also started incorporating it at Mister Spex. One of the team members presents either a new method or a method they're enthusiastic about, or something else they just wanted to talk about. Just geek out within your team. It's fun.
But I think that the most important thing is to not be afraid to make mistakes. Don't be afraid to fail. We all do, we all messed up a project at least once in our lives and it's okay. It's okay to make mistakes and it's okay to be a rookie. It's okay to be at the very start of your career and to ask questions. It's okay to not know things. I think that's also one important thing to keep in mind, it's okay to say, "I don't know how to do this, but I'm willing to find out." and to ask for help, to ask your peers for help and not just pretend that you're capable of doing everything if you’re not.