What I learned from a UX Researcher in Marketo through a real-world case

Till now, I have been working as a UX intern in Marketo for 3 weeks. It is pretty exciting. After I did my first real-world user research in the industry(which is so so terrible), my user research mentor gave me a workshop. I learned so much from the talk that I decided to write a story to clean it up.

Project Introduction

This is the first project I worked on in Marketo. A main function of Marketo is marketers can use our platform to send out emails to their customers. When doing this, markers will set up audience list, email content, and schedule. For now, when marketers are setting up emails, they can only choose one single time zone like EST, PDT which is always the default timezone where the marketers are.

However, the truth is, marketers care more about the timezone where their customers are so they can get the best timing. We want to give the choice of sending in the receivers’ timezone which we call LTZ(lead timezone) for now. The main problem is what should we do when a marketer set a time while didn’t realize that some parts of the globe have already passed this time. Also, how can we deal with the complexity of using head start which means start processing emails 12 hours earlier.

My solution & Interview Notes

This is the main pop-up screen when a marketer chose a time which is a problem for some parts of the globe. (Don’t laugh at the terrible UI built 10 years ago! Our team is building a super cool new system, not only better UI but a better experience!) The user interview is actually not required from my mentor or PM but I have doubts about what marketers will do in this situation which is the options list. With this goal, I reached out to a Sr. Marketer here in Marketo. After she said yes, I didn’t really think much about what I should and shouldn’t do but rushed to ask her questions. I didn’t even think back to what I learned about user research in school! After a 30 minutes talk, I cleaned up a note looking like this.

This is the note that made my research mentor feel he can not wait to talk with me about UX research…

What we talked about & What is wrong

My UX research mentor did not know much about this project so he asked me to introduce it first. I talked for like 1 minute, trying to articulate the complex situation and everything I need to take consider into. My mentor listened patiently. After I finished my “speech”, he said:

“Try to use a one-line sentence to articulate the problem.”

A one-line sentence which can clearly state the problem will be important when we are communicating with others, especially with stakeholders. This is actually the same thing I learned in the Human-Robot Interaction class. In that class, the professor kept asking us what is the one-line sentence in your team, how did you modify that through time, what did you do to approach this problem and did your solution solve this problem. So here, the one-line sentence is: In the existing system, the users can not send emails to customers at the same time across time zones. My mentor also asked me, what are the users doing now to encounter this problem. This reminds me of what the user said, they have different marketing teams in charge of different areas of the globe which is also a backup for the necessity for this project. (Although they might need different strategy over different areas but still worth mentioning). As long as you keep the problem in mind, you will find a lot of related things

Also, he mentioned another point which I think is important:

“Make sure you know whether this is a want or a need”

This is actually a tricky topic and we kind of talked about it for a long time. I asked him, as a UX designer, should we always solve a problem which is a need? If so, is snapchat a need? This is an open topic while we agreed that a good product is not only about solving existing problems. They might create a want kind problem which is so good that it turns into a need. We can also solve a need and make is so desirable that everyone wants it.

“Choose a user who is not biased”

As I mentioned, the user is a marketer in Marketo. As an internal user, she is actually talking about the product she is trying to sell. It is highly possible that she is biased. Also, she might be more friendly treating a colleague. If it is possible, I will try to find an external user instead.

“Never show solutions upfront”

The most terrible part of my user research is that I am too urgent to show my solution to the user and ask for her opinion. Instead, I should bring up the problem and discuss with her what is she doing now to solve the problem, what does she think Marketo can do to solve the problem. We can even ask the user to sketch with us. People always say that everyone is a designer, and there have been arguments about should we ask our users to design for us. I remembered that the professor in HCI class told us, do not ask the user to design for you. However, now I think there is no problem asking users to design for us because we are not actually being laze and simply use their solutions. What we need to do is to see things through their design. We can learn their needs better through their design and come up with a probably better solution.

“Never ask what do you think(generally) but really get them thinking”

This rule seems like old-fashioned. But it is just hard to remember during the talk. Thinking is too subjective. We should always ask detailed and specific questions.

After the ideation with users, it’s time to show them what we have now. One thing to remember is never walk your user through your design. If so, they will have a pre-knowledge of what this is and they won’t really be thinking. A good design should have high learnability so people will be able to know what this is for the first glance. So instead of walking them through, we should show them some screens and ask them what they think it is and what might happen after you click something. And the interesting thing my mentor said is:

“If they ask a question, ask them back”

Instead of explaining right away, it would be better if we ask them to think first. For example, with the map design above, we should ask what they think it expressed and what they expect to happen when interacting it. This is the best way to know what we should improve and what the users might need. The basic principle is really just let users tell what they are thinking all the time.

“Feed them as little information as possible”

The strategy of asking questions is quite important. When I wanted to know if the map is helpful in decision making, I just asked it this way which is pretty bad. With this question, users will sure answer yes or no which is not informative for us. And most people will just answer yes, trying to be nice. Instead, we should ask questions like How would you use this map? Why do you think it is helpful? How are you going to use that? Can you give an example? When we are evaluating a system, we should not show interactions to them and ask what do they think about it, we should ask them what do you expect to happen.

Overall, when asking questions, we should keep the conversation organic and dig as much information as possible. One more thing is we should not only listen but observe. It is actually easy to tell if a person really needs it or he is just being perfunctory. Also, record it if possible. Keeping notes may take your attention away and it’s always better to be able to listen back.

Some thoughts

The principle above may work well in my case, but UX really needs flexibility over different cases so it doesn't mean they are universal and always right.

Being a student for almost 16 years, it is quite interesting to get started working in the industry. Things have some similarity while they need to be handled with more flexibility.

This is my first time doing user research in a real-world case. I didn’t prepare thoroughly and kind of sucked in that interview. But as my mentor said to me:

“It is never about sucking, it’s about being better.”