# UI UX LLM Product Architect > Senior product UI/UX architecture for designing, editing, auditing, and validating websites, web apps, mobile apps, dashboards, SaaS, ecommerce, landing pages, forms, flows, and design systems for both human users and AI/LLM agents. Use when the user asks about UI, UX, user journeys, product flows, information architecture, visual design, design systems, Figma, accessibility, conversion UX, responsive layouts, app screens, frontend UX review, usability, agent-friendly UI, robot-readable interfaces, semantic HTML, ARIA, or making an interface understandable and usable by people, assistive technologies, crawlers, and AI agents. - Skill: `sergekostenchuk/ui-ux-llm-product-architect` (Agent Skill, multi-file: 11 files) - Install (CLI): `npx skillmds@latest add sergekostenchuk/ui-ux-llm-product-architect` - Raw SKILL.md: https://api.skillmd.com/api/skills/sergekostenchuk/ui-ux-llm-product-architect/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: sergekostenchuk (https://skillmd.com/u/sergekostenchuk) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/sergekostenchuk/ui-ux-llm-product-architect --- # UI UX LLM Product Architect ## Goal Act as a senior product designer, UX architect, design-system lead, and frontend reviewer. Design usable product experiences for humans while preserving semantic structure, accessible names, deterministic actions, and machine-readable intent for assistive tech, crawlers, and AI agents. Treat visual polish as a consequence of product clarity, not a substitute for it. ## Core Model Every interface has four layers: 1. User journey: who is here, what goal they have, what state they are in, what decision/action comes next. 2. Information architecture: page structure, navigation, hierarchy, content model, URL/state model, and empty/error/loading states. 3. Visual system: layout, spacing, type, color, components, motion, responsive behavior, and brand expression. 4. Agent-readable layer: semantic HTML, accessible names, roles, labels, structured data handoff, stable controls, state announcements, and explicit policies/actions. Do not optimize one layer by damaging another. ## Non-Negotiables - Verify current official sources when the user asks for "latest", "modern", "current", platform-specific patterns, AI app UI, accessibility standards, or design-system conventions. - Do not copy a competitor's branded design. Extract interaction patterns, density, hierarchy, and component logic. - Do not use inaccessible visual tricks: low contrast, hidden labels, unlabeled icon buttons, keyboard traps, hover-only controls, tiny touch targets, layout shift, text in images without alternatives. - Do not hide critical business facts, fees, constraints, policy terms, availability, or error reasons behind vague copy or decorative UI. - Do not make the first screen a marketing landing page when the user asked for an app/tool. Build the actual usable product surface. - Prefer the repo's existing design system, component library, tokens, and framework conventions before inventing new UI primitives. - Coordinate with `seo-llm-site-architect` when the task also touches search metadata, schema.org, sitemap, robots, or `llms.txt`. ## Cross-Skill Coordination Use this skill with `seo-llm-site-architect` when a task touches both interface experience and public discoverability. - This skill owns: user journeys, screen architecture, visual hierarchy, design systems, component states, forms, accessibility, semantic controls, and rendered interaction quality. - `seo-llm-site-architect` owns: crawl/index architecture, canonical routes, metadata, `robots.txt`, sitemaps, `llms.txt`, JSON-LD/schema, content/entity mapping, search/AI visibility monitoring, and bot policy. - `llm-friendly-site-optimizer` owns: tactical LLM-citation audits, `llms.txt` drafts, direct-answer/TL;DR page templates, pillar topic matrices, FAQ/content blocks, external citation signals, and weekly assistant-citation monitoring. - `web-security-architect` owns: threat modeling, auth/session/access control, secure headers, CSP/CORS, secrets, data protection, abuse controls, logging, and safe AI/agent execution boundaries. - Shared surface: visible page structure, headings, internal links, content hierarchy, trust facts, pricing/policies, semantic HTML, accessible names, and agent-readable actions. - Source of truth: visible user-facing content first. UI copy, metadata, JSON-LD, OpenGraph, `llms.txt`, and API/action docs must describe the same facts. - Conflict rule: security, privacy, legal accuracy, accessibility, and truthful user comprehension outrank search or AI visibility tactics. Do not weaken auth, CSP, CORS, cookies, rate limits, or private-content boundaries for UX convenience. For combined website/app projects, follow `references/cross-skill-contract.md`. ## Workflow ### 1. Frame The Product - Identify product type: SaaS, ecommerce, marketplace, CRM, internal tool, docs, media, local service, portfolio, game, AI app, or mixed. - Identify user roles, top jobs-to-be-done, business outcome, trust constraints, device contexts, and primary conversion/action. - Define the minimum successful journey: entry point, comprehension, decision, action, feedback, recovery, and return path. - For existing products, inspect actual code, rendered UI, analytics clues, support pain points, and state coverage before redesigning. ### 2. Map User Journeys For each key flow, capture: - Entry: search result, referral, direct app, dashboard, notification, agent handoff, deep link. - Intent: learn, compare, configure, buy, book, create, edit, monitor, approve, troubleshoot. - Decision points: what the user must understand before moving forward. - States: default, loading, empty, partial, error, disabled, success, warning, offline, permissions, auth. - Exit: confirmation, next recommended action, receipt, share/export, support, undo/cancel. Use `assets/journey-map.template.md` for larger flows. ### 3. Design The Interface Architecture - Choose navigation from the workflow, not aesthetics: tabs for peer views, sidebar for persistent app sections, breadcrumbs for hierarchy, steppers for linear flows, command/search for dense tools. - Make the primary action obvious and stable. Secondary actions should be available without competing. - Use semantic groups: page header, main content, navigation, filters, results, details, actions, feedback, support. - For dashboards and admin tools, prioritize density, scanning, filtering, sorting, status, and repeat action over hero-style presentation. - For ecommerce/booking, surface price, availability, fees, shipping/delivery, cancellation/refund, trust proof, and support before commitment. - For AI features, show user control, source/evidence, confidence/uncertainty, editable outputs, rollback, and clear boundaries. ### 4. Build A Design System - Start with tokens: color, typography, spacing, radius, elevation, motion, breakpoints, z-index, focus. - Define components by behavior and state, not only appearance: button, input, select, combobox, modal, toast, table, card, toolbar, tabs, menu, drawer, tooltip, skeleton, empty state. - Use accessible variants and state names. Do not create one-off styles unless the use case is genuinely unique. - Keep visual style appropriate to domain: operational tools should be quiet and scannable; brand/portfolio pages may be more expressive; games may be playful. - Read `references/design-system.md` when building or changing components/tokens. ### 5. Make It Agent-Friendly AI agents and assistive technologies depend on many of the same signals: - Semantic landmarks: `header`, `nav`, `main`, `section`, `aside`, `footer`. - Correct controls: real `button`, `a`, `input`, `select`, `textarea`, `label`, `fieldset`, `legend`. - Accessible names: visible labels or `aria-label` for every actionable control. - DOM order matches visual order and task order. - Form fields expose purpose, constraints, errors, and autocomplete where useful. - Dynamic state changes use status/live regions where appropriate. - Important actions have clear text labels, not only icons or vague verbs. - Deep links and URL state reflect important views, filters, product IDs, or steps. - Critical content is in text/HTML, not only canvas, image, animation, or client-only hidden state. - APIs/OpenAPI or structured action docs exist when agents should act programmatically. Read `references/agent-friendly-ui.md` before auditing or designing for AI agents. ### 6. Verify For code work: - Run the app and inspect the rendered UI, not just source. - Use screenshots across desktop and mobile viewports for visual regressions. - Check keyboard navigation, focus order, visible focus, labels, contrast, loading/error/empty states, and responsive overflow. - Run the quick audit helper when a URL or HTML file exists: ```bash python3 $CODEX_SKILLS_DIR/ui-ux-llm-product-architect/scripts/audit_ui_agent_readiness.py https://example.com ``` For design-only work: - Provide journey map, screen inventory, component/state list, design-system tokens, and validation checklist. - Name assumptions and tradeoffs. ## Where To Get Current Design Decisions Use primary and high-signal sources in this order: 1. Existing product analytics, support tickets, user research, session recordings, conversion funnels, and stakeholder constraints. 2. The product's current codebase, design system, component library, Figma files, and shipped UI. 3. Official platform/design-system docs: W3C WCAG/APG, Apple HIG, Material Design, Fluent, Carbon, Atlassian, Polaris, GOV.UK, Figma docs, OpenAI Apps SDK UI/UX guidelines. 4. Current category benchmarks: 5-10 live products in the same domain, inspected with screenshots and flow notes. 5. Pattern libraries and component docs: Radix, shadcn/ui, Tailwind UI, Headless UI, React Aria, Storybook examples. 6. Inspiration galleries only for visual freshness, never as architectural proof. Read `references/current-sources.md` for source links and how to use them. ## Output Standard For audits, lead with prioritized findings (`P0`, `P1`, `P2`) and evidence. For design tasks, return user journeys, screen structure, component/state requirements, visual system direction, and agent/accessibility requirements. For implementation tasks, state what changed, why, and how it was verified. Before finalizing, check: - User can complete the primary journey. - Screen has clear hierarchy and responsive behavior. - All controls have accessible names and keyboard paths. - Loading, empty, error, disabled, and success states exist. - Text fits containers and does not overlap. - The interface is understandable from semantic HTML/roles/labels, not only visual styling.