AI products have a unique problem: users often don't understand what the AI can and can't do. They either trust it too much or don't trust it at all. Testing an AI product means understanding both the usability side (can they figure out how to use it?) and the trust side (do they actually believe the output?).

I'd run moderated sessions with your target users where they actually use your product. I watch where they get confused, whether they understand what the AI is doing, and whether the workflow actually makes sense for them. Then I synthesize what I learned and tell you what to fix before you ship.

If you're building with Claude Code or other AI tools, I've done this kind of testing before and I know what tends to trip people up.

It depends on where you are. If you're early-stage and need research to inform roadmap decisions, a project-based engagement usually makes sense—you get research without the overhead. As you grow and research becomes ongoing, building internal research capability (or working with someone fractionally) makes more sense.

I do both. I can come in for a specific project—say, testing a new feature before launch—or I can work with you ongoing as a research advisor. The best setup depends on your team, your timeline, and what you're trying to learn.

Look for someone who actually cares about your users—not just the research methods. Anyone can run a survey, but it takes experience to know which questions matter and how to make sense of messy user feedback.

Good researchers ask good questions, push back on assumptions, and translate what they learned into actionable next steps. They're comfortable admitting what they don't know. And they can communicate findings in a way that actually changes how your team thinks about building.

If you're looking for someone to help you build research capability from scratch, that's different from hiring someone to run a one-off study. Make sure they have experience doing what you actually need.

I was a special education teacher before I became a researcher, so this is actually my bread and butter. I understand what it means to design for students who learn differently, and I know what it looks like when a product fails those users.

When I research EdTech for students with different learning needs, I'm thinking about: accessibility, clarity of instructions, how the product scaffolds learning, and whether the interface itself creates barriers. I also know the teacher side—what instructors need to actually use your product in the classroom.

Most teams design for the "average" user and then act surprised when edge cases break the product. Edge cases are usually where your most important users live—power users, users with constraints (accessibility needs, time, attention), users doing things in unexpected ways.

I find edge cases by actually watching how people use your product in context. What do they do when your happy path doesn't work? What do they misunderstand? I ask questions that help teams see users they weren't thinking about. And I recruit deliberately—not just average users, but people who represent different use cases and constraints.

If you're building for real people in real contexts (classrooms, clinics, busy teams), edge cases matter. That's where my research gets specific.

Not necessarily. If you have product-market fit questions that are actually blocking progress, research is worth the investment. If you're still figuring out the basic problem you're solving, you might not need formal research yet.

I've worked with everything from solo founders to enterprise teams. I can scale the engagement to match your stage. Sometimes that means a smaller project, or bringing in research at specific moments when you really need to understand something.

The worst thing you can do is guess about your users and build the wrong thing. If you have real uncertainty about who you're building for or what they need, let's talk.

Email me: monicabsherwood@gmail.com

Tell me what you're working on and what you're trying to learn. If it sounds like something I can help with, we'll schedule a call to talk through approach, timeline, and what it would look like.

No pressure, no long sales process—just honest conversation about whether this is a good fit.

I work with startups and established companies. Company size matters less than whether you're serious about understanding your users. I've worked with solo founders and teams of hundreds.

The one thing I won't do: research you don't actually plan to act on. If you're just collecting data to feel better about decisions you've already made, I'm not your person. But if you genuinely want to understand what's not working and you're willing to change based on what you learn, let's talk.

Yes. I've built research operations for teams that had zero research infrastructure. That includes developing research processes, training teams on how to talk to users, building recruiting pipelines, and setting up systems so research insights actually get used (not just reported and forgotten).

If you want someone to help you hire your first researcher, set up your research function, or train your team on research practices, I can do that alongside ongoing advisory work.

I research products that use AI and I design with AI tools. That means I've tested AI-driven features with real users, evaluated AI-generated content for quality and usefulness, and built custom research tools using Claude Code to speed up my analysis.

AI products have unique research needs. Users often don't understand what's happening behind the scenes, they sometimes trust the AI too much or not enough, and the UX of "here's what AI generated" is still pretty new. I've done enough of this work to know what questions to ask and what tends to work.