Design Judgment in the AI-Native Product Era

This session is the entry point for the whole course. The visible topic is simple: what is design? The deeper purpose is more serious: learning how to observe a situation, name what matters, and turn that observation into a product decision.

Use seven words as your starting language: person, task, context, interface, friction, evidence, and decision. They are simple enough for day one, but serious enough to support product conversations later.

Work in a loop. First observe the object or screen. Then name what helps or blocks the user. Then ask AI or another person for another view. Finally, choose one improvement and explain why it matters.

Start with a real product screen. A fictional example can explain a concept, but an official reference shows that professional design has standards, constraints, language, and context.

Use the GOV.UK Design System start-page pattern as your first guided observation. You do not need to know public-service design. You need to practice seeing what a page is for, who it helps, what evidence is visible, and how the same purpose behaves across desktop and mobile.

Complete this guided reference before choosing your own object or screen. It gives you a benchmark for what strong observation sounds like.

The second real-world reference introduces a smaller but essential idea: a button is a promise. Ask what the action will do, what information makes it safe to act, and what uncertainty might still slow the user down.

The GOV.UK vehicle-tax start page is useful because the action is visible, but it is not floating alone. It is supported by the page title, explanatory copy, prerequisite information, helper text, and a clear relationship between desktop and mobile.

This submodule gives you a practical habit that will return throughout the course: never critique a button only by color, size, or style. Read the action, the support around it, the risk before it, and the result after it.

The third real-world reference teaches that trust is not a visual mood. Trust is built from information that lets the user decide whether it is safe, correct, and worthwhile to continue.

The Dart Charge page is useful because it asks the user to move toward payment, account setup, or fine handling. Before the button, the page exposes consequence, scope, required information, and an existing-account route.

This submodule gives you a sharper lens for checkout and payment patterns later. Stripe and Shopify can be used as official link-first references, but the screenshot anchor here stays rights-safe through GOV.UK.

The first AI interaction is part of the learning method, not a side activity. You are learning how to give AI enough context to be useful while keeping human observation in charge.

Start from a real tool entry point, then create a clean chat and paste the structured prompt. The first output is not the answer. It is material to inspect, accept, adapt, reject, and cite in your final decision.

The privacy rule is simple: use public pages, safe objects, redacted screens, or written descriptions. Do not paste private personal data, customer data, passwords, payment details, medical information, or anything you would not want reviewed by another person or partner assessor.

The first visual workspace is not assumed. You need to see where the tool begins, what file type to choose, what to name the board, what zones to create, and what evidence to save.

FigJam is useful here because it is an online whiteboard. The goal is to organize observation, AI critique, curation, and a final decision. You are not expected to create polished UI design in this first lesson.

The board is the first reviewable artifact. It should let a peer, reviewer, or future partner assessor see the path from human observation to AI critique to human decision without needing you to explain everything live.

This course is Product + Design + AI. Product is the field where the work matters. Design is the specialist capability that helps you see quality and shape user experience. AI is the accelerator that makes options, drafts, critique, and prototypes appear faster.

This first lesson is AI-native, but not AI-dependent. Use AI to think faster while also learning that generated output is not automatically good output. Your job is to give direction, inspect evidence, reject weak assumptions, and make the product decision.

The tool bench starts deliberately small but fully guided. Use one LLM and one visual workspace, then follow the first click, the first typed prompt, the first board labels, the first quality check, and the first saved screenshot or link. Beginner confidence comes from seeing the exact path before being asked to perform.

In everyday conversation, people often use "design" to mean appearance. In professional product work, design means more than appearance. It is the shaping of a product, service, object, or system so people can understand it, use it, and reach an outcome.

Human-centred design gives this lesson its academic foundation. ISO 9241-210 frames human-centred design around interactive systems across their life cycle. NIST summarizes the goal in practical terms: systems should be usable and useful by focusing on users, needs, requirements, human factors, usability, accessibility, and evaluation.

You do not need to read standards documents in Week 1. For now, use this simple definition with serious backing: design is the practice of making decisions that help people use systems well.

Decoration can matter. Color, imagery, mood, typography, brand personality, and visual polish all influence how a product feels. The mistake is treating decoration as the whole of design.

A button can be beautiful and still unclear. A form can be stylish and still too difficult. A screen can look modern while hiding the most important information. Good design asks whether the person can complete the task with confidence.

For a product owner, this distinction is vital. If the problem is decoration, the next decision might be about brand expression. If the problem is usability, the next decision might be about labels, sequence, information hierarchy, accessibility, or error prevention.

You do not need a large vocabulary in Session 1. You need a small vocabulary that can be used immediately. These six words make design talk more precise without turning the lesson into jargon.

The most important move is from opinion to evidence. "This is confusing" is a start. "This may be unclear because the page mentions an external service and SORN before the user starts" is a stronger design statement.

Everyday objects are excellent practice material because they make design physical. A kettle, door handle, microwave, medicine bottle, traffic sign, remote control, or washing machine already contains decisions about shape, labels, order, feedback, and safety.

The point is not to find a perfect object. The point is to slow down and see how the object teaches the user. A handle suggests where to hold. A switch suggests what changes. A light gives feedback. A label explains a state. A badly placed label or tiny measurement line creates friction.

This exercise protects confidence. You do not need drawing skill or software knowledge to begin. You only need to look carefully and explain what the object is doing for the person.

A product screen is also an interface. It teaches the user what matters, what can be done, and what happens next. A screen can fail even if it looks polished, because polish does not guarantee clarity.

Professional screen reading starts with purpose. What is the user trying to do at this moment? Then it looks for the primary action, information order, language, feedback, and accessibility. These areas connect directly to sources such as Apple interface guidance, USWDS accessibility guidance, and Nielsen Norman Group usability heuristics.

For Session 1, analyze only one screen at a time. Complexity will come later. A single public service start page, calendar event screen, food ordering screen, map screen, or checkout screen is enough.

Product ownership begins when design observation becomes a decision. A product owner does not only collect opinions. They help the team understand what matters, why it matters, and what should happen next.

This is why the artifact for Session 1 is a design observation and product decision sheet. You practice moving from "I noticed this" to "I would improve this first because it affects this user task."

This is also where startup relevance appears. In a fast startup, the team rarely has complete certainty. The product owner must make limited but thoughtful decisions: improve this, defer that, test this assumption, clarify this acceptance criterion, or ask for more evidence.

AI appears in this lesson as a study partner, not as a replacement designer. It can explain vocabulary, offer alternative readings, generate examples, and help you write clearer decisions. This is especially useful when you are new to design language or learning in a second language.

AI also creates risk. Figma's own AI guidance warns that AI outputs may be misleading or wrong and should not replace expert advice or research. NIST's AI risk work similarly reminds teams that trustworthiness must be managed. For this lesson, the simple rule is: AI can help you think, but you still check.

Good prompting is not a magic phrase. OpenAI's prompting guidance emphasizes clear instructions, audience, purpose, and iteration. For product design, that means providing context, naming the user and task, asking for evidence, and requiring uncertainty.

The course is AI-native from the first lesson, so do not only ask AI for critique. Also learn to critique AI-generated interface output. A generated screen can feel impressive because it has layout, color, cards, buttons, and confident language. That surface polish can hide weak product thinking.

This controlled sample is intentionally not a real product and not a recommendation. It is a safe practice surface. Inspect it with the same words used throughout Lesson 1: person, task, context, interface, friction, evidence, and decision.

The lesson is not full prompt-to-interface production yet. It builds the judgment habit that makes later AI production useful: label generated material, observe it carefully, challenge unsupported claims, accept/adapt/reject the output, and choose one scoped improvement.

A strong answer does not need advanced vocabulary. It needs specificity. It names the user, task, helpful decision, friction, evidence, AI curation, first improvement, and tradeoff.

The model artifact uses a real GOV.UK service screen to make the quality bar visible. The weak answer is not weak because it is short. It is weak because it cannot support action. The better answer starts to use evidence. The strong answer shows enough reasoning for a product team or external reviewer to understand the decision.

Use the model artifact as the reusable benchmark: the source screen, human notes, AI contrast, curation, decision, and tradeoff should all remain visible to a reviewer.

Use the studio exercise as practice, not as a quiz. Work through the first example using the model, then attempt a second example independently. If you get stuck, ask questions that return to evidence instead of rushing into redesign.

The target artifact is small but serious: one object observation, one screen observation, one AI-output critique, one prompt comparison, one FigJam or Figma observation board, accept/adapt/reject notes, and one product decision sentence. Small does not mean shallow. This artifact trains the exact habits used later in briefs, critique sheets, acceptance criteria, prototypes, and case-study writing.

Use the public handout to complete the artifact without guessing what strong looks like. Return to the model artifact whenever you drift into taste, copying AI, or redesigning too broadly.

Do not treat Lesson 1 as complete just because a page was read, AI produced a response, or a board exists. The standard is a reviewable reasoning trail.

Before moving to Lesson 2, your artifact should let another person understand what you observed, what AI added, what you accepted, adapted, or rejected, and why one decision is the next best move.

This gate is deliberately strict. It protects the course standard: design is not a list of tips, AI is not the final judge, and a product/design decision should be grounded in person, task, context, interface, friction, evidence, and tradeoff.

For home study, find three designed things: at least one everyday object, one app or web screen, and one service or sign. For each, answer: who is the user, what task are they trying to complete, what helps, what creates friction, what evidence supports the observation, and what would I improve first?

The readings below are optional professional references. You do not need to read all of them after Session 1. They are included so the lesson remains grounded in real professional sources while keeping the main study path accessible.