Summer Internship (12 Weeks)
UX Research Intern
I was working as part of the design team, directly supervised by the Head of UX Research. My main focus was Redfin's internal Customer Relationship Management (CRM) tool, the system that real estate agents use to manage listings and related workflows.
Additionally, I did research on a customer-facing feature and I compiled a UX Research guide for other roles within the company, such as engineers and product managers.
The best part of my internship was that I was able to closely work with my boss, whom I learned a ton from, but also with business stakeholders (product managers) and of course, end users.
For all of my projects, I either refined existing research questions, or I formed my own. Starting out with the right questions ensures that UX researcher and stakeholder are on the same page and shows that the UX researcher understood the requirements. Speaking of requirements: In the age of agile software development methodologies, UX research questions can often be translated into engineering requirements.
Asking good UX research questions also informs the UX researcher's work down the line, ensuring the validity of interview questions and creating a well-defined framework which the UX researcher can later furnish with his or her research findings.
To better understand the users of Redfin's internal CRM, I conducted contextual inquiry sessions with 5 real estate agents. Contextual inquiry interviews are carried out at the place of work of the interview subject and they focus on observing the users as they are going about their work. The interviewer assumes the role of an apprentice - while the user takes the lead as the expert as they go through the tasks and activities they normally perform. Even though I purposely didn't plan the interviews by bringing a protocol, I did prepare questions beforehand. On the one hand I wanted to make sure that I allowed for as much flexibility as possible, on the other hand, there were some areas that I wanted to focus on.
I interviewed 5 real estate agents in different roles: Two buyer's side agents, two listing agents, as well as a transaction coordinator. As the interviewer I not only observed the agents, but also engaged the agent in conversations about their work, and as a team we unveiled the many facets of an agent's work. The most fascinating aspect of the contextual inquiry sessions was that oftentimes I had design ideas as I was observing the user. I would share those ideas for potential design solutions with the agent, probing them with "what-if" questions about a proposed feature. This lead to many design ideas that I was able to share with my stakeholders.
While the agent went about their work, I would ask questions as they arose. Sometimes, it was to clarify things that I didn't understand (which happened often as I really was the apprentice in the real estate business, it was not just a role I assumed). I would often encourage the agent to show me something they were talking about, instead of just mentioning it. In the beginning, this was hard as agents seemed to prefer to tell me about how they did things, instead of showing me. Sometimes, agents would generalize and say, "typically, I start my day getting my kids ready for school". When I asked them how they started the day on that specific morning, they would be more specific and mention the fact that they check their email on their smartphone first thing after waking up.
Spending time with agents in the field was much more than just interviewing them at their place of work. It involved watching the users go about their tasks to build a deep understanding of their work and to gain empathy for the agents as a person.
During synthesis my goal was to generate meaning from all the data I collected. Going through the audio recordings of my Contextual Inquiry sessions often revealed nuances that weren't obvious to me while I was on site with the agent. As I went through the recordings and my notes, I coded quotations and observations into a spreadsheet. I would regularly go through the spreadsheet and group data into common themes. It was like an affinity diagram, only instead of having it on a wall in a conference room, I was able to bring it with me on my computer and I could start working with it as soon as I gathered data.
Apart from detailing my findings in a comprehensive research report, I regularly updated our internal UX Research blog. Summarizing my insights so they inspired change was a central focus of my work. Writing those blog posts forced me to distill the salient research findings and to tie them to previous research results. The goal was to showcase our work throughout the company while giving readers an easy to navigate overview of UX research outcomes.
Aptly communicated research results often don't instigate change, however. To bring my findings to the attention of the responsible stakeholders, I proactively invited UX designers, product managers and engineers to the table to present them my insights and design ideas. My goal was to always bring at least one low-hanging fruit to a meeting - something smaller that would be easy and straightforward to implement.