AI User Experience: What Victoria McClune Sees
Victoria McClune’s Silent Downgrade research asks how AI shapes answers before users prompt. See why UX, transparency, and accountability matter.
AI User Experience: What Victoria McClune Sees
The AI Answer May Be Shaped Before You Ask the Question
It's tempting to blame a disappointing AI answer on the prompt. Maybe it was too vague. Maybe the wording was off. Maybe you just need to try again with more context.
That's sometimes true - but it's not the only explanation.
Victoria McClune's Silent Downgrade research looks at a less obvious part of the interaction: how an AI system can shape what a user experiences before they ever send a specific prompt. McClune is a human-computer interaction designer and creative director. She got interested after noticing that her conversations seemed to change when children and healthcare were involved. So she started testing the model to figure out what might be driving that shift.
Her work raises a practical question for anyone using or buying AI: when an answer is unhelpful, how do you tell whether the problem is your prompt, the system itself, or the design of the interaction? This article walks through McClune's argument, what it means for businesses, and how teams can investigate AI experiences without assuming the user is at fault.
From interactive books to AI interfaces
McClune's career has moved with the big shifts in digital technology. While she was still in art school, she saw the arrival of the first iPads as a chance to rethink children's publishing. She founded a startup that built interactive books for that new platform, worked with Disney illustrators, and got recognition at South by Southwest. The company also leaned into remote work long before it was common.
But what's most relevant isn't just "how do we make the device work." It's the harder problem: how do you make something unfamiliar feel usable and clear to the people using it? She asked that again when she moved into augmented and virtual reality marketing, and later returned to the industry after the pandemic to study AI at MIT.
Her background in psychology, advertising, and interface design shows up in how she frames the issue. She's not a "model person" in the engineering sense - she identifies as a human-computer interface designer. That distinction matters, because a system can be capable on paper and still feel inconsistent, confusing, or stressful in real use.
The interface is part of the system
When people talk about AI, they often zero in on capability: how fluent the answers are, how many tasks it can handle, or how fast it responds. Those things matter - but they don't tell you how the product actually behaves.
A user interacts with a system, not a benchmark.
That system includes the interface, the policies and processes around the model, and the way the product handles different situations. Together, they shape what a user can do and what they take away from the output. If the system changes its behavior without making it obvious, the user may assume the failure is theirs: they didn't ask correctly, they didn't provide the right context, or they misunderstood how the tool works.
McClune's career offers a useful lens. Interactive publishing, VR campaigns, and AI don't just differ in technology - they differ in the relationship they create between a person and a designed environment. The key question isn't only what the technology can produce. It's what the person experiences while trying to use it.
What Silent Downgrade means
McClune's Silent Downgrade series looks at how AI systems can affect the quality of responses people receive. She started with a simple observation: once she introduced language about children and healthcare into her conversations, she felt the system treated her differently. She describes the experience as being "managed," and she began testing the model to understand what might be influencing the responses.
It's important to be clear about what this is - and isn't. This is an investigation and a design concern, not a claim that AI has intentions or acts like a sentient agent. McClune treats AI as predictive generative technology built from patterns in human-created information. Her focus is on how technical processes and design choices can combine into an experience users may not be able to see - or explain.
The room metaphor
McClune uses a room metaphor to describe the conditions around an interaction. A person enters the room and asks a question, but the room can influence what happens next. The user might assume the answer reflects only what they typed. Meanwhile, other factors could be shaping the response, including what the system is willing to do and how it communicates that to the user.
The metaphor is useful because it moves attention away from prompt-writing alone. Prompt quality matters, but it's only one piece. If someone keeps getting less useful answers in a specific context, telling them to rephrase over and over probably won't fix the underlying problem. The product team has to ask what else in the system might be affecting the experience.
Also, the metaphor isn't proof of a specific mechanism. The source account doesn't establish that a particular model deliberately downgrades specific users, and it doesn't identify a universal process that applies to every AI product. McClune's contribution is more general: to point to an area worth investigating. Users may experience shifts in response quality without getting a clear explanation for why.
Why the user may blame themselves
A lot of AI products quietly place the burden of interaction on the person at the keyboard. When the system misses the mark, the standard advice is to add more context, refine the prompt, or try another formulation. Those tactics can help.
But they can also become the default explanation - and that can hide system-level issues.
The practical consequences are real. Users spend more time experimenting, develop inconsistent workarounds, and can start to lose confidence - not just in the tool, but in their own ability to use it. In a workplace, that extra effort can get labeled as "AI productivity," even when employees are essentially doing extra work to get to an acceptable result.
A responsible investigation breaks the problem into three questions:
- What did the user ask? Look at the prompt and the context the user had available.
- What did the system do? Capture the response and any visible changes in the interaction.
- What did the user understand? Check whether the product explained what it was doing - or left the user guessing.
That separation doesn't assume the system is at fault. It just stops teams from blaming the user before they look at the evidence.
Why AI user experience is a business issue
McClune's point lands beyond research and ethics. Businesses are adopting AI because they want useful work done - customer questions answered, documents reviewed, internal information found, or routine tasks handled. But "works in demos" doesn't automatically mean "works reliably for employees in real life."
If people can't predict how the system will respond, they have to spend time checking, correcting, and retrying. Some of that is normal - AI outputs often need review. The business problem shows up when the product creates avoidable uncertainty and doesn't help users figure out what to do next. The result can be a tool that looks impressive in a presentation but gets expensive to operate at scale.
The hidden cost of confusing interactions
When a team evaluates an AI tool, it shouldn't stop at subscription cost and raw model performance. Operational cost includes the human effort required to make the system actually usable. That effort can show up as:
- Repeated prompt revisions to get anything useful.
- Manual verification because users can't tell when output quality has changed.
- Informal workarounds that differ from one employee to another.
- More support requests and more training time.
- Lower trust, which can lead employees to avoid the tool or use it inconsistently.
None of these prove the system intentionally treated someone differently. But they explain why user experience belongs in adoption reviews. If a product repeatedly makes users guess, it's not just inconvenient - it can reduce the value of the investment.
Bring more disciplines into development
McClune argues that people with expertise in psychology, communications, and human-computer interaction should have more influence in AI development. That's a practical call, not a demand to replace engineering. Engineers build and maintain the system; other disciplines can help teams understand how people interpret behavior, how expectations get set, and what users need to know when something changes.
A narrow development process can miss problems that don't show up in a purely technical evaluation. A model may produce something plausible, while the product gives the user no useful way to judge reliability. A workflow may look fast in a prepared demo but feel confusing in the middle of a real task. Those are product issues as much as model issues.
McClune is also skeptical about relying only on companies to self-regulate. Businesses have incentives to ship and to grow adoption. That doesn't automatically make self-governance useless, but it does mean accountability should include real scrutiny, clearer system behavior, and meaningful ways for users to challenge outputs.
A practical framework for teams adopting AI
McClune's work suggests a straightforward operating principle: don't treat a bad AI interaction as a prompt problem until you've checked the system - and the experience around it. You can apply that principle without pretending you'll be able to explain every model behavior.
1. Define the job before choosing the tool
Start with the task the product is meant to support. "Use AI to improve productivity" is too vague to evaluate. Define who the user is, what job they're doing, what counts as a good result, and what the system should not decide on its own.
For example, if a tool helps staff draft customer replies, spell out whether it's expected to produce a first draft, pull relevant policy details, or send responses automatically. Those are different workflows, with different risks and different review requirements.
2. Establish a baseline experience
Before rollout, test representative tasks and document what users see. Include common cases, hard cases, and situations where the system might need to ask for clarification or refuse to answer. Don't just score whether the final text looks good - track what steps users have to take, how clear the feedback is, and how much the user must verify.
A baseline gives the team a reference point when the product, model, or workflow changes. Without it, "it feels worse now" and "it seems fine" are both hard to investigate.
3. Test the whole interaction, not just prompts
Prompt testing is useful, but it should be part of a bigger test plan. Look at the interaction from the user's point of view:
- Is it clear what information the system can use?
- Does the interface explain what it's doing - and what it can't do?
- Can users tell when they need to verify an answer?
- Do similar tasks produce consistent enough experiences?
- What happens when users bring up sensitive or consequential topics?
The goal isn't to force identical answers from a generative system. The goal is to understand the range of behavior and whether users have enough information to use the system safely and effectively.
4. Give users a way to report the problem
A feedback button isn't an accountability process by itself. Someone has to review reports, look for patterns, and link user observations to product or policy changes. Collect enough context to investigate, while still respecting privacy and data-handling requirements.
When users report an interaction that felt different or unhelpful, don't ask only whether they wrote a good prompt. Ask what they expected, what changed, what they tried next, and whether the system explained itself. That creates a better record for design and operations teams.
5. Make changes visible and assign ownership
If model behavior, policies, or product flows change, teams should know who is responsible for assessing the effect on users. In a business setting, that owner may sit across product, engineering, operations, and risk - not just one function.
Documentation should match the impact of the tool. A low-stakes drafting assistant doesn't need the same controls as a system that influences consequential decisions. Still, in both cases, someone should be able to answer: what changed, who was affected, and how will we know whether the experience improved?
This framework won't reveal every cause of a surprising answer. What it does provide is something more practical: a repeatable way to notice, investigate, and respond - without treating user frustration as an individual failure.
Conclusion: make the system legible
McClune's main challenge to the AI industry is simple: pay attention to the person using the system, not only to what the model can generate. A user's experience is shaped by more than what's written in the prompt, and an unhelpful response shouldn't automatically be treated as proof that the user failed to ask correctly.
For businesses, that means evaluating the full interaction, measuring the effort needed to get a useful result, and giving users a way to report problems that leads to real investigation. For product teams, it means bringing people who understand behavior and communication into the work - not just the people building the technology.
AI systems will always have limits. The operational question is whether the product makes those limits understandable - and whether it gives users a way to handle them. If your organization is rolling out AI, pick one real workflow this week and watch where people retry, verify, or guess. Then assign someone to investigate what's driving it. That's a better starting point than telling people to write better prompts.