Managing the Administration of Researchers
UX Research by itself is difficult enough, but contending with ancillary administrative requirements can be a significant energy drain on the part of the Researcher and cause scope creep.
This is where Operations comes in to assist with moving these administrative tasks out of the way so that the Research team to shine without having to be bogged down with the details of recruitment, project tracking, remuneration and more.
What's in this Blog?
My Experience with Research Operations
Effective Project Tracking Methodology for Research
My Experience with Research Operations
I started assisting with Research before it was labeled "Operations". At the time, the most difficult part was simply defining the separation of responsibilities since I didn't want to overstep onto someone's personal preferences.
Mike Tse was the first one to specifically request assistance with facilitating Usability Testing because the weight of prototyping by itself was too demanding. And this was the birth of Research Operations at the company we worked at.
At the beginning of every Fiscal Quarter we would plan out UX Deliverables for Development and schedule in UX Research activities for usability testing, reporting, refining and presentation. We were clumsy, but the process was organically evolving into a predictable process that was repeatable, reliable and informative.
The three legs of Operations we devised was to (1) create and manage a repository for Research documentation, (2) Recruit, schedule and manage applicants for testing, and (3) plan and coordinate project tracking related to UX Research. There's more detail to each step, but this was the gist of how I was able to assist UX Research.
Research Repository
I created an easy documentation process that captures relevant data inputs into a framework that functions as a navigable repository at scale. Documentation needs to store qualitative annotation, details and the executive summary.
Recruitment
This was probably the most interesting activity in terms of establishing relationships with various gatekeepers for access and resources. There are four sources for applicants: In-house volunteers, Client Contact List, Vendor pools and Public domain. Each had its unique pros-and-cons, but two things were consistently essential: an approved legal contract for permissions and a budget for remuneration. There is a debate on the conflict of interest to reward usability applicants, however, having this established was better than not to have it.
Project Tracking
Establishing a system for Project Tracking was probably the easiest thing to do, but imposing a work agreement to follow consistently had its ups and downs. Honestly, the amount of Management push back was surprising at times.
Facilitation and Moderation
This is a fourth and unmentioned leg of Research Operations. At the time, UX Designers were expected to run the full gamut of UX responsibilities, including conducting their own Usability Testing. This is equivalent to a Developer conducting QA testing on their own code. It was fraught with bias and errors. These days, this isn't the case and there's a separate position solely dedicated to conducting UX Research.
Effective Project Tracking Methodology for Research
In order to properly celebrate and recognize all of Research's efforts, project tracking can do wonders to fill in the quantitative gaps, rather than relying on a couple of big, year-end presentations to showcase the impact it has as a department.
In my experience these are the challenges Research faces with project tracking:
Aligning Research activities to Fix Versions
Proper Components and Labeling
Utilizing Sub-Tasks for Applicant Tracking
Accounting for accountability
Aligning Research activities to a Product's Fix version will create a direct correlation where the time was spent. While this sounds relatively obvious, in practice it can be challenging. For example, if the Release Management Maturity score is low, then adherence to QA procedure of Fix Versions is inconsistent. Also, if UX Research operates as a separate team then cross container Fix Versions are slightly more difficult to synchronize. However, if done successfully, then a data viz could easily be drawn up to showcase Research's investment type and time into the Product.
Proper Components and Labeling of Research activity will identify the type of research that was done. Every Product team should have a basic Component identifying it as a "Research" activity, while the Label can specify the type of research. This will require the Research Team to coordinate on consistent labeling. If this is done successfully, then a data viz could identify what type of research was done most consistently, which product utilized the most research and which Researcher specialized on a specific method.
Utilizing Sub-Tasks for Applicant Tracking is a trick to track recruitment, success rates and remuneration. In Jira a Story can be made for "recruitment" and ten sub-tasks can be created to represent each applicant to be fulfilled. This Story can then be repeated to the Facilitation phase and if an applicant fails to appear, the sub-task can be marked as "abandoned". Finally, there can be a Story for remuneration with each sub-task containing the proper payment information for each tester. This Container however, will need to be classified as "restricted" to maintain the anonymity of names within the Research Team.
Accounting for accountability means that in order for Product Owners to consider the impact of UX, they need to be made accountable to report on how much research went into their Product. By filtering for the Story's Component in the Product, a simple breakdown of task types can be revealed. This required revelation will give Researchers a bigger voice during planning and a wider berth in deciding what, who, where and when research needed to take place for the PI, rather than be relegated as an afterthought.
In summary, by utilizing these efforts in project tracking, a Research team can do more to show the impact of their efforts to executive leadership. There are further nuances that can be drawn from project tracking, but the key is to keep the outcomes as an automated byproduct and not as a complex work agreement that will fatigue the team.
Fin.
Comments