Understanding what people do
Contextual research, usability testing, task analysis, observation, simulation testing, click testing, heat maps.
UX Research · Customer Experience · Product & Service Research
I help organizations understand a customer, product, or service problem well enough to make a better decision about what to do next.
Sometimes you know exactly what is wrong. Sometimes you just know something is off and the explanations you have so far are not good enough. Several things may be going wrong at once.
Tell me what you're trying to figure outStart here
What Might Be Bringing You Here?
Several of these may be happening at the same time. Scan the situations below and open the ones that sound familiar.
Select a situation to see what may be underneath it and how I have approached similar problems.
People can't find what they need Navigation, structure, terminology, or something bigger may be getting in the way.
You're aware that something about the navigation, structure, terminology, or overall path through the experience isn't working as well as it should. Maybe people eventually get where they need to go, but not in the way you expected. Maybe it's hard to identify exactly where the problem is.
If the problem is in the interface
I've worked on improving information architecture, navigation, labeling, and task flow. That work has included card sorting, tree testing, contextual usability testing, click testing, and direct observation of where people get lost, hesitate, or make an unexpected choice.
If the problem is bigger than the interface
Sometimes the screen is just where the problem finally becomes visible. Different teams may own different pieces of the experience. Handoffs may be unclear. Terminology may have evolved separately. Nobody may have a complete view of what happens from one step to the next.
In those situations, the work means looking across the service, the people involved, and the way responsibility moves through the organization, not just at what appears on the screen.
People aren't using something the way you expected They hesitate, misunderstand it, abandon it, or create workarounds.
Something works, at least technically, but people hesitate, misunderstand it, abandon what they're doing, or come up with workarounds you never intended.
If the problem is in the experience itself
I've worked on identifying where people encounter friction, what they expected to happen instead, and whether the problem is tied to the design, content, workflow, or surrounding context. That work has included moderated and unmoderated usability testing, contextual research, task analysis, interviews, click testing, and observation.
If the problem is bigger than the experience itself
Sometimes people are doing something strange for a perfectly good reason. They may be compensating for a policy, process, handoff, organizational constraint, or gap between channels that the interface alone cannot fix.
I've looked beyond the immediate interaction to understand what else is influencing behavior and where the experience stops lining up with the way people actually need to work.
You're seeing drop-off, low engagement, or behavior you didn't expect The data shows the pattern, but not necessarily what is behind it.
Maybe people are abandoning a task, skipping a feature, failing to complete something, contacting support at a particular step, or taking paths through the experience that do not make much sense from the data alone.
If you need to understand what's behind the behavior
I've used interviews, contextual research, usability testing, diary studies, focus groups, and other qualitative methods to understand what people expected, what they were trying to accomplish, where they became uncertain, and why they made the choices they did.
If the cause may be outside the product itself
Drop-off or low engagement can reflect more than interface friction. Policy, process, prior interactions, channel handoffs, competing tools, or expectations set somewhere else can all shape what eventually shows up in product behavior.
The data may tell you where something happened. That does not mean it tells you where the problem started.
You want to de-risk a decision before committing more time or money Reduce avoidable uncertainty before the organization is too far down the road.
You may be considering a new product, service, feature, redesign, or major change and want to understand what could go wrong before the organization is too far down the road.
This is not risk management in the formal sense. It is about reducing avoidable uncertainty.
If you need to compare possible directions
I've used concept testing, prototype research, comparative studies, usability testing, interviews, task testing, click testing, and unmoderated research to understand where different options hold up and where assumptions start to break.
At some point, someone has to pick a winner. Better evidence can make that decision less dependent on instinct, internal politics, or whoever argues the hardest.
If the uncertainty is bigger than a design choice
Sometimes the more important question is whether the organization is solving the right problem at all, whether different groups are working from the same evidence, or whether an investment is being made on assumptions that have not been tested.
Research will not remove all risk. It can help make sure you are taking the risk with your eyes open.
You've made changes, but the same problems keep surviving them Redesigns and reorganizations happen. Somehow the problem keeps coming back.
You've redesigned it. Released updates. Changed the process. Added tools. Reorganized ownership. Maybe you've done all of those things.
And somehow, some of the same problems are still there.
At that point, the question is no longer just "How do we fix this?" It becomes "What keeps recreating this problem?"
If the problem is surviving product or service changes
I've looked across research findings, customer behavior, usability issues, and successive versions of an experience to understand which problems were actually resolved and which were moved somewhere else, temporarily reduced, or never addressed at the level where they started.
If the problem is surviving organizational change
Sometimes the same handoff, ownership gap, policy, incentive, or disconnect between teams survives every redesign around it. The visible experience changes. The conditions producing the problem do not.
I've looked across the broader experience and across cycles of change to identify what stayed put while everything around it changed.
You're getting customer feedback, but it isn't leading to enough change You may already be listening. The evidence may not have a path into decisions.
You may already have surveys, support tickets, research, reviews, analytics, frontline feedback, or several of them. The problem is not necessarily that nobody is listening. It may be that the information is scattered, important patterns are hard to see, or findings reach people who do not have a clear path to act on them.
If the problem is what you're hearing
I've worked on identifying gaps in what organizations know, where certain users or parts of the experience may be underrepresented, and what additional research could clarify what existing feedback cannot.
If the problem is what happens after you hear it
Sometimes the organization already has years of useful feedback. What is missing is a way to connect it across teams, establish ownership, decide what deserves attention, and make sure important findings can reach the people with the authority to do something about them.
There is not much value in collecting feedback forever if it has nowhere to go.
I've worked in environments where the harder challenge was building the connections, responsibilities, and governance that give existing evidence a path into actual decisions.
Different parts of the organization are solving different versions of the problem Product, operations, support, and leadership may all be seeing something different.
Product thinks the issue is usability. Operations sees a process problem. Customer support is hearing something else. Leadership may be working from a different set of signals again.
If the teams are working from different evidence
I've worked across research, product, service, and stakeholder groups to connect what each group is seeing, identify where the views overlap or conflict, and surface questions that still need better evidence.
If the problem is in the handoffs between teams
Sometimes each group is doing perfectly reasonable work within its own area and the experience still breaks between them. Bringing those perspectives together can expose gaps, clarify assumptions, and show where more information is needed.
There are things you are never going to know for certain. That is just true. But not every important decision belongs in that category. If you are deciding whether to launch something, change it, keep funding it, or kill it, you should know as much as you reasonably can before you make the call.
You need a baseline so you can tell whether things are actually getting better Establish a fair starting point before the next round of change.
Maybe a redesign is coming. Maybe a new service is launching. Maybe leadership wants to know whether the next round of changes made any difference at all.
If you need something to compare against later
I've worked on research designed to establish a starting point before changes are made, using measures such as task success, completion, comprehension, usability, confidence, satisfaction, or other indicators that make sense for the experience.
If the benchmark needs to survive beyond one study
The important part is deciding what is worth measuring, how consistently it can be measured, and what would count as a meaningful change.
Otherwise you do the work, come back six months later, and discover you have no honest way to tell whether anything actually improved.
You need to show whether a program, product, or service is actually helping Sometimes the question is simply whether what already exists is doing its job.
Sometimes the question is not what to build next. It is whether something that already exists is doing what it was supposed to do.
If you need evidence of whether it is working for people
I've used interviews, usability research, surveys, behavioral evidence, and other forms of evaluation to understand whether people are getting the intended value and where the experience may be falling short.
If the question is bigger than satisfaction
People can like something that does not work very well. They can also complain about something that is still producing real value.
The useful question is what success was supposed to look like, what evidence would actually demonstrate it, and what the evidence you have can honestly support.
Methods, in context
How I've Gone About Finding Answers
Different questions call for different kinds of evidence. These are some of the ways I've approached them over the years.
Understanding what people think, need, or expect
Interviews, focus groups, diary studies, structured group exercises, qualitative research.
Understanding how information should be organized
Information architecture research, card sorting, tree testing.
Testing ideas before committing to them
Concept testing, prototype testing, comparative testing, unmoderated research, click testing.
Looking for patterns across an experience
Journey analysis, qualitative synthesis, behavioral analysis, longitudinal research, feedback analysis.
Establishing whether something is changing or working
Benchmarking, baseline research, repeated measurement, program and service evaluation.
Making better use of what an organization already knows
Research planning, evidence synthesis, listening-capability assessment, identifying gaps in existing feedback, and governance around how findings reach decisions.
Selected work
What This Has Looked Like in Practice
Telehealth appStopping a Release When the Evidence Exposed a Larger Risk+
I worked on a feature inside a telehealth app intended to help patients discreetly signal that they had lost privacy during a video visit.
Research with people who had relevant lived experience surfaced risks and unintended uses that had not been adequately considered.
At that point, I did not think the responsible answer was to polish the feature and keep going. The question had changed from "Does this work?" to "Should this be released yet?"
I argued that it should not.
Consumer pharmacy websiteFinding a Problem Nobody Had Asked the Study to Investigate+
I was testing changes to an unsecured prescription-refill feature on a consumer pharmacy website when I noticed something odd: some people appeared to be trying to log in through the refill fields.
Nobody had asked me to investigate that.
But it kept happening across the variations being tested. Heat-map behavior supported the concern, and moderated research let me watch people do it directly.
At that point, deciding which variation performed better was almost beside the point. Both inherited the same problem.
Consumer pharmacy websiteRebuilding Navigation Around How People Actually Look for Things+
I worked on a major redesign of a consumer pharmacy website whose navigation and terminology no longer reliably matched how people looked for information or understood common pharmacy tasks.
I used extensive card sorting and tree testing to help restructure the information architecture and evaluate whether people could actually find what they needed.
A recurring lesson was simple: people do not owe an organization an understanding of its internal vocabulary.
If the structure only works after the customer learns how the company thinks, the structure is asking too much of the customer.
30+ healthcare appsConnecting Behavioral Signals, Feedback, and Operational Evidence+
I worked across a portfolio of more than 30 consumer-facing healthcare apps, where useful evidence was spread across analytics, private in-app feedback, public app-store reviews, research, and operational signals.
I regularly looked across those sources for patterns that deserved attention, including basic product-health issues such as crash rates that were not always being actively monitored elsewhere.
Sometimes the useful finding was not buried in an elaborate study. Sometimes it was simply recognizing that several small pieces of evidence were all pointing in the same direction and somebody needed to look.
Digital healthcare servicesResearching Both Sides of a Complex Service+
I worked on digital healthcare services used by both patients and clinicians, including tools for remote appointments and concepts for helping clinicians recommend digital health applications.
That meant researching not only the patient experience, but also the clinicians and staff responsible for recommending services, setting up appointments, reviewing information, and supporting the experience behind the scenes.
A customer-facing service can look perfectly understandable until you see what the people on the other side have to do to make it work.
Consumer pharmacy websiteTesting Whether People Understand Consequential Information+
On a consumer pharmacy website, I researched experiences where misunderstanding the language could affect what people believed would happen to their medication, money, or next step.
That included whether customers understood when they would actually be charged for an order, how they interpreted "refill" versus "new order," and whether terms such as prescription transfer meant what the organization assumed they meant.
These were not vocabulary quizzes. People had medications to get and money to manage.
The point was to stop making them answer questions the service could have answered for them.
About
I've spent my career researching products, services, and the people who have to use them.
Often that work has happened in large or complicated environments where the problem did not fit neatly inside one screen or one team.
My background is in UX research and customer experience, with work spanning healthcare, government, digital services, and organizational research.
Much of that work has taken place in confidential or sensitive environments, so the original artifacts are not always something I can share publicly. And in a lot of research work, the most important outcome is not a dramatic visual before and after anyway.
What I can share is the kind of problem I was working on, how I approached it, what I learned, and how that evidence helped inform what happened next.
Contact
If something here sounds familiar, tell me what you're trying to figure out.
You do not need to know what kind of research you need. You do not need to have the problem perfectly defined.
Just tell me what is happening.