illek-product-design
Audit, design, implement, and release Illek web product UI, UX, accessibility, responsive behavior, copy, SEO, and visual polish. Use for work on tools.illek.ie, requestscope.illek.ie, email.illek.ie, scan.illek.ie, network.illek.ie, day.illek.ie, or their source repositories, especially redesigns, interface reviews, responsive fixes, accessibility work, metadata changes, and production-readiness checks.
# Illek Product Design Use evidence from the running product and its source. Preserve product identity while applying shared quality gates. ## Workflow 1. Read repository instructions, status, architecture, and current diffs. Preserve unrelated work. 2. Identify the product's audience, core job, primary path, trust boundary, and visual character. 3. Capture the current interface at 390, 768, and 1440 pixels. Exercise important interactive states rather than judging only the landing view. 4. Review the interface using `references/standards.md`. 5. Prioritize problems that affect comprehension, task completion, trust, accessibility, or mobile use. 6. Implement changes in the product's existing design language. Avoid applying a shared template across products. 7. Add or update automated checks for the changed behavior. 8. Run source tests, browser tests, accessibility checks, metadata checks, and visual comparisons. 9. Deploy only when requested. Verify the canonical `illek.ie` hostname at desktop and 390-pixel mobile widths. ## Design approach - Lead with the product's principal task and make its next action obvious. - Prefer calm information hierarchy, purposeful spacing, and restrained decoration. - Give each product a recognizable visual idea connected to its function. - Treat loading, empty, error, partial, success, export, and destructive states as designed surfaces. - Keep developer/API information useful without allowing it to dominate the primary workflow. - Use generated design concepts as exploration. Reconcile them with the product architecture, accessibility, and actual content before implementation. ## Copy constraints - Do not use eyebrow labels. - Do not use em dashes. - Avoid formulaic contrast constructions such as `X, then Y`, `not X, Y`, or `it is not X, it is Y`. - Avoid inflated claims, generic SaaS language, and security guarantees the implementation cannot support. - Use Irish English where natural. ## Validation Run `scripts/audit-html.mjs` against every canonical page affected by the change. Pair it with the repository's browser suite and Lighthouse. Automated accessibility checks do not replace keyboard, focus, zoom, contrast, and content review. Use Playwright screenshot comparisons when deterministic baselines exist. Inspect diffs before accepting updated snapshots. Do not publish Azure Platform Designer, retired projects, `pages.dev`, or `workers.dev` hostnames. Do not publish a new Field Agent package until its Windows, signing, SmartScreen, EDR, and RMM gates pass.