Building a functional Research Repository for 100+ People who do Research (2022)
Summary
By understanding the current processes, pain points, and the organization’s mental model around User Research, I created a Research Repository that was quickly adopted.
THE PROBLEM
Siloed Research led to difficulty finding research projects.
At AppFolio, each product development team was assigned to a specific Focus Area, such as a customer segment or product area. There were typically 3-6 development teams per focus area. Teams in the same focus area were well connected, but they were not very in tune with other areas.
Due to this siloed structure, the organization was experiencing two main problems:
Folks often didn’t know what other teams were working on.
It was very difficult to find previous completed research, especially if the person who conducted the research was no longer at the company.
This team had tried a few different tools in the previous 3 years, but each had been abandoned.
After digging into why the previous solutions had failed, it became clear that one of the main issues was that they required additional work outside of the existing documentation efforts. The engineers and QA team members were used to taking notes alongside PMs and UXDs, they wanted to have access to research so they could understand how it influenced what they we building.
Previous solutions further siloed research documentation
The previous solutions were not accessible by engineers or QAs on development teams so…
The “repository” documentation was siloed.
required duplicative efforts on the part of the Product and UX team members.
VENDOR EVALUATION
Flexibility to match our organization’s mental model became the #1 priority.
With an understanding of our needs, I facilitated 2–4 week pilot programs to evaluate vendors’ ability to meet employee and business needs. The vendor evaluation included participants from every role on the Product & UX Team. I asked participants to explore the tool and evaluate the ease of use of a set of specific tasks.
With this Ease of Use Evaluation, it was really easy to have conversations comparing the different tools we piloted. These pilot conversations revealed the importance of a tool that would allow real-time collaboration and flexibility across development teams. In the end, Coda was chosen as the best fit due to its flexibility, reasonable cost, and compliance with security needs.
BETA PROGRAM & IMPLEMENTATION
A two-month beta program with Coda laid the foundation for full implementation.
After deciding on Coda as our repository tool, I facilitated a beta program with about 10 team members from Product, Design and Research. I spent 2 months iterating on the templates that were introduced during the pilot program. I ran feedback calls with the beta participants and made many incremental changes to the project template and repository pages.
This iteration was incredibly valuable when it came time for full adoption. I was able to expand the templates to address a few tedious pain points - For example, instead of manually recording participant information for calls, I introduced a Google Calendar sync to allow automated call tracking across the team.
OUTCOME
The flexible repository created efficiencies and was quickly adopted.
After the beta program was complete, we implemented the new documentation system for the rest of the Product & UX Team.
The same team that had rejected 3 previous solutions embraced the new research repository and documentation system.
Within the first 60 days, over 80% of development teams had active project documents in the research repository.
In the year after its introduction, over 100 research projects were recorded.
Adopting new requirements & processes doesn’t have to be a battle.
When team members understand why a process has been introduced and see the benefits of efficiency in tedious tasks, adoption can be easy.