AI Collaboration 101: Brief, Generate, Check, Revise

Session 8 begins Week 3 by turning AI from a novelty into a disciplined work partner. The learner has now practiced design observation, screen reading, user-task-context framing, layout, actions, states, and interface copy. AI can accelerate all of those practices, but only if the learner brings structure and judgment.

The lecture should make one principle unmistakable: AI is useful because it expands and critiques thinking, not because it removes the need to think. The learner remains responsible for evidence, ethics, accuracy, prioritization, accessibility, and product decisions.

The artifact is an AI collaboration practice log. It should show the brief, prompt, AI output, human critique, verification checks, revision, accepted/adapted/rejected suggestions, and final decision.

The learner does not need to understand model architecture deeply to use AI responsibly, but she does need a useful mental model. AI can generate fluent patterns from instructions and context. Fluency is not the same as truth. Polish is not the same as evidence.

This distinction should be repeated often. AI can help the learner draft a product brief, list edge cases, compare options, rewrite copy, or critique a flow. It cannot know the actual user unless evidence is provided. It cannot take responsibility for the final decision.

The correct beginner posture is neither blind trust nor blanket rejection. The goal is calibrated use: trust AI more for low-risk drafting and less for facts, policy, user evidence, or high-stakes decisions.

The first professional shift is moving from delegation to collaboration. Delegation says: do this for me. Collaboration says: help me think, show me options, critique assumptions, and help me improve a decision I still own.

This matters because AI output can feel complete. It may be grammatically clean, structured, and confident. That feeling can hide weak assumptions, invented facts, missing user context, or product risk.

A Product Owner with AI-native habits uses AI to make thinking visible: What are the options? What are the risks? What evidence is missing? What should be verified? What decision should be made now?

The seven-step loop is the spine of the session. It turns AI use into a professional habit that can be inspected and improved.

The loop prevents two common failures. The first failure is under-briefing: asking AI for something broad and receiving generic output. The second failure is over-trusting: accepting the first output because it sounds fluent.

The learner should write the loop at the top of the practice log and use it every time: brief, generate, critique, verify, revise, decide, log.

A prompt is a brief. The learner should stop thinking of prompts as secret wording and start thinking of them as structured work instructions.

A strong prompt usually contains the task, context, constraints, desired output, success criteria, and any evidence the AI should use. If facts matter, the prompt should include source material or ask for source-based checking.

The prompt should also name what AI should not do. For example: do not invent user research, do not remove legal meaning, do not make claims without evidence, and mark uncertainty instead of guessing.

Context is the main difference between generic AI output and useful product work. A learner who asks for a landing page will get a generic landing page. A learner who gives a user, task, context, outcome, and constraints can get useful alternatives.

The context package should be small but specific. It does not need every detail. It needs the details that shape the decision.

The lecturer should model this by rewriting a vague prompt live. For example, "make this screen better" becomes "critique this laptop recommendation screen for a first-time university student choosing within a fixed budget; focus on clarity, trust, and next action."

AI is especially useful for expanding the option space. But options are only useful when they are meaningfully different. Three variations of the same answer do not create real choice.

The learner should ask for dimensions of difference. For product and design, useful differences include flow structure, information priority, amount of guidance, level of automation, risk reduction, and effort.

This section prepares the learner for Session 9, where options and tradeoffs become the main topic.

The first AI output is not the end. It is material for critique. A useful pattern is to ask AI to change roles: first drafter, then critic, then editor.

Critique should be specific. Asking "is this good?" usually invites shallow reassurance. Better critique asks against a rubric: user task, accessibility, risk, evidence, clarity, feasibility, and product outcome.

Human critique remains necessary because AI may critique according to generic norms. The learner should compare AI critique with the actual course principles and user context.

Verification is separate from generation. Asking AI to produce a better answer is not the same as checking whether the answer is correct.

The learner should verify at different levels. Fact claims need reliable sources. Product claims need user or business evidence. Interface claims need task fit, accessibility, and interaction logic. Technical claims need developer or system verification.

The higher the risk, the more formal the verification. Low-risk brainstorming can move quickly. Anything involving money, safety, health, legal meaning, private data, or public claims needs stronger checking.

Responsible AI use can be taught simply. The learner does not need a full governance program to understand basic risk habits. She needs to ask: What could be wrong? Who could be harmed? What data am I sharing? What must be checked? Who decides?

NIST frames AI risk management as continuous, not a one-time checklist. For this course, that becomes a habit: map the task, measure output quality, manage risk, and keep the human decision visible.

This is also where privacy boundaries belong. The learner should not paste raw customer data, confidential strategy, credentials, health details, or other sensitive material unless the tool and organization policy explicitly allow it.

The same principles that apply to AI products apply to personal AI workflows. People need to know what the AI can do, how well it can do it, what it is using, how to correct it, and when to take over.

Microsoft HAX and Google People + AI both emphasize expectation setting, trust calibration, correction, feedback, and control. These principles help the learner understand why an AI output should include uncertainty, assumptions, and verification steps.

The learner should also avoid over-automation. If a decision is important, AI can prepare the decision but should not quietly remove the moment of human choice.

This course is not teaching AI as a separate hobby. It is teaching AI as a multiplier for the Product Owner with design specialist capability.

For product work, AI can help turn messy thoughts into briefs, stories, acceptance criteria, edge cases, and tradeoff notes. For design work, AI can help critique screens, rewrite copy, map states, and generate alternatives.

The learner should keep the role boundary clear: AI helps produce and examine material; the human owns the product decision.

The practice log is the main artifact because it captures process. A polished final answer alone does not show whether the learner used AI well.

The log helps the tutor see the learner thinking: what context she provided, what she asked for, what AI produced, what she trusted, what she changed, what she checked, and what she decided.

This habit matters in teams. Product work needs traceability. If someone asks why a recommendation was chosen, the learner can point to the brief, tradeoff table, verification checklist, and decision sentence.

The Session 11 prompt is intentionally structured. It does not merely ask AI to be helpful. It asks AI to collaborate in a way that exposes assumptions, options, risk, uncertainty, verification needs, and human decision-making.

Learners should use the prompt on a small product or design problem, then inspect the output against the checks. The tutor should ask which AI suggestions were accepted, adapted, rejected, and why.

The most important rule in the prompt is that AI should not invent facts, research findings, metrics, policies, technical constraints, or user evidence. When it does, the learner should mark the issue and revise the brief or verification plan.

Use the course project as the worked example. The learner wants to improve a laptop recommendation screen. A weak prompt asks AI to make it better. A strong prompt gives the user, task, budget constraint, screen goal, known evidence, and output format.

The output should include three approaches, not one answer. For example: quiz-first, comparison-first, and shortlist-first. The learner then compares tradeoffs.

The human decision might be: I would choose comparison-first because it supports confident selection, but I would verify which comparison criteria students actually use before building it.

The studio output is one complete AI collaboration practice log. The log should show the work, not just the final result. It is acceptable if the first AI output is weak, as long as the learner identifies why and improves the brief or revision.

For home study, the learner should repeat the loop on one small task from the week: a UX copy rewrite, state map, layout critique, or user story. The goal is to build repeatable judgment, not collect impressive AI answers.

Close by previewing Session 9. Now that the learner can collaborate with AI safely, the next lesson will focus on generating and comparing options with tradeoff notes.