Bringing Research Insights Closer to Decision Making
The problem: Difficulty in finding, tracking and aggregating research in PropertyGuru. This led to stakeholders (PMs, Designers, Researchers, Marketers) feeling lost, not even bothering to look for user insights. This resulted in a product cycle where the stage of understanding user needs was skipped, consisted of too many assumptions, or the team wasted time conducting research for insights that have already been uncovered.
The challenge: Solving the problem required discovering the nuances of all stakeholders’ needs and issues through time consuming testing and iteration, whilst also running the day-to-day research + research team management.
The solution: Research insights integrated within Confluence, where most of the product team and design team collaborate and document decisions.
The Beginning: Google Drive, Airtable, Slack and the Polaris Ideal
When I joined the company, research lived in Google Drive, with insights written in Google Slides. The process of finding user research meant digging through Google Drive folders. This was becoming more and more untenable as we accumulated more data.
The Head of Design and I had heard of Polaris (used at WeWork), a tool to search for user insights. We decided to implement an early, cheap version of that using AirTable, essentially documenting and tagging all user observations into a searchable excel-style database.
Airtable: Research repository as searchable database uncovers usability issues
What we did: All observations were organised, tagged, and analysed within the AirTable database. The dream was to create the one place for all stakeholders to access research, at any level of analysis:
Observations - descriptions of user behaviour, data points, quotes, or reviews
Findings - inferences on what each observation means about user needs
Insights - high level generalisations about user behaviour and intent
The above were input manually and tagged by theme, location, task, among others.
Airtable. Raw database view showing customer feedback and tags.
What worked:
For the research team: We gained experience in knowing how to organise our research at a higher level for product. The AirTable experience helped us to understand the appropriate level of data to input into a repository; and gave us a hands-on introduction to tagging and aggregating research.
For our stakeholders: the “frontpage” for research increased their appreciation for the sheer volume of data we had on hand. AirTable’s search functionality also made it very easy to find data based on keywords or tags.
What didn’t work:
For the research team: Data entry became very time consuming, with several hours per week used just for data entry. This was due to the complexity and number of tags for every individual observation.
For our stakeholders: AirTable was too complex and overwhelming, so that they instead asked researchers for help. Some stakeholders were also “cherry picking” observations by searching only for confirmatory data.
What we learnt:
For the research team: Ease of data input is equally important to the ease of data retrieval.
For our stakeholders: Observations should not be the base level for output; it needs to be refined to findings or even insights to prevent misinterpretation.
EnjoyHQ: Learnings and Changes
Wider context: The research culture in the company had grown:
The research team expanded from one person to three
The research team became proficient in using Confluence, resulting in greater visibility into product documentation
Research observation became a habit amongst stakeholders; PMs, designers and marketers would attend user interviews and discuss their observations after every project, leading to greater ownership and understanding of user needs
What we did: To improve usability, we wanted to move away from the database metaphor, and towards a wikipedia style of repository. Hence, we turned to external repository platforms like Dovetail and EnjoyHQ. After some market research, we decided on EnjoyHQ - where observations, findings and insights would be organised as Stories.
EnjoyHQ. Story pages, each with a headline describing the research insight.
What worked:
For the research team: Stories were much easier to create, with EnjoyHQ largely replacing Google Slides as the main medium for communicating research. Stories could be set up right after, or even during, a stakeholder discussion.
For the stakeholders: Stories could be linked to — which allowed for EnjoyHQ links to appear in Product pages on Confluence. Additional benefits included low level integration with Confluence and Jira, project management tools, transcription and tagging tools.
What didn’t work:
EnjoyHQ was rarely used by product managers or designers; researchers did most of the searching and linking to confluence documents
Switching between platforms (i.e.Confluence to EnjoyHQ and back) in order to use, plan and execute on insights was cumbersome.
What we learnt:
A pure self serve model for a research repository, on yet another platform, was not practical for the company culture at the time
Similarly, linking insights to product was extremely useful, but ran into a previously insivible issue of the hassle of switching platforms
Finally, working with Stories also gave the team training in writing up “SEO friendly” insights
Confluence: The Simplest Solution (for now)
Wider context: Thinking back to the objective of the research repository — I realised that all we really wanted was a simpler way to document research on a platform that was easily accessible and easily searchable. Which meant that bringing it closer to the stakeholders on Confluence could only benefit us.
What we did: We experimented with one project; where we use Confluence for all project management, including meeting minutes, discussion guides and insights. The result was a simpler and easier collaboration between Designer, PM and Researcher, as all relevant materials could be found on one platform.
Seeing a positive reaction, we decided to move all our insights from EnjoyHQ to Confluence, utilising headers and tags to keep observations, findings and insights organised.
Confluence. Insights housed and organised within the design/ research space, in parallel with product.
What worked: Confluence turned out to be a great way to manage research within a larger product.
For researchers AND stakeholders:
Research management and Project management became more tightly integrated, allowing for smoother collaboration. Confluence search - though not as powerful as EnjoyHQs (yet) - was good enough for researchers and some designers and PMs to find, link, and reference user needs.
What didn’t work: It became pretty clear the self-serve dream was dead. The optimal workflow was for designers and PMs (and other stakeholders) to collaborate with researchers, who would use Confluence as a shared tool to inform + document.
What we learnt: Confluence’s success uncovered more needs for a research repository
With a large backlog of previous research and a new collaborative workflow, we realised there was a need for research documents that sum up previous research data to find new insights (i.e. meta analysis)
Confluence was making headway with the working level stakeholders, but C suite stakeholders still found many research findings invisible or too cumbersome to wade through
Using a familiar user experience (e.g. Confluence) is preferable to a simpler but different one (e.g. EnjoyHQ)
What’s next: Some ideas for bringing research repositories forward as a collaboration and communication tool include
Meta analysis projects to sum up themes from previous work
Email newsletter aimed squarely at C suite stakeholders
Experimentation with Atlassian’s implementation of a large language model to supplement its search function