--- name: consumer-ux-director description: Use before building or redesigning any Consumer AI Factory prototype UI. Converts product ideas and taste references into concrete artifact-level UX direction, blocks generic SaaS/AI-wrapper pages, and requires side-by-side browser QA before calling a rebuild done. version: 1.0.0 author: Hermes Agent license: MIT metadata: hermes: tags: [consumer-ai, ux, design, prototypes, quality-bar] related_skills: [consumer-ai-demand-probe-prototype, design-md, popular-web-designs, dogfood] --- # Consumer UX Director ## When to use Use this skill before: - Building a consumer AI prototype. - Redesigning a landing/product page. - User says UI/UX is weak, generic, or not different enough. - Creating a demand-probe page for the Consumer AI Factory. - Claiming a prototype is “showable.” Do not start implementation until this skill produces a concrete UX direction. ## Core purpose Prevent the agent from making polished-but-generic pages. This skill exists because prior prototype work changed copy, trust language, and styling while preserving the same skeleton. Antoine correctly said the pages looked basically the same. The fix is not nicer CSS. The fix is artifact-level product direction before coding. ## Inputs to gather 1. Product idea or existing product. 2. Target user and concrete user moment. 3. Current page/repo, if any. 4. Antoine's relevant good/bad examples. 5. The Consumer Prototype Quality Bar. 6. Existing screenshots or local URLs for side-by-side comparison. If examples are available, use Antoine's examples over random references. Do not invent taste from brand names. ## Required reference files If working in the Consumer AI Factory, read these when available: - `/Users/antoinelevy/Documents/Obsidian Vault/Consumer AI Company Factory/01 Playbooks/Taste Reference Library.md` - `/Users/antoinelevy/Documents/Obsidian Vault/Consumer AI Company Factory/01 Playbooks/Consumer Prototype Quality Bar.md` - `/Users/antoinelevy/Documents/Obsidian Vault/Consumer AI Company Factory/01 Playbooks/a16z Top 100 Gen AI Apps - UX Reference Scan.md` ## Forbidden behavior Do not say: - “Make it feel like Apple Settings + Wise.” - “Use an Airbnb/Notion vibe.” - “Premium SaaS dashboard.” - “AI copilot for X.” Unless translated into concrete screen decisions. Bad direction: > Make it like Suno. Good direction: > Put the core creation surface in the hero. Use one input-as-CTA, one primary Create button, and finished artifacts around it showing what the user gets. Bad direction: > Make it feel like character.ai. Good direction: > Use one high-quality visual world plus an overlapping conversion card, but add product-specific examples because this brand has no existing recognition. ## Required UX brief Before implementation, produce this exact brief. ### 1. User moment One sentence: > The user is [person] in [situation] trying to [job] without [pain]. Example: > The user is a homeowner staring at scattered bills, tenancy docs, repair emails, and renewal reminders trying to know what needs attention this week without manually organizing every document. ### 2. Product artifact What object does the user get or interact with? Must be specific: - Home command center. - Weekly parent digest. - Relationship coaching pod. - Product photo before/after. - Source-backed answer. Not acceptable: - Dashboard. - AI copilot. - Assistant. - Platform. ### 3. First viewport spec List what is visible without scrolling: - H1. - Product artifact. - Primary CTA. - Secondary CTA, if any. - Trust cue near the action. - One proof/source/example detail. ### 4. Primary interaction What can the user do immediately? Examples: - Click to talk. - Type prompt and create. - Inspect a source. - Add first bill. - Forward first school email. - Open sample digest. ### 5. CTA hierarchy Define: - Primary CTA. - Secondary CTA. - Tertiary/nav/legal. The primary CTA must match the artifact interaction. ### 6. Trust/anxiety map List anxieties and exactly where they are handled. Example: - “Will you need my bank login?” handled next to Start setup: “No bank login.” - “Will you contact my school?” handled next to Start pilot: “Parent reviews everything; no school contact.” - “Can I verify the AI?” handled inside artifact with source excerpts. ### 7. Explicit removals List what must be removed from the old/current pattern. Examples: - Remove generic feature cards. - Remove chip rows. - Remove giant textarea. - Remove repeated explanation sections. - Remove fake metrics. - Remove old dashboard skeleton. ### 8. Visual direction as concrete decisions Do not use vague analogies. Specify: - Background/color role. - Focal object shape/position. - Type scale. - Number of cards/panels allowed. - Image/artifact requirements. - Interaction affordances. - Density limits. ### 9. Acceptance criteria A good brief has pass/fail checks: - First viewport contains product artifact. - First interaction is obvious. - Less explanatory copy than v1. - No generic AI/SaaS phrasing. - Trust cue appears near the risky action. - New version is visually/materially different from v1. ### Directory / marketplace redesign requirement When redesigning a directory, app store, marketplace, catalog, or category-heavy discovery product, do not jump directly from taste references to UI edits. First create a structured research/content matrix that can fuel both design and growth surfaces. Minimum outputs before major implementation: - UI trends/rules matrix covering discovery/search tools, UX rules, current trends, fonts, styles, shapes, cards, comparison, trust, mobile, and SEO. - Category-specific matrix covering user moment, visual direction, typography/shape cues, content modules, trust/proof needed, SEO angle, and examples for each current category. - Export the matrix to a reusable workbook when the user asks for research or when category content can become a growth asset. - Convert the matrix into implementation artifacts: `DESIGN.md`, category content data, richer category landing pages, and card/detail-page decision signals. #### AI app-store / agent-directory product lesson If the product is a consumer-facing AI app/agent directory, the UX must not drift into protocol, MCP, routing, developer-infrastructure, or abstract “discoverability layer” language unless the user explicitly asks for that surface. Antoine corrected this during AgentAppStore work: for consumer positioning, rebuild around simple app-store language and hide backend/discovery complexity. Use this default direction for consumer AI app stores: - Product promise: `We have an app that does what you want.` - Naming/copy: prefer “apps” over “agents” when speaking to consumers; reserve “agents” for technical/internal surfaces only if needed. - Homepage: one consumer task search surface, example matched apps, category entry points, and minimal explanation. Do not lead with MCP, APIs, routing, protocols, logo marquees, or generic SaaS feature grids. - Discover/search: let users describe the job in natural language; show fit reasons, price, category, tools/integrations, and trust cues. Keep filters secondary and simple. - Cards: answer “should I try this?” before the click — job/outcome, price, category, tools/integrations, trust/proof, and a clear details CTA. - Category pages: treat them as SEO and learning surfaces, not just filtered lists. Include user moment, “how to choose,” category learnings, trust checks, comparison criteria, SEO phrases, recommended apps, and FAQs. - Detail pages: structure around what the app does, who it is best for, works-with/integrations, pricing, data/safety/trust checks, useful links, reviews, and similar alternatives. - Submit/listing pages: ask publishers for the consumer job/outcome and proof, not only technical capabilities. - Explicitly remove or de-emphasize MCP/developer routes from the primary consumer nav unless the product strategy says developer distribution is the current goal. Fail condition: a redesign that only enriches category pages while leaving homepage, discover/search, cards, and app detail pages in the old skeleton is not a full marketplace rebuild. ### Reusable factory artifact naming If research is meant to improve launches across multiple Consumer AI Factory ventures, do **not** name or file the vault artifact as if it belongs only to the first venture that produced it. Antoine corrected this explicitly: a design research workbook created during AgentAppStore work should become a factory-level launch/design system artifact, with the first venture treated as a use case. Use this storage pattern in the factory vault: - Factory-level reusable artifacts: `01 Playbooks/ - .md` and matching workbook/file. - Venture-specific implementation notes: `05 Ventures//...`. - Opportunity-specific market research: `04 Opportunity Research//...`. Naming examples: - Good: `Consumer AI Launch Design Research System - 2026-05-17.md` - Good: `Consumer AI Launch Design Research System - 2026-05-17.xlsx` - Avoid for reusable systems: `AgentAppStore UI Design Research - 2026-05-17.md` The note should state that the originating project was the first applied use case, not the owner of the artifact. For AI agent/app-store products specifically, use the linked reference: `references/agent-directory-marketplace-design-research.md`. For consumer app-store rebuilds, also use `references/consumer-app-store-featured-inventory.md`. A consumer positioning change is incomplete if the actual homepage/category featured inventory still highlights mostly generic model assistants, developer tools, enterprise agents, or protocol/API surfaces. Inspect the data source for `featured` rows or homepage selection logic and explicitly replace/curate the first visible apps toward true consumer-life jobs. When Antoine says or implies the redesign should change the whole product, use `references/marketplace-full-surface-redesign-scope.md` before opening or merging a PR. Treat category-page enrichment, research workbooks, DESIGN.md creation, or copy-only repositioning as necessary but insufficient. The PR must explicitly cover the full decision journey — homepage, search/discover, cards, detail pages, category pages, submit/contributor flow, developer/API/MCP pages, global nav/footer, mobile states, shared visual system, and the actual featured/listing inventory — or be labeled as a partial slice before merge. For apps where the core promise is turning content/advice into offline behavior, use `references/action-conversion-loop-products.md`. In screenshot reviews and redesign briefs, check whether the full loop is visible: better input → interpretation/coaching → one concrete real-world action → completion reflection → progress signal. Do not let these products collapse into a content grid, generic chatbot, or habit checklist. For sensitive photo/visual-proof products, use `references/visual-proof-assets-for-sensitive-photo-products.md` before generating or requesting hero imagery. Generate the exact asset shape the product needs: if the UI needs two separate weekly photos/uploads, create two standalone images, not a side-by-side collage that must be cropped. QA for same person, same framing, subtle/non-diagnostic changes, no accidental app chrome, and no shame-coded transformation imagery. For group consensus products such as friend dinner planning, use `references/group-dinner-consensus-social-artifact.md`. Antoine rejected DinnerVote designs that looked like dashboards, command centers, or synthetic ticket/card walls. Default to the social artifact: a realistic group-chat surface with the consensus card posted inside it, plus direct share/vote/copy/book actions. The user should understand the group outcome before they understand the algorithm. ### Full-surface redesign pitfall Do not merge a green PR merely because it improves a valuable part of the product. If the user asked for “everything” or the conversation established a new product premise, run a pre-merge scope check and state what remains unchanged. A partial redesign presented as the transformation creates false progress and erodes trust. If the old homepage, search, cards, detail pages, docs/contributor pages, or nav still carry the previous skeleton, the redesign is not done. ## DESIGN.md requirement Every serious prototype must have a `DESIGN.md` before implementation. It should include: - Product promise. - User moment. - Product artifact. - First viewport layout. - Visual system. - Component rules. - CTA rules. - Copy rules. - Trust rules. - What not to build. - Browser QA checklist. Use the Consumer Prototype DESIGN.md template if available. ## Side-by-side QA requirement For redesigns, do not overwrite only the old page. Create: - current version: `/index.html` - new version: `/v2.html` Then: 1. Open old page in browser. 2. Take visual QA screenshot/assessment. 3. Open new page in browser. 4. Take visual QA screenshot/assessment. 5. Ask explicitly: does v2 look materially different and better? If not obvious, fail and iterate. ## Redesign implementation lessons When applying the UX brief, preserve these practical lessons from the Homebase OS v2 rebuild: - Add the new page to the build config, not just the dev route. For Vite multi-page prototypes, update `vite.config.js` Rollup inputs with the v2 HTML file and verify production build output includes `dist/v2.html`. - Keep the new visual direction in a separate CSS file when doing a side-by-side rebuild. This prevents old skeleton/styles from leaking into the v2 page and makes comparison honest. - After Antoine approves a v2 direction and explicitly says to kill the previous version, promote the approved artifact to the canonical route instead of keeping a permanent v1/v2 split: copy/adapt `v2.html` into `index.html`, remove `v2.html` from Rollup inputs, delete the separate v2 file, update `DESIGN.md` QA instructions, and add tests/searches that catch stale links or old-version copy. Side-by-side is for evaluation; once chosen, the product should have one main surface. - Do not stop at the hero when promoting a better direction. Rebuild the whole user-facing flow with the same design OS: checkout/start, post-payment setup/source submission, generated artifact/dashboard, legal/support pages, empty/local-preview states, and trust copy near risky actions. - Check sample data for market, currency, geography, and price consistency. Mixed examples like UK tenancy/council-tax language with US-dollar pricing make the prototype feel fake even if the layout is good. - Browser QA should inspect the H1 after the visual pass. A visually strong artifact can still be weakened by vague/clunky headline language; patch the headline and re-run first-viewport QA. - Full-page screenshots with sticky headers can create fake or real-looking overlay defects because Playwright captures sticky elements at the current scroll position after interactions. For prototype QA, either reset scroll before screenshots, capture first viewport separately, or make non-essential headers static. If the screenshot shows a header bisecting the artifact, patch before reporting. - Desktop first-viewport QA is not enough when the H1 is large or the artifact is dense. Run tablet/mobile QA before calling the page ready for external sharing. - Desktop first-viewport QA is not enough when the H1 is large or the artifact is dense. Run tablet/mobile QA before calling the page ready for external sharing. - CTA overlays on artifacts can be acceptable if intentional, but QA must check that they do not hide the product proof the artifact is supposed to provide. - For focus/rescue products, check whether the UI composition contradicts the product promise. If the promise is “one step only” or “calm focus,” do not show the whole future sequence by default even if it is useful context; put goal/progress/full sequence in an on-demand drawer/panel and make the main surface only the current action, timer, and primary CTA. Do not add a separate “Focus mode” control when the default screen already embodies focus; that creates conceptual clutter instead of clarity. - Treat “revision” controls as product logic, not copy decoration. Buttons like “Make smaller,” “Gentler,” or “Simplify” must materially rewrite the artifact/action and update any dependent state (e.g. timer duration), not add visible prefixes such as “Gently:” or “Even smaller:”. Add regression tests for this. If the adjustment applies to the whole plan/artifact, place it in the plan/artifact view rather than beside the current action, and make it transform the whole sequence (e.g. split all steps), not just the currently visible item. - Contextual timers should match the atomic action and be capped by product rule. For ADHD/focus prototypes, avoid defaulting every step to 5:00; tiny opening/physical steps can be 0:30–1:00, writing/filling steps can be 2:00–5:00, and no step should exceed the cap. - Mobile QA for drawer/panel layouts must verify the panel is hidden by default, the main CTA/timer remain reachable without scrolling on a representative phone width, the full sequence does not reappear below the fold as distracting clutter, and mobile copy does not reference desktop-only metaphors like “side panel.” - Drawer/panel open/close controls must be spatially attached to the object they affect. A global/header “View plan” affordance is acceptable when the panel is hidden, but once the panel is open, the “Hide/Close” control should move inside the panel/sheet header or card chrome. Avoid remote top-right close buttons for left drawers or bottom sheets because users may not understand what they dismiss. On mobile bottom sheets, add enough backdrop/dimming/blur for the sheet to read as the active layer while keeping the underlying focus surface subordinate. - Drawer/panel controls must be spatially attached to the object they affect. A global/header “View plan” control is acceptable when the panel is hidden, but once the panel is open, the dismiss action (“Hide plan”, close, done) should move inside the panel/header/card being dismissed; otherwise users perceive it as remote and unrelated. On mobile bottom sheets, pair this with a subtle backdrop/blur so the sheet reads as the active layer, then verify open and closed states separately in browser QA. ## Start Small UX lessons: bad pattern → better pattern Use these lessons for future Consumer AI Factory UX work, not just Start Small: - Bad: showing every step/action by default because it proves the AI made a plan. Better: if the promise is calm focus, make the main screen one current action and move the broader plan into an on-demand panel. - Bad: extra mode buttons that explain the concept, e.g. “Focus mode,” when the whole product should already be focused. Better: make the default state embody the product promise and remove redundant controls. - Bad: vague adjustment chips like “Gentler” that add choice but do not create a clear product outcome. Better: keep one concrete, high-value adjustment such as “Make steps smaller,” and make it visibly transform the artifact. - Bad: revision buttons that only decorate copy with prefixes like “Gently:” or “Even smaller:”. Better: implement real state changes, update dependent UI like timers/progress, and add regression tests. - Bad: one-size timer defaults. Better: contextual timers should match the action size, with tiny starter actions at 0:30–1:00 and a strict cap for the product. - Bad: plan/drawer dismiss controls far away from the panel they affect. Better: the open control can be global, but the close/hide control belongs inside the panel/sheet itself. - Bad: desktop-only success criteria. Better: QA desktop and phone separately; on mobile, drawers should be hidden by default and the primary action/timer should stay reachable. - Bad: generic AI/SaaS composition — big pitch, feature cards, pretty but non-specific panels. Better: design around the product artifact and the exact emotional moment; for rescue/focus products, less visible UI can be better UX. - Bad: calling a version worse because it shows less functionality. Better: judge whether the composition supports the promise; for Start Small, the single-step focus screen was materially better than the all-steps-visible version. Start Small companion/body-double lessons: - Bad: user-facing copy says “I’ll sit with you” but never establishes who “I” is. Better: define a consistent companion identity or speaker attribution before the first command/check-in. - Bad: reacting to “maybe it needs a character” by adding a cute mascot/avatar. Better: first test whether a voice-only companion solves the clarity problem through naming, attribution, consistent first-person copy, and guided flow. Visual characters should clarify product promise, not decorate it. - Bad: rescue prompts that appear as unexplained commands, e.g. “Stand up.” Better: add framing before the first physical prompt explaining the ritual and why the body is moving, then make the first instruction permission-based but still clear: “First, let’s help your body shift out of stuck mode. Follow along — I’ll walk you through it.” plus “When you’re ready, stand up.” - Bad: landing pages for rescue/body-double products with two competing entry paths — CTA plus textarea/chips — because they collapse back into planner/chatbot UX. Better: one primary path into the guided session; task naming can happen after the rescue/onboarding ritual. - Bad: landing pages that are emotionally clear but product-light, with only a promise and CTA above the fold. Better: show a compact product artifact in the hero — for Start Small, a sample session card with task question, realistic avoided task, timer, and companion response — so the page feels like a real consumer AI product rather than a manifesto. - Bad: switching a weak SMS/app-install CTA to an email-first/waitlist CTA and assuming the funnel is fixed. Better: keep the lower-friction email capture, but put a concrete artifact in the first viewport showing what the assistant actually does. For SMS assistant products like Alma, the hero should show a compact text exchange or outcome card before traffic is judged on email conversion. - Bad: generic first-viewport copy like “AI assistant for busy moms” plus an email field. Better: name the user moment and show the artifact: “Text Alma when the family logistics are too much,” paired with meal/reminder/grocery/check-in examples and a trust line near the email field. - Bad: “No typing” trust cue when task naming later requires typing or selecting, or narrow friction copy that misses body-double anxieties. Better: use truthful friction reducers near the CTA such as “No sign-up · no camera · not therapy · 5 minutes.” - Bad: check-in messages floating without attribution, making them feel like tooltips or random notifications. Better: visibly/semantically attribute them to the companion voice and keep the same voice through rescue, session, pause, receipt, and waitlist. - Bad: receipt as only factual completion stats. Better: close the emotional body-double loop with a companion sign-off before monetization/waitlist, e.g. “That’s done. I was here the whole time.” - Bad: pricing/waitlist framed as a generic product card after a vulnerable session. Better: frame it as continuation of the companion relationship (“Want me here next time?”) while keeping no-payment clarity. Typography/layout lessons from Start Small: - Bad: generic agent-demo typography — oversized but bland H1, weak hierarchy, template-like copy blocks. Better: use a deliberate type system with a strong H1 shape, intentional line breaks, generous leading, and restrained support copy. - Bad: H1 that is semantically clear but visually clunky. Better: browser-QA the H1 as a visual object; tune weight, width, line-height, and rhythm until it feels product-grade. - Bad: decorative/right-side sample cards competing with the real action. Better: for immediate-relief products, center the core input/action and remove competing artifice. - Bad: suggestion chips that dominate the hero or feel random. Better: compact, realistic, emotionally specific examples below the input so they support action instead of distracting from it. - Bad: boxed “how it works” cards that make a simple product feel SaaS-y. Better: use centered typographic steps when the product should feel calm and lightweight. - Bad: too many panels/cards visible at once. Better: fewer surfaces, more whitespace, one dominant focal object, and secondary context tucked into panels/drawers. - Bad: visual polish that keeps the same skeleton. Better: layout changes must be materially different in composition, hierarchy, and product interaction — not just new colors/shadows. ## Screenshot / image review discipline When the user asks a simple image question like “What do you see in this image?”, answer the visual observation first before expanding into product strategy. Do not assume they asked for a full UX teardown. When generating visual assets for a prototype/landing page, do not overproduce by default. Generate the smallest useful batch (usually one icon or one image pair), QA it, and report the best option plus flaws. Ask or wait before expanding into multi-image sequences, contact sheets, or variant batches. If Antoine says “stop,” “don’t actually,” or similar, stop tool work immediately; do not finish the batch just because it already started conceptually. Use this compact order unless they explicitly request a deep review: 1. **What is visible** — page/screen type, main UI elements, modal/overlay, obvious state. 2. **Immediate read** — what the product appears to do. 3. **Notable strengths/issues** — only the highest-signal 3–5 bullets. 4. **Ask-or-offer next step** — e.g. “Want a deeper UX critique or specific fixes?” If doing a product critique from a screenshot, distinguish between visual facts and strategic interpretation. Flag blockers like install modals separately from the underlying product screen, because overlays can distort the UX assessment. ## Design rejection recovery rule If Antoine says a design is “terrible,” “still terrible,” “too shit,” or otherwise rejects the visual direction, do not defend prior QA or claim it is materially better. Treat the direction as failed, name the likely premise error, and rebuild from a different artifact premise — not just new CSS, colors, shadows, or a Claude pass. For group dinner / small-group consensus products, a common failed premise is “decision dashboard.” Switch to a group-chat-native artifact: the app posts the consensus decision into the conversation and the user can share/vote/copy/book from there. ## Browser QA questions Ask the vision/browser QA these exact questions: 1. Does the first viewport contain a specific product artifact, not just a pitch? 2. Is the primary interaction obvious within 5 seconds? 3. Does this look like a consumer product or an agent-generated SaaS landing page? 4. Is trust handled where the user would feel anxiety? 5. Compared with v1, is this materially different in composition and product experience? 6. What still looks generic, dense, fake, or embarrassing? ## Output format When using this skill, return: 1. UX Director brief. 2. DESIGN.md changes or creation path. 3. Implementation instructions. 4. QA plan. Do not claim completion until browser QA passes. ## Hard rule If Antoine says “I can’t see the difference,” the design failed. Do not defend it. Rebuild the artifact and first viewport from a different premise.