On October 7, 2026, I had the opportunity to speak with students of the School of Computer Science and Engineering at Vellore Institute of Technology, Chennai, in an online guest lecture titled “Designing Human–AI Experiences with Claude: From Interaction to Intelligent Action.”
The session grew out of a question I keep coming back to:
Lecture’s Presentation
If AI can now generate screens, write code, explore ideas, analyse requirements and build prototypes, what should a designer actually be responsible for?
That question sounds simple. It isn’t.
AI has changed the speed of product work. It has changed how designers and developers collaborate.
But one thing hasn’t become cheap.
Judgment.
That became the thread running through the lecture.
The session brought together UX, product design, engineering, AI-assisted workflows, prototyping, product launch, Quantum Thinking, Quantum Coding, and the ideas behind my book, Judgment Is the Advantage.
The presentation itself was structured around product and engineering collaboration, working with designers, launching products, and building an AI-powered workflow. index
The conversation has changed
A few years ago, many conversations about AI and UX started with a practical question:
“How can AI help a designer?”
That was a useful question.
We could talk about generating UX copy, summarising interviews, creating personas, exploring user flows, making images, producing concepts, and speeding up repetitive work.
I had covered many of these ideas in an earlier guest lecture.
But the question has moved.
Now I think we need to ask:
“What happens when AI becomes part of the product itself?”
That shift is much bigger.
AI can sit behind a traditional interface. It can speak, see, generate, recommend, make decisions, call tools, and take actions.
The interface may still look like a familiar web or mobile screen, but the behaviour underneath it can be very different.
That changes HCI.
It changes product design.
And it changes the skills students need to develop before they enter the industry.
From designing screens to shaping decisions
I started the lecture by talking about my own experience.
I have spent more than 18 years designing digital products across healthcare, SaaS, FinTech, logistics, and AI. The products I have worked on have reached more than 60 million people. index
That experience taught me something early.
A product is never created by one discipline.
A designer can create a beautiful interface. A product manager can define a strong business goal. An engineer can build a technically impressive system.
None of those things, on their own, guarantee a good product.
The real work happens between them.
You have to ask:
Does this solve a real user problem?
Does it support the business?
Can we build it?
What does the system need to know?
And now there is a fourth question that matters more than it did before:
What does AI need to know?
That question changes the designer’s role.
You are no longer handing a set of screens to an engineer and walking away.
You are helping define the context, rules, intent, constraints, and decisions that shape what the AI produces.
That is a much bigger responsibility.
AI makes creation faster. That can create a new problem.
One of the strongest ideas in the lecture was simple:
More output does not mean more impact.
Imagine a designer who used to create three concepts in a day.
Now AI lets that designer create thirty.
Sounds great.
But what if the designer still doesn’t know which problem matters?
You now have thirty options instead of three.
That can make the work faster.
It can make the decision harder.
The same thing happens in software development. A developer can generate more code, close more tickets, and produce more changes. But if the team can’t review, test, and understand those changes, speed can turn into rework.
So I framed AI fluency as capacity, not judgment.
AI fluency gives you capacity. Judgment decides whether that capacity moves anything forward.
That distinction became one of the main themes of the session.
Why collaboration matters more now
AI doesn’t remove the need for product, design, and engineering collaboration.
It raises the stakes.
The presentation framed collaboration around three simple things: clear requirements, clear communication of intent, and explicit trade-offs. User stories, acceptance criteria, and edge cases can reduce back-and-forth.
Design discussions work better when teams share intent instead of passing around screens. Trade-offs become easier to handle when everyone can see what the team is giving up. index
This sounds almost old-fashioned.
Write things down.
Talk to each other.
Explain why.
Review the work.
Yet these simple habits become even more useful when AI enters the process.
Why?
Because AI can fill gaps very quickly.
If the requirements are vague or unclear, AI can invent the missing details.
The result can look polished.
That is where things get dangerous.
A polished answer can still be wrong.
The best AI systems start before the prompt
One of my favourite slides from the lecture said:
“The best AI systems don’t start with better prompts. They start with better inputs.”
This is a useful way to think about AI-assisted product work.
People often spend a lot of time trying to write the perfect prompt.
But a prompt can’t fix missing context.
If you want better output, start with five things:
Problem. What are we trying to solve?
Knowledge. What should AI know?
Constraints. What rules should it follow?
Direction. What exactly should it do?
Judgment. Is the answer actually good?
The lecture deck presents this as a design input framework for improving AI outputs. index
That last question is the one people skip.
AI gives you an answer.
You still have to decide if the answer deserves to survive.
So, how do I use Claude?
This was one of the more practical parts of the lecture.
I wanted students to see AI as part of a product workflow, rather than as a magic box that produces a final answer.
For example, I use Claude to examine requirements and edge cases, pressure-test decisions, work through long documents, and support coding work.
The presentation shows a simple example:
“Draft a PRD and user stories for in-app notifications. Include acceptance criteria and edge cases.”
Claude can turn that request into a structured starting point and flag scenarios such as offline delivery, rate limits, permission changes, and duplicate notifications. index
That is useful.
But I wouldn’t hand the whole product to Claude and say, “Great, ship it.”
I’d ask another question:
What did we miss?
Then another:
What assumption are we making?
Then:
What could break?
And finally:
How will we know this worked?
That is where the human part of human-AI collaboration becomes real.
Claude as a design partner
AI can help across several parts of the design process.
For UX copy, exploration, usability, andresearch, I can ask for different approaches to onboarding, empty states, or microcopy.
The lecture included examples of all four. index
The key is the word partner.
A partner doesn’t replace your thinking.
A partner gives you another perspective.
Sometimes the best use of Claude isn’t asking it to create something.
It is asking Claude to disagree with you.
“Find the weak assumptions.”
“Act like a skeptical product manager.”
“Review this flow as a first-time user.”
“Find accessibility problems.”
“Think like an engineer who has to maintain this.”
“Tell me why this feature should not ship.”
Those prompts can be much more useful than:
“Make this better.”
From prototype to something people can actually test
AI has changed prototyping too.
A prototype no longer needs to remain a static representation of a future product.
You can describe a product idea, define who it is for, explain what it needs to do, and ask AI to create a working exploration.
The process I shared was simple:
- Define what you’re building.
- Create a small product brief.
- Generate and refine the interface.
- Test it.
- Share it with stakeholders.
- Learn from the response.
The presentation describes this as a way to test product direction before pulling the full design or engineering process into the discussion. index
That can save a lot of wasted effort.
But there is a catch.
A prototype can now look real long before the product is real.
That means teams need to become better at separating appearance from evidence.
A convincing prototype is still a hypothesis.
The designer’s role is moving upstream
There was a slide in the lecture that showed the evolution of UX thinking:
1990s: Make it work.
2000s: Make it usable.
2010s: Make it responsive.
2020s: Make it frictionless.
Now: Make it meaningful.
The question shifts from:
“Can people use this?”
to:
“Is this the right thing to build?”
The deck describes this move as a shift from screen designer to decision architect. index
I like that distinction.
A designer who can produce screens is useful.
A designer who can help a team decide what deserves to become a product is much harder to replace.
That doesn’t mean visual design becomes irrelevant.
Far from it.
It means visual design becomes one part of a larger product skill set.
Feedback should be about outcomes, not taste
We spent time talking about design collaboration too.
This is something students often encounter only after joining a product team.
Someone says:
“I don’t like this.”
Someone else says:
“I prefer the other version.”
Then the design review turns into a debate about taste.
That’s a poor use of a design critique.
A better question is:
“What outcome are we trying to improve?”
The lecture covered four areas of design collaboration:
Feedback should focus on outcomes rather than personal preferences.
Design systems and branding create a shared language between design and engineering.
Critiques should focus on decisions and evidence rather than opinions.
Remote teams need clear documentation and async communication. index
Again, none of this sounds revolutionary.
That’s the point.
Good product work often comes down to simple things done consistently.
Then came the uncomfortable part: vibe coding
I wanted to spend time on coding because the relationship between design and development is changing fast.
AI can now generate working interfaces and code from natural language.
That creates an interesting shift.
The old model was:
Designer creates mockups → developer interprets them → developer builds the product.
The emerging model can look more like:
Designer explores → AI generates working front end → developer takes it into production architecture.
The deck calls this a move from design handoff to code handoff.
That is a major change for designers. index
But I challenged the idea that simply prompting AI and accepting the result is enough.
That is where I used the term Quantum Coding.
Quantum Coding: don’t ship what you haven’t understood
The phrase sounds technical.
The idea is actually simple.
If AI writes the code, you still own the outcome.
Quantum Coding asks you to do four things:
Document intent.
Tell the system what you are trying to achieve.
Validate assumptions.
Check that the AI understood the problem and the surrounding rules.
Test the result.
Don’t trust a working-looking interface. Test what it actually does.
Preserve the system.
Keep the code, architecture, documentation, and product behaviour understandable for the people who come after you.
This is where AI-assisted development differs from simply saying, “It works on my screen.”
A product isn’t a screenshot.
It is a system.
And systems have memory.
From idea to launch
The lecture then moved from creation to shipping.
This is where product judgment becomes very practical.
You can’t build everything.
You need to decide what matters now.
We looked at MoSCoW prioritization:
Must have: critical for the plan to work.
Should have: important, but not required for the first release.
Could have: useful if time or budget allows.
Won’t have: outside the current focus.
The deck uses this framework as part of the move from idea to launch. index
I like this framework for one reason.
It forces a conversation.
A team has to say no.
And saying no is a product skill.
AI can give you fifty feature ideas in seconds.
Someone still has to decide which three deserve engineering time.
Build something real, then learn from it
One of the strongest lines in the presentation was:
“Start with something real. Learn from usage. Then invest in what proves itself.”
That changes how we think about product launches.
A launch isn’t the finish line.
It’s another source of information.
Before release, the team should look at readiness, design and development QA, onboarding, rollout plans, and risk.
After release, the team should look at adoption, engagement, qualitative feedback, quantitative signals, retention, and business impact. index
This is where AI can help again.
I can ask Claude:
“What could go wrong with this feature? List the missing scenarios and edge cases.”
That gives the team another set of eyes.
It doesn’t permit the team to stop thinking.
That’s a key difference.
AI can be a pre-launch critic
One of the workflows I shared was using AI as a thought partner before release.
Ask it to look for:
- Missing states
- Permission problems
- Data migration risks
- Rollback issues
- Notification overload
- Unclear onboarding
- Failure paths
- Edge cases
- Confusing product behaviour
The deck gives an example where Claude identifies risks across data migration, permission states, rollback, and notification spam. index
This is a powerful pattern.
Don’t ask AI only to make your idea better.
Ask it to make your idea harder to defend.
That sounds strange.
It works.
A good critic can save a team from a bad decision.
The AI toolkit I shared
The session wasn’t tied to one tool.
Different tools can play different roles.
The presentation included:
ChatGPT for strategy and communication, including PRDs, brainstorming, summaries, and UX copy.
Claude for deeper analysis, requirements, edge cases, long documents, and coding.
Claude Design for design concepts, mock data, and rapid prototyping.
Notion AI for research, notes, and project plans.
Framer AI for interactive landing pages and quick prototypes. index
The point wasn’t to create a giant AI tool list.
Tool lists become outdated quickly.
The more useful skill is knowing what kind of thinking each tool should support.
The tool is secondary.
The task comes first.
Then we got to Quantum Thinking
This was the part where the lecture connected most directly with Judgment Is the Advantage.
I use Quantum Thinking as a name for looking at a product decision as part of a connected system.
You don’t look at the screen alone.
You look at:
Users. Business. Technology. Data. AI. Consequences.
A small interface change can affect support.
A new AI feature can change user expectations.
An automation can save time and create a new failure mode.
A recommendation system can influence behaviour.
A product decision is rarely isolated.
The lecture introduced seven principles:
- Think in systems, not screens.
- Make decisions, not deliverables.
- Look for signals, not assumptions.
- Think in probabilities, not certainty.
- Work in loops, not phases.
- Think about consequences, not features.
- Think with AI, not through AI.
The presentation describes Quantum Thinking as making decisions with the whole connected system in view. index
That last principle matters.
Think with AI, not through AI.
AI should extend your thinking.
It shouldn’t become the place where your thinking stops.
The Judgment Stack
I then introduced the Judgment Stack, a practical sequence for making product decisions.
It starts with:
Frame: What problem are we solving?
Context: What do we and the system know?
Evidence: Why do we believe this?
Constraints: What cannot change?
Options: What choices do we have, including doing nothing?
Trade-offs: What are we giving up?
Risk: What could go wrong?
Decision: What are we choosing, and who owns it?
Measurement: How will we know if it worked?
Learning: What changed our mind?
The idea is simple.
Don’t jump from a vague problem to a solution.
Give the decision some structure.
AI can help with almost every part of this process. It can generate options.
But the decision still needs an owner. index
One equation I wanted students to remember
Near the end of the lecture, I put one equation on the screen:
Capability × Context × Judgment × Verification = Impact
Think about that for a second.
Capability is what the tool can do.
Context is what it knows about your users, product, and rules.
Judgment is what you decide to ask it to do and what you decide matters.
Verification is how you know the result is correct.
Remove any one of those and the result can fall apart.
A powerful model with poor context can produce poor work.
Good context with weak judgment can produce the wrong thing very efficiently.
Great output without verification can create false confidence.
AI capability is only one part of the equation.
What does this mean for students?
This was probably the most important part of the lecture for me.
Students entering UX, HCI, product design, or software development are entering a strange market.
AI can already produce things that used to take hours.
So what happens to the skills that were built around producing those things?
The answer isn’t to ignore AI.
It isn’t to compete with AI at generating more pixels or more code.
It is to move up the stack.
Learn how to frame problems.
Learn how to research people.
And yes, learn the tools.
But don’t stop there.
A student who knows how to prompt Claude is useful.
A student who knows what to ask Claude, what context to provide, what to reject, and how to verify the result is much more valuable.
HCI is moving from interaction to intelligent action
This is where the topic becomes especially interesting for a lecture involving HCI and robot perception.
Traditional HCI often starts with an interface.
A person clicks something.
The system responds.
AI changes the loop.
Now the system can interpret intent, process context, generate an answer, and sometimes take an action.
The pattern becomes:
Human → Intent → AI → Perception → Reasoning → Action → Feedback
That raises a new design question.
If an AI system can act, what should it be allowed to do?
What should it ask permission for?
These are HCI questions.
They are product questions.
And, increasingly, they are engineering questions too.
That connection becomes even stronger when we move from software agents to robots.
A robot can perceive an environment.
It can interpret a command.
Then the human needs to know where control sits.
That is where judgment becomes even more important.
AI won’t replace the need for designers
I ended the main part of the session with a statement that can sound reassuring at first:
AI won’t replace designers, product managers, or engineers.
But I don’t think that means nothing changes.
A better way to say it is this:
The work will change.
Designers who spend most of their time pushing pixels will face different expectations.
Developers who spend most of their time writing routine code will face different expectations.
Product managers who spend most of their time turning meetings into tickets will face different expectations.
The professionals who learn to work with AI will have more capacity.
The professionals who pair that capacity with judgment will have more impact.
That’s the distinction I wanted the students to leave with.
The real advantage isn’t speed
Speed is easy to notice.
You ask for something.
The AI responds.
A prototype appears.
Code appears.
Copy appears.
Ten ideas appear.
It feels like magic.
But product work has never been limited by the ability to produce ideas.
It has been limited by the ability to decide which ideas deserve attention.
That problem doesn’t disappear when AI gets better.
It becomes more visible.
When everything becomes easier to make, choosing what should exist becomes harder and more valuable.
That’s why I keep coming back to the same phrase:
Judgment is the advantage.
A final exercise for the students
If I were to leave the students with one practical exercise, it would be this:
Pick a problem at your university.
Maybe it’s attendance.
Then ask six questions:
1. What problem are you solving?
2. What does the AI know?
3. What does the AI decide?
4. What can the AI actually do?
5. Where does a human need to approve the action?
6. What happens when the AI gets it wrong?
That small exercise can reveal a surprising amount.
It forces you to move beyond the interface.
You start thinking about data.
People.
Rules.
Actions.
Failure.
Responsibility.
And trust.
That’s HCI in an AI system.
From a guest lecture to a larger conversation
The VIT Chennai lecture was a chance to bring together many of the ideas I’ve been exploring through product design and my book, Judgment Is the Advantage.
The presentation itself ends with a simple message:
AI gives you more capacity. Collaboration helps you use it. Judgment decides where it should go. Verification tells you if you got it right. index
That feels like the right place to leave the conversation.
AI will keep getting better.
The tools will change.
Claude will change. ChatGPT will change. New design and coding tools will appear. The interface itself may change again.
Students entering HCI today may end up designing systems where there is no traditional screen at all.
But the core questions will remain.
What problem are we solving?
Who are we solving it for?
What should the system know?
And, perhaps the hardest question of all:
Should we build this at all?
That is where human judgment still matters.
And that is where I think the next chapter of product design begins.
Everyone can build now. So what are you for?
For me, the answer is becoming clearer.
You are there to decide what is worth building, why it matters, and when the machine should be trusted to act.
That is the advantage.
About the lecture
Guest Lecture: Designing Human–AI Experiences with Claude: From Interaction to Intelligent Action
Institution: Vellore Institute of Technology, Chennai
School: School of Computer Science and Engineering
Format: Online
Date: October 7, 2026
Speaker: Prince Pal Singh, UX Architect, Designer, and Strategist
The lecture deck was prepared as a practical session on product and engineering collaboration, AI-assisted design, prototyping, product launch, AI workflows, and the ideas behind Judgment Is the Advantage.
Explore the lecture deck: Design, Collaborate & Launch with AI
Read the book for free on Amazon Kindle: Judgment Is the Advantage