5 - AI-Assisted Design and Development Workflows

Tool	Primary Integration	Interaction Style	Context Window	Best For in HCI
GitHub Copilot	IDE extension (VS Code, JetBrains)	Inline real-time suggestions	Moderate (file/function level)	Rapid scaffolding of UI components and patterns
OpenAI Codex	API access; powers custom tooling	Prompt-based generation	Moderate	Custom design-system generators and embedded tools
Claude Code	Terminal / agentic environment	Multi-step reasoning and task execution	Large (multi-file / codebase level)	Complex refactoring, accessibility audits, large-scale design system work

Effective Prompting Strategies for Design Tasks

▶

Working with AI assistants on design and development tasks is not simply a matter of typing a request and accepting whatever comes back. The quality, relevance, and usability of AI-generated output is almost entirely a function of how well the prompt is constructed. A vague, underspecified prompt produces a generic response that may look plausible on the surface but fails to fit the actual project context — the wrong component library, missing accessibility attributes, hardcoded colors instead of design tokens, or markup that simply does not scale. Mastering effective prompting is therefore a core professional skill for anyone integrating AI tools into a design or front-end development workflow. This topic covers the foundational principles of prompt construction, how to refine prompts iteratively, how to embed accessibility and usability requirements directly into prompts, how to keep AI output aligned with an existing design system, and how to recognize and sidestep the most common prompting mistakes.

Principles of Effective Prompting

The single most important habit to develop is treating a prompt as a specification, not a casual question. When you ask a colleague to build a component, you naturally tell them which framework the project uses, what the component is supposed to do, who will use it, and how the output should be structured. The same level of context is required when prompting an AI assistant, because the model has no implicit knowledge of your project.

Specify the technology stack, component type, and design system constraints. An AI assistant that does not know your stack will default to whatever is most common in its training data. If your project uses React with TypeScript and Tailwind CSS, say so explicitly. If the component should follow Material Design conventions, name that. Consider the difference between these two prompts:

// Underspecified
"Write me a button component."

// Well-specified
"Write a primary button component in React with TypeScript. 
 The project uses Tailwind CSS v3 and follows our internal 
 design system. The button should accept a label prop, a 
 disabled state, and an onClick handler. Use the design 
 token class names `btn-primary` and `btn-disabled` rather 
 than inline Tailwind utilities."

The second prompt will produce output that is immediately useful. The first will produce a generic HTML button or a React component with inline styles, requiring significant rework before it fits the project.

Include the intended user context or task scenario. Describing who will use the component and what they are trying to accomplish helps the AI make appropriate decisions about interaction patterns, label text, and information hierarchy. For example, stating that a form is used by warehouse workers on a mobile device while wearing gloves implies large touch targets, high contrast, and minimal text input — context that meaningfully shapes a good design response. Without this framing, the AI may produce an interface optimized for a desktop power user.

Request a specific output format. If you need a React component, ask for a React component. If you need a standalone HTML/CSS snippet for a static prototype, say that. If you want the CSS delivered as a separate block rather than inline, specify it. Reducing format ambiguity means less post-processing. You can also request that the AI annotate the output with comments explaining non-obvious decisions, which makes the generated code easier to review and adapt.

Break complex design tasks into smaller, sequential prompts. Asking an AI to produce a fully functional, accessible, design-system-aligned, responsive data table with sorting, filtering, and pagination in a single prompt is likely to produce something that partially satisfies each requirement while fully satisfying none. Instead, build the output in stages:

Prompt 1: Generate the basic table structure in React with the correct column definitions and sample data.
Prompt 2: Add sorting behavior to each column header, using the aria-sort attribute correctly.
Prompt 3: Introduce a search filter input above the table and connect it to the displayed rows.
Prompt 4: Add pagination controls that follow WCAG 2.1 AA keyboard navigation requirements.
Prompt 5: Replace any hardcoded color values with design token variables from the project's token file.

Each stage produces a reviewable, testable artifact. Errors caught at stage 2 do not propagate into stages 3 through 5. This approach also creates a natural audit trail of how the component evolved, which is valuable for team communication and future maintenance.

Iterative Prompt Refinement

Generating a first draft is rarely the end of the prompting process. Skilled practitioners treat AI output as a starting point for a structured refinement loop, not a finished deliverable. This mindset shift — from "the AI wrote it so it must be fine" to "the AI drafted it and I will now direct revisions" — is what separates effective use from careless use.

Review AI-generated outputs critically before accepting them. When you receive a generated component, read through it as you would a colleague's pull request. Check whether the component actually does what was requested. Look for hardcoded magic numbers, missing edge cases, incorrect semantic HTML, and accessibility gaps. If the AI generated a modal dialog without a focus trap, that is not a minor style issue — it is a functional failure that will break keyboard navigation for all users.

Follow-up prompts can request targeted adjustments. Once you have identified a specific gap, describe it precisely in a follow-up prompt. Vague corrections ("make it look better") produce vague results. Specific corrections produce specific improvements:

// Vague correction
"The modal doesn't look right."

// Specific correction
"The modal is missing a focus trap. When the modal opens, 
 keyboard focus should move to the first focusable element 
 inside the dialog. Tab and Shift+Tab should cycle through 
 only the interactive elements within the modal. Pressing 
 Escape should close the modal and return focus to the 
 trigger button. Please update the component to implement 
 this behavior."

This level of specificity gives the AI exactly enough information to make the right change without introducing regressions elsewhere in the component. You can similarly request targeted adjustments to layout (reorder these two columns on mobile), color contrast (increase the contrast ratio of the placeholder text to at least 4.5:1), semantic structure (replace the <div> used as a list with a <ul> and <li> elements), or responsiveness (add a breakpoint at 768px where the two-column grid collapses to a single column).

Few-shot prompting improves alignment. When you provide one or more examples of the desired output directly inside your prompt, the AI can infer the expected code style, naming conventions, and structural patterns from those examples rather than falling back on statistical defaults. This technique is called few-shot prompting. For instance, if your project follows a particular component file structure, paste a short representative example into the prompt:

"Here is an example of a component in this codebase:

import React from 'react';
import styles from './Badge.module.css';

interface BadgeProps {
  label: string;
  variant: 'success' | 'warning' | 'error';
}

export const Badge: React.FC<BadgeProps> = ({ label, variant }) => (
  <span className={`${styles.badge} ${styles[variant]}`}>{label}</span>
);

Following the same pattern, create a Tooltip component that 
accepts a `content` prop and a `children` prop, and positions 
itself above the child element using CSS."

The AI now has a concrete template for file structure, TypeScript interface definition, className convention, and export style. The resulting output will require far less reformatting to match the rest of the codebase.

Document the prompting sequence. Keeping a log of the prompts that produced useful outputs — along with the model version and any relevant context — creates a reusable asset for the team. When a future task requires a similar component, a team member can start from a proven prompt sequence rather than rebuilding from scratch. This also supports reproducibility: if the output of a specific prompt needs to be revisited or audited, the prompt itself serves as the specification of intent.

Prompting for Accessibility and Usability

Accessibility is one of the areas where AI-generated code is most likely to fall short without explicit instruction. Models trained on large corpora of web code have been exposed to enormous quantities of inaccessible markup — missing alt attributes, click handlers on non-interactive elements, modals without focus management, forms without associated labels. Without a specific prompt requiring accessible output, the AI will often reproduce the statistical norm, which in this domain is unfortunately not the accessible implementation.

Always specify the accessibility level and relevant interaction patterns in the prompt. Do not assume the AI will produce WCAG 2.1 AA compliant output by default. Name the standard explicitly, and name the specific patterns you expect. For example:

"Generate a dropdown menu component in React that conforms 
 to WCAG 2.1 AA. It should implement the ARIA Authoring 
 Practices Guide (APG) Menu Button pattern. The trigger 
 button should have `aria-haspopup='menu'` and 
 `aria-expanded` toggled on open/close. Each menu item 
 should be a `<li role='menuitem'>` and should be keyboard 
 navigable with Arrow Up, Arrow Down, Home, End, and Escape 
 keys. Focus should return to the trigger button when the 
 menu closes."

This level of specification leaves little room for the AI to produce a dropdown that is only mouse-operable or that uses incorrect ARIA roles.

Request ARIA labels, roles, and live region attributes explicitly. For interactive components — dialogs, alerts, loading spinners, inline form validation messages — the presence or absence of specific ARIA attributes determines whether the component is usable by people relying on screen readers. Do not rely on the AI to infer these needs. Ask for them:

For a loading spinner: "Include a visually hidden <span> with role='status' and aria-live='polite' that announces 'Loading, please wait' when the spinner is active."
For inline form validation: "When the field contains an error, set aria-invalid='true' on the input and associate the error message element with the input using aria-describedby."
For an icon-only button: "Since the button contains only an icon with no visible text, provide an aria-label that describes its action, and set aria-hidden='true' on the icon element."

Ask the AI to explain its accessibility choices. Adding an instruction such as "After the code, provide a brief explanation of the accessibility implementation decisions you made" surfaces the AI's reasoning. This makes it easy to spot gaps. If the explanation mentions keyboard navigation but does not mention screen reader announcements, you know to probe that area in a follow-up. If the explanation is confident but incorrect — for instance, claiming that role='button' on a <div> gives it full button semantics without also noting the need for tabindex='0' and keyboard event handlers — you can catch and correct the error before the code is integrated.

Validate AI-generated accessible code with automated tools. No amount of careful prompting eliminates the need for automated accessibility testing. Tools such as axe-core, Lighthouse, or WAVE can identify a significant proportion of WCAG violations automatically. After integrating an AI-generated component, run it through at least one automated checker, and supplement that with manual keyboard navigation testing. Automated tools typically catch contrast failures, missing labels, incorrect ARIA usage, and focus order issues — exactly the class of errors most likely to appear in AI-generated code.

Design System Integration Through Prompting

One of the highest-value applications of AI in a design and development workflow is accelerating the production of components that conform to an established design system. However, AI models have no innate knowledge of your organization's specific tokens, component library, or documentation conventions. This knowledge must be supplied through the prompt.

Include design token names, color variables, and typography scales in prompts. If your design system defines a color palette as CSS custom properties — for example, --color-brand-primary, --color-text-default, --color-surface-raised — paste the relevant subset into your prompt and instruct the AI to use only those variables rather than raw hex values or Tailwind color utilities. Similarly, if your type scale defines named steps such as --text-body-md or --text-heading-lg, name them explicitly. This prevents the AI from introducing hardcoded values that will break when the design system is updated.

"Use only the following design tokens from our system. 
 Do not use raw color values or Tailwind color utilities.

 Colors:
 --color-brand-primary: #0052CC
 --color-brand-primary-hover: #0747A6
 --color-text-on-brand: #FFFFFF
 --color-surface-raised: #FFFFFF
 --color-text-default: #172B4D

 Typography:
 --text-body-md: 1rem / 1.5 (Inter, system-ui)
 --text-label-sm: 0.875rem / 1.4 (Inter, system-ui, 500 weight)

 Generate a Card component in React that uses these tokens 
 for all color and typography styling."

Provide a reference component to teach the expected code style. Alongside token definitions, pasting an existing, approved component from the design system gives the AI a concrete model to follow for structural patterns, prop naming conventions, CSS module usage, or styled-component syntax. This is a form of few-shot prompting applied specifically to design system alignment. The closer the reference component is to the component you are requesting, the more useful the analogy will be.

Request that the AI use only named design system components. If your design system includes a component library — for example, a Button, a TextInput, or a Select — ask the AI to compose new components from those primitives rather than building equivalent functionality from scratch with raw HTML and CSS. This keeps the output consistent with the rest of the product and avoids duplication that creates maintenance debt.

"The project uses our internal Polaris-based component 
 library. Compose the new FilterBar component using only 
 components from that library: <TextField>, <Select>, 
 <Button>, and <Stack>. Do not write custom CSS or use 
 raw HTML form elements."

Review outputs against design system documentation to catch deviations. Even with detailed prompts, AI output may introduce small deviations — a slightly wrong spacing value, a missing border radius token, or a state (hover, focus, disabled) that is not styled according to the design system specification. Establish a review step where generated output is compared against the relevant design system documentation before it is integrated. Catching a deviation at this stage costs minutes. Catching it after it has propagated across ten components costs significantly more.

Avoiding Common Prompting Pitfalls

Even practitioners who understand prompting principles can fall into patterns that undermine the quality of AI-generated output. Recognizing these pitfalls is as important as knowing the positive techniques.

Underspecified prompts produce generic outputs. This is the most pervasive pitfall. Generic outputs are not always obviously wrong — they may compile, they may render, they may even look approximately correct on first glance. The problem becomes apparent when the component is integrated into the actual project: the colors are hardcoded, the component is not keyboard accessible, the prop interface does not match the rest of the codebase, and the HTML semantics are incorrect. All of this rework could have been avoided with a more complete initial prompt. Before submitting any prompt, ask yourself: if a contractor with no knowledge of this project received this prompt, would they be able to produce something I could use? If the answer is no, add more context.

Accepting AI outputs without code review introduces risk. AI-generated code can contain security vulnerabilities — for example, unsanitized user input rendered as HTML, leading to cross-site scripting exposure — and accessibility failures that are invisible to the naked eye but significant in impact. It can also include deprecated API usage, incorrect dependency assumptions, or subtle logic errors. Every piece of AI-generated code should go through the same review process as human-written code. The existence of an AI in the pipeline does not change the responsibility for the quality of what ships.

Vague correction prompts shift rather than resolve problems. When a follow-up prompt says something like "fix the bug" or "make it more accessible" without describing the specific problem and the desired outcome, the AI is likely to make changes that appear responsive but do not actually address the root issue. It may add an ARIA attribute that is not the correct one, or refactor a section of code in a way that eliminates one bug while introducing another. Effective correction prompts name the problem, explain why it is a problem, and describe the specific outcome expected.

Prompts should be versioned or logged. A prompt that produced excellent output for a card component today may be exactly what is needed for a similar component in three months. Without a log, that prompt is lost. More importantly, the team cannot learn from it, adapt it, or share it. A simple approach is to maintain a shared document or repository of prompts organized by component type or task, annotated with the model version used and any known limitations of the output. This transforms individual prompting knowledge into a team asset and accelerates future work.

The following table summarizes the key dimensions of an effective design-task prompt and the consequences of omitting each one:

Prompt Dimension	Example of Inclusion	Consequence of Omission
Technology stack	"React 18 with TypeScript, using CSS Modules"	Output may use wrong framework, plain JS, or inline styles
Component type and purpose	"A dismissible alert banner for error messages"	Generic component that does not fit the interaction context
User context	"Used by screen reader users on mobile devices"	Accessibility and touch considerations may be absent
Output format	"Return a single .tsx file with no external dependencies"	Output may be split awkwardly or include unexpected imports
Accessibility requirements	"Conforms to WCAG 2.1 AA; use APG Alert pattern"	Missing ARIA roles, no focus management, poor screen reader support
Design tokens	Paste token names and values; instruct use of variables only	Hardcoded hex values that break on design system updates
Reference example	Paste an existing approved component as a style model	Inconsistent naming, structure, or CSS approach
Specificity of correction	"Add aria-live='polite' to the status message container"	AI makes unrelated or counterproductive changes

Effective prompting is ultimately a discipline of precision, context-setting, and critical evaluation. The AI assistant is a powerful collaborator that will follow your direction as closely as the specificity of your prompt allows. The more clearly you define the constraints, the context, the format, and the quality criteria, the more useful the output will be — and the less time you will spend correcting it. Over time, the prompts themselves become a form of institutional knowledge: a record of how the team thinks about components, accessibility, and design system compliance, expressed in a form that any team member can build on.

NotesCovers the full lifecycle of prompting for design tasks: initial prompt construction, iterative refinement, accessibility-specific techniques, design system alignment, and common failure modes. The included code examples and summary table support practical application in workshop or lab settings.

Videos on This Topic

▶

Working with an AI assistant on a design task is itself an interface problem. The prompt is the control surface: what you type determines what the system can do for you, and vague input produces generic, unusable output. In this topic we treat prompting as a skill with structure — giving the model role and context, stating the task and constraints, specifying the output format, and supplying examples when the format matters.

For interface work, prompts also need domain content. A prompt that asks for "a login screen" gets you a cliche; a prompt that names the target users, the platform, the design system tokens, the WCAG contrast and focus requirements, and the error states you must handle gets you something you can actually critique and refine. Refinement is the normal case, not a failure: you read the output, find where it drifted from your intent, and change one thing in the prompt to close that gap.

The three videos below move from practical technique to a research view of why prompting is harder than it looks. While watching, collect concrete patterns you can reuse — ways to supply context, to constrain output format, to ask the model to reason or to critique its own work — and note the failure modes: over-trusting a confident answer, changing many things at once between attempts, and assuming the model shares background knowledge you never stated.

Video 1: Prompt engineering essentials: Getting better results from LLMs | Tutorial

▶

GitHub · 9:02 · 187,147 views · 1y ago · captions — Watch on YouTube

About this video

GitHub's tutorial introduction to prompt engineering for developers, aimed at people who are getting vague or unusable answers from large language models. Based on its title and description, it covers the essentials of how LLMs interpret input and the components of a prompt that reliably improve results, such as supplying context, being specific about the task, and shaping the output.

Why this video

It comes from GitHub, a producer of widely used AI developer tooling, and it maps directly onto the Principles of Effective Prompting subtopic with a developer-facing vocabulary you will reuse when prompting for code scaffolding.

Video 2: Essential AI prompts for developers

▶

Visual Studio Code · 8:31 · 379,161 views · 2y ago · captions — Watch on YouTube

About this video

A Visual Studio Code video presenting four prompting techniques that generalize across AI tools and tasks, not just coding. Expect concrete, reusable prompt patterns demonstrated on practical examples, with attention to how rephrasing or adding structure changes the quality of the response.

Why this video

The focus on a small set of transferable techniques gives you a starting toolkit for iterative prompt refinement and for embedding design system or requirement details into prompts, and it comes from the team behind a mainstream AI-assisted editor.

Video 3: Why Johnny Can’t Prompt: How Non-AI Experts Try (and Fail) to Design LLM Prompts

▶

ACM SIGCHI · 8:37 · 2,022 views · 3y ago · captions — Watch on YouTube

About this video

A conference talk video from ACM SIGCHI presenting the research paper "Why Johnny Can't Prompt," a study of how people without AI expertise attempt to design prompts. It reports where non-experts go wrong — such as over-generalizing from a single success, treating the model like a person who shares their assumptions, and refining prompts opportunistically rather than systematically.

Why this video

This is peer-reviewed HCI research presented by its authors, and it directly addresses Avoiding Common Prompting Pitfalls and Iterative Prompt Refinement by naming the specific habits that make prompting fail.

How These Videos Support the Learning Outcomes

▶

Together these videos build the prompting competence the module outcomes depend on. The GitHub and VS Code tutorials give you the structural patterns needed to apply AI tools to generate layouts, content drafts, or code scaffolding that actually reflect your project requirements, which supports MO2, while also clarifying what these assistants can and cannot do in a design workflow (MO1). The SIGCHI research talk supports MO3 by showing that prompt outputs and prompting strategies both need deliberate evaluation: recognizing common failure patterns is what lets you judge AI-generated design output against HCI principles and usability standards rather than accepting the first plausible result.

About These Videos

▶

These videos were chosen from YouTube on October 3, 2026. Each has captions; the player turns them on. Videos on YouTube can be changed or removed — if one no longer plays, tell your instructor. If a player does not appear, use its Watch on YouTube link.

Review Dimension	What to Check	Common AI Failure Mode
Prop structure	All declared props are consumed; types are correct; required vs. optional is appropriate	Declares props that are never referenced in the template or logic
Event handling	Events follow framework conventions (emit vs. callback prop); event payloads are typed	Mixes React callback prop pattern into a Vue component
State management	Local state is minimal; derived values use computed/memos; no prop mutation	Copies props into local state unnecessarily, creating sync bugs
Lifecycle correctness	Side effects are cleaned up; subscriptions are unsubscribed	Adds document event listeners without corresponding removal
Accessibility	ARIA roles, labels, and keyboard interactions are present and correct	Adds role="button" to a div but omits tabIndex and keyboard handlers

Checklist Category	Key Questions
Accessibility	Are interactive elements keyboard reachable? Are ARIA labels present and meaningful? Is color contrast sufficient? Are form fields associated with labels?
Design System Alignment	Are spacing, typography, and color values drawn from system tokens? Do component names and variants match the design system vocabulary?
Code Clarity	Are prop and variable names descriptive? Are there unexplained hard-coded values? Is logic organized predictably?
Structural Correctness	Are component responsibilities appropriately bounded? Is state colocated correctly? Are there no prop mutation anti-patterns?
Test Coverage	Are test stubs present for key behaviors? Do tests exercise realistic user interactions?

Maintaining Design Quality in AI-Assisted Projects

▶

As AI-assisted design and development workflows become standard practice, one of the most pressing professional challenges is ensuring that what AI tools produce actually meets the quality bar that users, stakeholders, and ethical obligations demand. AI tools are powerful accelerators, but acceleration without direction produces mediocre or harmful outputs at scale. Maintaining design quality in AI-assisted projects is therefore not a passive activity — it requires deliberate, structured effort at every stage of the project lifecycle, from the initial brief through to deployment and iteration.

This topic examines the full landscape of quality maintenance in AI-assisted projects: what design quality means in this context, how to evaluate AI-generated interfaces against established heuristics, how to audit generated code for accessibility, how to review code for correctness and security, and how to ensure that the designer's original intent and user research findings are not gradually eroded by AI-generated suggestions that optimize for averages rather than for the specific needs of real users.

Defining Design Quality in the AI Context

Design quality is not a single measurable property — it is a composite of several distinct but interrelated criteria. Before any AI-assisted generation begins, the team needs a shared, documented understanding of what quality means for the specific project. Without this foundation, evaluation becomes subjective and inconsistent, making it impossible to give the AI meaningful corrective direction.

The five core criteria that define design quality in most human-centered projects are:

Usability: Can users accomplish their goals efficiently, effectively, and with satisfaction? Usability encompasses learnability, efficiency, memorability, error tolerance, and subjective satisfaction — the classic dimensions articulated by Jakob Nielsen and expanded by subsequent HCI research.
Accessibility: Can users with disabilities perceive, understand, navigate, and interact with the interface? Accessibility is not a feature; it is a baseline requirement that affects a substantial portion of every user population and is often mandated by law.
Visual consistency: Do all components, typography, color usage, spacing, and interaction patterns align with the design system and communicate a coherent brand experience? Inconsistency erodes trust and increases cognitive load.
Performance: Does the interface load quickly, respond immediately to input, and remain stable under realistic conditions? Performance is a design quality dimension because slow or unstable interfaces directly damage usability and user trust.
User need alignment: Does the design solve the problems that user research identified, for the people the research described? An interface can be usable, accessible, consistent, and fast but still fail because it solves the wrong problem.

The critical insight about AI tools is that they do not inherently optimize for any of these criteria. A large language model or generative design tool optimizes for pattern-matching to training data. It produces outputs that statistically resemble successful examples in its training set. This means AI will reliably produce outputs that look plausible — they will have familiar layouts, conventional interaction patterns, and syntactically correct code — without any guarantee that those outputs are usable for a specific audience, accessible to people with disabilities, consistent with a particular design system, performant in a specific technical environment, or aligned with the insights from a specific round of user research.

This distinction is not a criticism of AI tools; it is a structural fact about how they work. The practical consequence is that quality criteria must be externalized and documented before AI generation begins, so that human evaluators have explicit standards against which to measure AI output. A project design brief should capture these criteria concretely: usability goals tied to specific user tasks and success metrics, accessibility conformance targets (typically WCAG 2.1 Level AA at minimum), the active design system tokens and component library, performance budgets for key metrics such as Largest Contentful Paint and Time to Interactive, and a summary of user research findings that constrain the solution space.

Beyond the initial documentation, quality criteria must be revisited regularly throughout the project. AI-assisted iteration is fast, which means design drift — the gradual departure from original intent — can accumulate quickly. A component revised through five rapid AI-assisted iterations may end up visually and functionally quite different from the original brief without any single revision looking like a dramatic departure. Scheduling explicit quality checkpoints at each major milestone, where the current state of the design is compared against the documented brief, counteracts this drift.

Heuristic Evaluation of AI-Generated Interfaces

Heuristic evaluation is a usability inspection method in which evaluators examine an interface against a set of established usability principles (heuristics) and identify violations. It was formalized by Jakob Nielsen and Rolf Molich in the early 1990s, and Nielsen's ten heuristics remain the most widely applied framework. In the context of AI-assisted design, heuristic evaluation serves a specific and important function: it provides a structured, repeatable method for identifying exactly where AI-generated prototypes fall short, and it produces findings that can be directly translated into corrective prompts for the next AI-assisted revision cycle.

Heuristic evaluation should be applied systematically at each major iteration checkpoint — not only at the end of the project, and not only informally. Every time the AI generates a substantially revised prototype, evaluators should walk through the interface with the heuristics as an explicit checklist.

Nielsen's ten heuristics provide the standard framework, but three categories of heuristics deserve particular attention in AI-generated interfaces because they are areas where AI tools consistently underperform:

Error handling (Heuristic 5: Help users recognize, diagnose, and recover from errors; Heuristic 9: Help and documentation): AI-generated interfaces frequently produce error messages that are technically correct but unhelpfully generic ("An error occurred. Please try again.") or that use internal system language rather than plain user-oriented language. AI trained on large codebases has seen many such messages and reproduces them. Evaluators should specifically probe every error state in the prototype and assess whether the message explains what went wrong in plain language, suggests a concrete recovery action, and preserves user-entered data where possible.
Feedback mechanisms (Heuristic 1: Visibility of system status): AI-generated interfaces often omit or underspecify loading states, progress indicators, confirmation messages, and transition animations. These feedback mechanisms are often implemented as brief conditional snippets that AI either leaves as placeholders or generates too minimally. Evaluators should test every action that takes non-trivial time and every action whose completion is not visually self-evident.
Consistency (Heuristic 4: Consistency and standards; Heuristic 8: Aesthetic and minimalist design): Because AI generates component code and content somewhat independently, it frequently produces subtle inconsistencies: a button labeled "Submit" in one context and "Save" in another for the same action, slightly different spacing in similar components, or icons that do not align with the established design system. Evaluators should cross-reference the generated interface against the design system documentation and apply consistency checks across all instances of repeating elements.

When heuristic violations are found, the evaluation output should not be a vague note like "error messages need improvement." Instead, document each violation with enough specificity to drive a targeted AI revision prompt. A well-documented heuristic violation includes: the specific location in the interface, the specific heuristic being violated, a description of the observed problem, and a proposed direction for correction. For example:

Location: Checkout flow, Step 3 — Payment form
Heuristic: H5 – Error recognition and recovery
Observed problem: When the credit card number field receives an invalid input,
the error message reads "Invalid input." The message does not specify what
is invalid, does not indicate the expected format, and clears the field
contents on blur, requiring re-entry.
Proposed direction: Display an inline message specifying the issue
("Card number must be 16 digits, no spaces") and retain field content
on error so the user can correct rather than re-enter.

This specificity serves two purposes. First, it gives a human developer or designer precise guidance. Second, and equally important, it gives the AI a well-constrained revision prompt that is much more likely to produce a useful correction than a vague instruction.

Multiple evaluators should be involved in heuristic evaluation of AI-generated interfaces. Individual evaluators, on average, find only about 35% of usability problems in an interface; a group of three to five evaluators typically identifies 75% or more. This finding, established in Nielsen's original research, applies with equal force to AI-generated interfaces. Furthermore, designers and developers who have been closely involved in the AI-assisted generation process may develop a form of familiarity bias — they know how the interface is supposed to work and may mentally compensate for gaps without noticing them. Independent evaluators who approach the prototype fresh are more likely to surface genuine usability failures.

Accessibility Auditing of AI-Generated Code

Accessibility is one of the most reliably underserved quality dimensions in AI-generated code. The reason is structural: much of the code in AI training sets was written before modern accessibility standards were widely adopted, and even recently written code frequently contains accessibility errors. AI models that learn from this data reproduce these patterns. Studies of AI coding assistants have found that a substantial proportion of generated UI code contains detectable WCAG violations, particularly in areas like keyboard navigation, focus management, color contrast, and ARIA attribute usage.

A rigorous accessibility audit of AI-generated code has two complementary components: automated checking and manual testing. Neither alone is sufficient.

Automated accessibility checking with tools like axe (available as a browser extension, a CLI tool, and a JavaScript library for integration into CI/CD pipelines) or Google Lighthouse can catch a specific class of accessibility violations: those that are deterministically detectable from the DOM structure and applied styles. These include missing alternative text on images, form fields without associated labels, insufficient color contrast ratios, missing document language declarations, and certain ARIA misuses. Automated tools should be run on every AI-generated prototype before it proceeds to user testing. Running the check earlier — during code generation — is even better; the axe-core library can be integrated into component test suites so that accessibility violations surface in the same workflow as functional bugs.

However, automated tools detect only about 30–40% of real-world WCAG failures. The remaining violations require manual testing, which should focus on three areas that AI-generated code consistently handles poorly:

Keyboard navigation: Every interactive element in the interface must be reachable and operable using only the keyboard. Tab through the entire interface and verify that all buttons, links, form controls, and custom interactive components receive focus, that the focus order follows a logical reading sequence, and that no keyboard traps exist (situations where a user can tab into a component but cannot tab out). AI-generated custom components — dropdowns, modal dialogs, date pickers, carousels — frequently omit correct keyboard interaction patterns. For example, a custom dropdown that opens on click but does not respond to Enter/Space to activate, arrow keys to navigate options, or Escape to close is a keyboard accessibility failure even if it works perfectly with a mouse.
Focus management: When dynamic content changes — a modal opens, an error message appears, a page section is replaced — focus must be programmatically managed so that keyboard and screen reader users are directed to the newly relevant content. AI-generated code for dynamic interfaces frequently neglects this, leaving focus stranded in a now-irrelevant location after a state change. Manual testing requires triggering every dynamic state change and verifying that focus moves to a logical location and that the user's position in the interface makes sense in the new state.
Screen reader announcements: Use a screen reader (NVDA or JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android) to verify that interactive components are correctly announced with their role, name, and state, and that status messages and dynamic content updates are announced via live regions. AI-generated ARIA is frequently either missing (components with no semantic role), incorrect (ARIA attributes applied to elements that do not support them), or excessive (redundant ARIA that double-announces content).

When accessibility issues are found, they should be documented with reference to specific WCAG 2.1 success criteria. This serves both the human quality record and the AI revision prompt. A vague note like "fix accessibility" gives an AI tool nothing actionable. A specific note like "This custom select component fails WCAG 2.1 SC 4.1.2 (Name, Role, Value) because it uses a <div> element without a role attribute, and fails SC 2.1.1 (Keyboard) because it cannot be operated with arrow keys. Revise to use the ARIA Listbox pattern per the ARIA Authoring Practices Guide" gives the AI a well-scoped, testable target.

Accessibility remediation must be treated as a non-negotiable quality gate. It is tempting to defer accessibility fixes to a final polish phase, particularly when the pace of AI-assisted iteration is high. This is a mistake for several reasons. First, retrofitting accessibility into a complex interface is significantly more expensive than building it in correctly from the start — an AI-generated component with broken keyboard semantics may need to be substantially restructured, not just annotated. Second, accessibility failures expose the organization to legal liability in many jurisdictions. Third, and most fundamentally, treating accessibility as optional communicates to the team that some users' needs are considered less important, which contradicts the basic commitment of human-centered design.

Code Review Practices for AI-Generated Output

AI-generated code requires code review, just as human-written code does — arguably more so, because AI-generated code can appear superficially correct while containing subtle errors that a human reviewer would not make in the same way. AI tools have no understanding of the security context of the application, no awareness of the project's existing dependencies and their known vulnerabilities, and no ability to reason about performance at the system level. Code review fills these gaps.

A thorough code review of AI-generated output addresses four distinct dimensions:

Security vulnerabilities: AI-generated code is particularly prone to a class of security errors related to trust boundaries. The most common are: failing to sanitize user-supplied input before using it in DOM manipulation (creating XSS vulnerabilities), constructing database queries or API calls by string concatenation rather than parameterization (creating injection vulnerabilities), importing third-party dependencies without version pinning or security audit, and generating authentication or session management logic that follows outdated patterns. Reviewers should specifically look for any location where external input (from users, from APIs, from URL parameters) flows into the DOM, into a query, or into a privileged operation, and verify that appropriate sanitization, parameterization, or validation is applied. Tools like ESLint with security plugins, Snyk, or Semgrep can automate some of this detection, but they do not replace human judgment about trust boundaries in the specific application context.
Semantic HTML correctness: HTML elements carry inherent semantic meaning that serves both accessibility and SEO. AI-generated HTML frequently violates semantic conventions in subtle ways: using <div> and <span> for everything because they are the most common elements in training data, placing block-level elements inside inline elements, nesting interactive elements inside other interactive elements (a button inside a link, for example), using heading levels out of sequence, or using <table> elements for non-tabular layout. Reviewers should assess whether each element in AI-generated HTML is the semantically correct element for its content and role, not just whether it renders correctly in the browser. Rendering correctly and being semantically correct are not the same thing, and the difference matters enormously for screen readers, search engines, and the long-term maintainability of the codebase.
Performance implications: AI-generated code in component-based frameworks often introduces performance problems that are individually minor but collectively significant. Common patterns include: generating components that trigger full re-renders on every state change rather than using memoization or granular state updates, importing large libraries for single utility functions that could be implemented with a few lines of native code, generating large inline style objects that defeat CSS class caching, and producing deeply nested component trees that increase reconciliation cost. Reviewers should evaluate the performance implications of AI-generated code at the component level (does this component re-render more than necessary?) and at the bundle level (does this import contribute disproportionate weight to the bundle?). Performance profiling tools in browser DevTools and bundle analysis tools like webpack-bundle-analyzer make these patterns visible.
Prompt traceability: A practice that is not standard in human-authored codebases but becomes important in AI-assisted ones is requiring that each AI-generated contribution be traceable to a documented prompt. This serves accountability (who asked for this and why?), reproducibility (can this output be regenerated or revised from a known starting point?), and quality auditing (was this generated in response to a well-scoped, quality-conscious prompt, or an imprecise one?). One practical implementation is to maintain a prompt log in the project repository — a file or linked document that records each major AI-generation step with the prompt used and the commit or version of the output it produced. This does not need to be exhaustive for every minor autocompletion, but it should cover every AI-generated component or significant code block that becomes part of the production codebase.

The following table summarizes common AI-generated code quality failures by category, with indicative examples and review checks:

Category	Common AI-Generated Failure Pattern	Review Check
Security	Inserting user input into innerHTML without sanitization	Trace all paths from external input to DOM; verify sanitization library is applied
Security	Unpinned or unaudited third-party dependency imports	Run dependency audit (npm audit / Snyk); verify version pinning in package.json
Semantic HTML	Using <div onClick> instead of <button> for interactive controls	Verify every interactive element uses a natively interactive element or has correct ARIA role + keyboard handler
Semantic HTML	Heading levels skipped or used for styling rather than structure	Check heading hierarchy reflects document outline, not visual design preferences
Performance	Entire parent component re-renders on child state changes	Profile with React DevTools / equivalent; apply memoization where component renders are expensive
Performance	Full library imported for a single utility function	Check bundle impact with bundle analyzer; replace with native implementation or targeted import
Traceability	Undocumented AI-generated code block with no associated prompt	Require prompt log entry for all significant AI-generated contributions before merge

Preserving the Designer's Voice and Intent

Perhaps the most philosophically important quality challenge in AI-assisted design is maintaining the designer's voice — the set of deliberate, user-research-grounded choices that differentiate a design from a generic, pattern-matched solution. AI tools are, by their nature, convergent: they produce outputs that resemble the most common successful examples in their training data. In many situations this is useful; common patterns are common because they work. But differentiated design — design that is specifically calibrated to the needs, mental models, and contexts of a particular user group — often requires departing from common patterns, and AI will not make that departure unless explicitly directed to do so.

Four practices preserve design intent throughout an AI-assisted project:

Maintain a living design rationale document: A design rationale document records not just what decisions were made, but why they were made. For each major design decision — the information architecture, the primary navigation model, the onboarding flow, the error recovery approach — the document should record the user research finding or design principle that motivated the choice, the alternatives that were considered and rejected, and the criteria that will signal if the decision needs to be revisited. This document serves as a check against AI-generated suggestions: if an AI-generated revision changes a navigation pattern, the designer can consult the rationale to determine whether the change is an improvement or a regression toward a generic solution that the original research argued against.
Actively compare AI suggestions against user research: AI-generated interfaces should be evaluated not only against abstract usability heuristics but against the specific insights, behaviors, preferences, and pain points documented in the project's user research. If the user research found that the target audience has low digital literacy and relies heavily on contextual help, an AI-generated interface that eliminates in-context guidance in favor of a clean, minimal aesthetic is a quality failure even if it scores well on visual consistency and heuristic evaluation. The user research is the primary quality criterion; heuristics are useful but secondary.
Reject or revise AI outputs that produce conventional solutions where differentiation is required: This requires the designer to make an active judgment call. When an AI-generated solution is technically acceptable but produces a generic outcome in an area where the user research calls for something distinctive, the appropriate response is not to accept the output because it is "good enough." The designer should reject the output and produce a more constrained prompt, a reference design, or a manual revision that brings the output into alignment with the research-grounded design intent. This is the core professional skill of AI-assisted design: not prompt writing per se, but the evaluative judgment to know when an AI output meets the actual quality standard and when it merely meets a superficial standard of plausibility.
Regularly revisit original user personas and scenarios: User personas and usage scenarios are the most concrete representations of user needs in most design projects. As AI-assisted iteration accelerates, it is easy for these artifacts to recede from active use and become reference documents that nobody consults. Scheduling regular design reviews where the current prototype is walked through against each persona's primary scenarios — asking "Can this persona accomplish this scenario efficiently with this interface, given their described context, goals, and constraints?" — keeps the design anchored to the human reality it is meant to serve, rather than drifting toward whatever the AI finds most familiar.

Taken together, these practices constitute an active quality stewardship role for the designer in AI-assisted projects. The designer is not merely a prompt engineer or a reviewer of AI output — the designer is the holder of the project's understanding of its users, and that understanding must continuously inform, constrain, and when necessary override the AI's pattern-matched suggestions. AI tools accelerate production; the designer's critical judgment is what ensures that what is produced actually serves the people it was made for.

NotesThis topic covers the full quality maintenance lifecycle for AI-assisted design projects. The accessibility section references WCAG 2.1 AA as the standard minimum conformance target. The heuristic evaluation section references Nielsen's ten heuristics. The code review section includes a summary table rendered as a proper HTML table. All subtopics from the brief are covered with in-depth explanation and concrete examples including illustrative code blocks for documentation patterns.

Videos on This Topic

▶

AI tools can produce interface layouts, copy, and working code in seconds, but speed is not the same as quality. This topic asks a harder question: once an AI has generated something, how do you decide whether it is actually good? Design quality in an AI-assisted project still rests on the same foundations you have used all semester — usability heuristics, accessibility standards, consistency, and fitness for the intended users and context — but the review process changes because the output arrives faster, in larger volumes, and without a human author who can explain their reasoning.

The subtopics walk through a practical review pipeline. You first define what "quality" means for your project, then apply heuristic evaluation to AI-generated screens, audit generated markup and code for accessibility problems (missing labels, poor contrast, broken focus order, non-semantic elements), and establish code review habits that treat AI output as a draft from an unfamiliar collaborator rather than a finished deliverable. Finally, you consider how to keep your own design intent intact, so that the product reflects deliberate decisions rather than whatever the model happened to produce.

The three videos below approach this from complementary angles: using language models to critique UI mockups, simulating users to surface usability feedback, and the broader practice of using an AI model as an evaluator. While watching, note what each approach can reliably catch, what it misses, and where a human designer's judgment is still required. Pay particular attention to how evaluation criteria are specified — vague prompts produce vague critiques, while criteria grounded in heuristics or guidelines produce feedback you can act on.

Video 1: Generating Automatic Feedback on UI Mockups with Large Language Models

▶

ACM SIGCHI · 13:40 · 553 views · 2y ago · captions — Watch on YouTube

About this video

A conference talk from the ACM CHI research community presenting a system that uses large language models to generate automatic design feedback on UI mockups. Based on the title and authorship, it likely explains how a mockup is represented for a model, how feedback is grounded in design guidelines, and how the generated critiques compare to feedback from human designers or experts. Expect discussion of both the quality of the automated feedback and its limitations.

Why this video

It directly addresses heuristic-style evaluation of interface designs with AI assistance, and as peer-reviewed CHI research presented by ACM SIGCHI it models the kind of evidence-based, criteria-driven critique this topic asks you to adopt.

Video 2: SimUser: Generating Usability Feedback by Simulating Various Users Interacting with Mobile Applic...

▶

ACM SIGCHI · 9:30 · 189 views · 2y ago · captions — Watch on YouTube

About this video

Another ACM SIGCHI research presentation, this one on SimUser, an approach that generates usability feedback by simulating different kinds of users interacting with a mobile application. The talk likely covers how user personas or characteristics are modeled, how simulated interaction traces are turned into usability observations, and how the results were validated. It should also surface where simulated feedback diverges from real user testing.

Why this video

It extends evaluation beyond static screen critique to simulated use, which is useful when reviewing AI-generated interfaces quickly, and it prompts you to think carefully about which user differences a simulation can and cannot represent.

Video 3: LLM as a Judge: Scaling AI Evaluation Strategies

▶

IBM Technology · 6:09 · 52,743 views · 1y ago · captions — Watch on YouTube

About this video

A short, accessible explainer from IBM Technology on the "LLM as a judge" pattern — using a language model to evaluate the outputs of another model. It is likely to cover why automated evaluation is needed at scale, how evaluation criteria and rubrics are defined, and common pitfalls such as bias in the judging model and the need for human verification. The framing is general rather than design-specific.

Why this video

It gives you the conceptual vocabulary behind automated review and its reliability limits, which is exactly the caution you need when building code review and quality-check practices around AI-generated output.

How These Videos Support the Learning Outcomes

▶

Together these videos move you from understanding AI's role in the workflow toward critically judging what it produces. The two CHI talks show research-grade methods for evaluating interface designs and usability with AI support, giving you concrete models for applying heuristic and user-centered criteria to AI-generated layouts and code (MO3), while also illustrating how AI tools fit into real design and development pipelines (MO1). The IBM explainer supplies the underlying evaluation framework — defining rubrics, scaling review, and recognizing when automated judgment must be checked by a person — which supports disciplined review of the outputs you generate in your own project work (MO2, MO3).

About These Videos

▶

Consideration	What to Investigate	Why It Matters
Terms of service and output ownership	Does the tool's ToS grant you ownership of generated outputs? Does it claim a license to your inputs?	Without clear ownership, incorporating outputs into client work may create contractual or IP conflicts.
Training data provenance	Was the model trained on licensed, public domain, or mixed-license data? Does the vendor document this?	Outputs derived from copyrighted training data may carry unresolved IP risk.
Similarity flagging	Does the tool flag suggestions that closely match known training sources?	Flagged suggestions may require independent review or replacement to avoid reproducing licensed material.
Commercial vs. personal use	Do the tool's terms distinguish between personal, educational, and commercial use?	Some tools permit personal experimentation but restrict commercial deployment of outputs.
Client or employer requirements	Does the client or employer have policies on AI tool use or IP chain-of-title requirements?	Even if a tool's ToS permits commercial use, clients may require clean IP provenance that AI use complicates.

5 - AI-Assisted Design and Development Workflows

Introduction to AI Coding Assistants in HCI

Introduction to AI Coding Assistants in HCI

Videos on This Topic

Video 1: Get to know GitHub Copilot in VS Code and be productive IMMEDIATELY

About this video

Why this video

Video 2: Spec-Driven Development: AI Assisted Coding Explained

About this video

Why this video

Video 3: Use GitHub Copilot agent mode to create an application from scratch

About this video

Why this video

How These Videos Support the Learning Outcomes

About These Videos

Effective Prompting Strategies for Design Tasks

Effective Prompting Strategies for Design Tasks

Videos on This Topic

Video 1: Prompt engineering essentials: Getting better results from LLMs | Tutorial

About this video

Why this video

Video 2: Essential AI prompts for developers

About this video

Why this video

Video 3: Why Johnny Can’t Prompt: How Non-AI Experts Try (and Fail) to Design LLM Prompts

About this video

Why this video

How These Videos Support the Learning Outcomes

About These Videos

AI-Accelerated Prototyping Workflows

AI-Accelerated Prototyping Workflows

Videos on This Topic

Video 1: Figma & Claude Just Changed UI Design Forever

About this video

Why this video

Video 2: Claude + Figma = Design System Components

About this video

Why this video

Video 3: Cursor Tutorial for Beginners (AI Code Editor)

About this video

Why this video

How These Videos Support the Learning Outcomes

About These Videos

Maintaining Design Quality in AI-Assisted Projects

Maintaining Design Quality in AI-Assisted Projects

Videos on This Topic

Video 1: Generating Automatic Feedback on UI Mockups with Large Language Models

About this video

Why this video

Video 2: SimUser: Generating Usability Feedback by Simulating Various Users Interacting with Mobile Applic...

About this video

Why this video

Video 3: LLM as a Judge: Scaling AI Evaluation Strategies

About this video

Why this video

How These Videos Support the Learning Outcomes

About These Videos

Ethical Considerations and Professional Responsibility

Ethical Considerations and Professional Responsibility

Videos on This Topic

Video 1: AI Is Dangerous, but Not for the Reasons You Think | Sasha Luccioni | TED

About this video

Why this video

Video 2: How AI Models Steal Creative Work — and What to Do About It | Ed Newton-Rex | TED

About this video

Why this video

Video 3: How to Stop AI from Killing Your Critical Thinking | Advait Sarkar | TED

About this video

Why this video

How These Videos Support the Learning Outcomes

About These Videos