Scaling UX Research Through Maturity, Rapid Programs, and ROI with Thomas Stokes | Episode #89

Thomas Stokes chose UX research unusually early. During his first semester as a psychology major, a course asked students to investigate possible careers. His interest in cognitive psychology, perception, memory, learning, laboratory work, and statistics led him to human factors, human-computer interaction, and user experience. He mapped the courses, research-lab experience, graduate programs, grades, and entry requirements that could take him into the field.

Now co-founder and principal at DrillBit Labs, Stokes helps teams strengthen research through consulting, training, and research services. His conversation with Dwayne Samuels focuses on a practical challenge: making research effective enough to influence product work, fast enough to fit delivery cycles, and clear enough that stakeholders will fund it.

What you'll learn

• How to assess UX maturity through people, process, and technology

• Why industry differences often change research logistics more than core principles

• How a rapid research program can return design feedback within four days

• Why sound study design matters more than elaborate methods or terminology

• How ROI, success stories, and live observation can build stakeholder support

Assess maturity against available capability

Stokes has worked across medical devices, online education, open-source software, and other settings. Earlier in his career, the differences between industries seemed dominant. He now sees a common underlying shape: the same research and UX principles appear in different combinations of constraints and pain points. Documentation matters everywhere, for example, but medical-device work places greater emphasis on formal documentation than open-source software does.

That perspective also shapes his approach to UX maturity. He starts with three categories. People covers staffing, team structure, and the skills a team has compared with those it needs. Process covers how consistently, efficiently, and effectively research is conducted. Technology covers access to research platforms, tools, and budget.

Stokes cautions against treating a maturity model as a checklist of status markers. Some measures can become vanity metrics that say little about whether the team uses its resources well. A more useful assessment asks how effective the current practice is, what better performance could look like in six months or several years, and which specific gaps must close. This gives leaders a direction grounded in their own team rather than an abstract maturity level.

Make research repeatable enough for delivery

In fast-moving organizations, Stokes says research competes first with doing no research at all. The response is not to make every study larger. It is to make recurring research easier to request and execute. He describes rapid research programs built with clear guardrails, processes, documentation templates, and stakeholder expectations.

A team can define the inputs it needs for a quick design study, provide stakeholders with a short checklist, and commit to a predictable turnaround. In his example, a complete request delivered on Monday can produce findings by Friday. The arrangement resembles a service-level agreement: stakeholders know what they must provide, while researchers avoid rebuilding the operating process for every request.

This programmatic approach helps research match the cadence of product development. Teams can create a repeatable path for iterative testing while reserving deeper methods for questions that need them. The practical lesson is to standardize the mechanics without predetermining the evidence.

That distinction matters because Stokes identifies weak study design as a common research failure. A study can be flawed from the beginning when a team hunts for a preferred result instead of remaining open to what the data shows. Other errors occur when researchers make an analytical mistake or apply a finding to a context that is not truly comparable. Clear infrastructure improves speed, but unbiased design protects the quality of what comes back.

Prove value and keep building the craft

Stokes recommends combining three approaches when stakeholders are skeptical. First, calculate ROI. He describes a navigation project in which testing connected a proposed design change to fewer avoidable call-center contacts. By combining the expected reduction in calls with the cost of call handling, the team could estimate how quickly the work would pay for itself and what it could save over a year.

Second, turn the work into a concise success story. Explain the original problem, what the research revealed, how the design changed, and where the product or business ended up. Third, invite selected leaders to observe live sessions. Stokes recalls showing stakeholders who expected only a visual refresh how people in their target market actually struggled with the experience. Direct observation helped make usability problems difficult to dismiss.

For people entering UX research, his advice follows the same practical logic. Learn UX fundamentals, including usability principles and heuristics. Study research methods, then practice each method on a real experience instead of stopping at definitions. Stokes applies deliberate practice to his own writing, a skill he says did not come naturally and remains in progress.

Listen to Episode #89