As part of our ongoing commitment to enhancing research capabilities and optimizing processes, we are excited to announce the launch of our Wayfair B2B and B2C insight communities. These branded research panels, comprised of our valued customers and suppliers, represent a dynamic platform for gathering insights directly from key stakeholders.
In line with this initiative, we are dedicated to empowering our direct stakeholders—UX researchers, product designers, and product managers—with the autonomy to independently initiate and conduct research within these communities. By reducing the need for end-to-end support from Research Ops, we aim to foster a culture of agility and ownership in our research endeavors.
To uphold the quality and integrity of research projects conducted within these communities, we have introduced a Quality Assurance (QA) request form. This form serves as a tool for relevant stakeholders to request quality checks on their studies before they go live, ensuring that each project meets our high standards for excellence and accuracy.
How can we support our direct stakeholders in QA-ing their research activities before launching on insight communities at a reasonable timeframe?
To understand how our stakeholders currently reach out to Research Ops for support, I mapped out all the flows on a MIRO board to identify where all current user touchpoints are.
After mapping out the user journey, I can see that our stakeholders reach out to us mainly in three avenues:
General Consultation (Office Hours)
Research Project Support
Communities of Practices (COP) / Strategic Initiatives
By assessing the past submitted request data, in addition to our team's general Slack channel, I noticed that Research Project Support and General Consultation are the two main avenues where we received formal QA requests for research activities.
I reported the findings to my immediate team and proposed a solution to build an embedded request system on the existing Research Calendar on Airtable, where all current and planned research activities are housed. The main advantages of creating this system on the research calendar are:
Users are already familiar with using the research calendar
Able to set up automated notifications to notify requesters of the status of their request
Easy to track the number of requests received
Above is an overview of the QA request ticketing system on Airtable. Once a research activity is added to the research calendar, the specific activity name and the requester’s name will auto-populate under the QA Ticket tab, where users can request a QA for their study if they need it.
There are two QA options for the users to choose from depending on their need:
This option is for any feedback on research brief (i.e. screener, survey questionnaires, etc.)
This option is to QA acitivities that have already programmed on the platform before launching
For the users, they are required to provide information on:
For Research Ops, once we receive a QA request, we will fill in:
Ticket Assignee
The member of Research Ops who picks up the QA ticket.
QA Status
Status of the QA
QA Feedback
Any feedback or suggestions we provide to users to program their activity on the tool platform or make changes before launching
I set up automated notifications on Airtable (task management software) throughout the request system to keep both users informed the status of their request and Research Ops informed when a ticket is submitted.
After the 3 months we implemented this QA request system, we noticed that:
Reduced chances of QA tickets getting lost in the process.
Reduced the rates of QA ticket’s resolve time to 3 days on average.
Users are satisfied with the communications that keep them informed about their request and able to plan their project timeline accordingly.