This project is described to the extent to which is possible as some of its details are confidential.
“Where to start?”
The problem: The leadership of a Financial Technology company was interested in formalizing a UX Research unit within the organization. Like any new project, there were limited resources and understanding of research protocols and the implications of developing a proper research team. Where do you start?
1. Mise en place
Before building a team, I had to understand what kind of team I needed to build. This meant having several conversations with stakeholders across the organization. Because I had no team yet, I treated these conversations as my first research project, one that I could undertake by myself and would lead to proper research output.
I designed a semistructured interview aimed to respond exhaustively to one general question: What would you like to know about our users and why do you think is necessary to know that? I scheduled interviews with C-level leaders, directors, managers and junior staff. This question was aimed to give me clarity on various issues:
- Who do we think our users are? Despite what we might think, not everyone in the organization shares the same idea of who is the final user. This question also helped me discuss the role of research as the voice of the user.
- What is the nature of the knowledge needed from our users at each level? Is it mostly qualitative, quantitative or both? This was important to know in order to justify hiring a team.
- What is currently preventing the organization from having that knowledge? Do we have proper data infrastructure? Is Google Analytics properly installed on the platform? Do we track events? Which events do we track? Do we have Hotjar, Smartlook, Log Rocket or something similar? These discussions helped both establish and flesh out potential dependencies on future research projects.
- How do you currently make decisions involving users? Some people already had a broad idea of how necessary a research unit was, some others have not reflected on the issue before. Knowing these opinions helped build a conclusive argument for its need.
The interviews also gave me an opportunity to show a small aspect of my exercise, and for the stakeholders to ask questions about my discipline. Concluding the interview with Do you have a question for me? has crucial.
2. Reporting findings
I was aware of the need of reporting in a clear way but “clear” can mean different things to different groups of people. I often joke about the fact that English is not my second language but academic English. Reporting on the findings of my initial study was a great opportunity to tune up my writing for a broader audience, assuming that at least those that participated in the interview process would be inclined to read the report and would have an opinion about it. This report included a research plan tackling the issues identified during the interviews and outlining the resources needed for its completion. I also used this opportunity to prepare a statement piece about the purpose of research in any organization. I recently published an extended version of this piece in UX Collective.
3. A high-level project
The first item in the research plan had to be something that was:
- Immediately meaningful to the organization. They were not just hiring a researcher, they were implementing research as a practice, the stakes were already high.
- Manageable by one person, at least initially. Hiring a team, no matter how small, takes time. The hiring process, although demanding, shouldn’t take the entirety of my time.
- Possible to be undertaken by a team. Once a team was hired, they would need a direction, a sense of purpose and a project to hit the ground running.
I decided to adopt a tool of academic research and adapt it to User Experience research (I describe this tool here) to create a version of a relationship/stakeholder map (common in service design) that would channel the initial efforts of the new research team. I describe this project in more detail here.
💡What did I learn?
The early conversations are not only a research project in themselves, they are a political exercise and an opportunity to manage expectations, particularly with regard to timelines. Most aspects of research cannot be expedited or automated and I shouldn’t have expected people in the tech sector to know that. I was not aware of this and I didn’t use these conversations to manage expectations. This led to mistrust among some stakeholders and I had to address this issue later on.
There is an innate tension between researchers and product and project managers. I didn’t know this at the time and I didn’t address this tension promptly enough. Now I know that these early conversations should have made clear to PMs that I was not there to replace but to support.
