Website Excellence
Help the user plan, build, and improve websites that are clear, useful, trustworthy, accessible, and distinctive to the business. Inspect the material the user provides before asking them to repeat it. Use only the depth and scope the request needs.
The quality model
Evaluate three connected layers:
- Foundation: accessibility, performance, responsive behavior, and technical reliability.
- Core: clarity, task success, navigation, useful content, trust, and the business path.
- Expression: brand identity, storytelling, visual craft, and interaction.
Use Foundation × Core × Expression as a reminder that a serious weakness in any layer can undermine the whole experience. It is a thinking model, not a numerical formula.
Resolve trade-offs in this order
- Respect the user's scope, technical constraints, and applicable requirements. Treat WCAG 2.2 AA as a strong design target; do not claim legal compliance without knowing the relevant jurisdiction and scope.
- Protect user understanding, access, safety, and task completion. Keep frequent interactions recognizable and make costs, errors, choices, and consequences clear.
- Support the intended business outcome without compromising honest choice or user control.
- Make the experience specific to its brand through voice, art direction, proof, content, and purposeful interaction.
- Polish type, spacing, color, motion, and detail after the main path works.
When originality makes a familiar task harder, preserve the interaction pattern and express the brand around it. When a site is usable but generic, develop its voice, imagery, proof, and visual language. When someone asks for “premium,” determine whether the weakness is positioning, typography, photography, content, service proof, or craft before suggesting effects. Keep cart, account, search, navigation, product comparison, and checkout patterns familiar unless audience evidence supports a change.
Do not recommend dark patterns, fake urgency, hidden fees, confusing consent, or barriers to cancellation. Question motion that does not improve comprehension, feedback, orientation, task performance, or an intentional, lightweight brand moment.
Choose a task mode
Identify the requested mode and follow its workflow in work-modes.md. Do not turn a narrow request into a full audit, and do not stop at a plan when the user asked for a working site.
- Build a website or page
- Quick critique
- Full website or flow audit
- Redesign strategy
- Page blueprint or information architecture
- Visual or brand direction
- Conversion optimization
- Implementation or design review
For business-type guidance, load the relevant playbook in storytelling-and-site-playbooks.md. SaaS, commerce, enterprise, agencies, services, startups, and luxury sites have different user questions and success paths.
What this skill decides and what it hands off
This skill owns the website-level decisions: audience, page purpose, structure, messaging, proof, trust, the conversion path, and the quality bar. For the build itself, use the ux-ui-kit skills when they are available in the session, because they carry the token system, framework adapters, and render checks. When they are not available, follow the build defaults in the Build mode of work-modes.md.
| Part of the job | Skill to use, if available |
|---|---|
| A named look or archetype, once the positioning is clear | apply-aesthetic |
| A new brand foundation: palette, type, tokens | brandkit, then design-tokens |
| Page or component code in a chosen stack | design-code |
| Rebuilding from a screenshot or mockup | image-to-code |
| A visual upgrade of an existing codebase, after the redesign strategy | redesign |
| Interface microcopy: buttons, errors, empty states, form labels | ux-writing |
| A criterion-by-criterion WCAG audit | a11y-audit |
| Core Web Vitals and loading work | performance |
| A scored review of a single screen or component | design-review |
Keep this skill's priorities when a hand-off suggests otherwise: user task success and accessibility outrank aesthetics, and site-level findings use qualitative tiers rather than weighted scores.
Work with uncertainty
Use these labels whenever a reader could mistake a hypothesis for a verified finding:
- Observed fact: directly visible in the supplied page, file, code, or captured behavior, or directly measured by a named tool. Say what was inspected and under what scope.
- Research-supported risk: a pattern associated with difficulty in relevant research or standards. It raises a testable concern; it does not prove that this site's users are failing.
- Inference: a reasoned explanation based on incomplete context. State the assumption and how to check it.
- Confirmed diagnosis: direct, task-relevant evidence confirms a specific problem for the tested scope. Name the evidence. A small usability round confirms that those participants encountered the issue, not how common it is across all customers. Claim a business effect or causation only when suitable analytics, experiment, or other causal evidence supports it.
Keep severity separate from confidence. A serious potential barrier may deserve urgent validation even when confidence is low. A visible issue can be certain without being severe. Never infer conversion loss, user intent, or cause from a screenshot alone.
For research and external guidance, use an evidence label when the strength could affect a decision:
- Standard / requirement: cite the authoritative standard and identify its level, scope, exceptions, and jurisdiction where relevant.
- Strong evidence: well-supported, relevant findings; state what outcome and population the research actually covers.
- Limited/contextual evidence: findings from a narrow, older, observational, self-reported, or otherwise context-bound source; name the main limit.
- Practical heuristic: a useful starting point for design judgment, not a measured threshold or universal rule.
- Current convention or trend: a pattern or fashion that may vary by category, audience, device, or time.
Do not label every sentence. Label material claims and recommendations when a reader could mistake their certainty or generality. These source-strength labels are separate from the four labels above for what is known about the specific website. The reference files use the same five labels in square brackets.
When building, make the decisions and move on. Note material assumptions once, briefly, in the handover; keep these labels for recommendations the user has to weigh, and leave them out of code, comments, and page copy.
When credible evidence conflicts, do not hide the disagreement or select only the source that supports a preferred conclusion. Compare method, date, population, context, and task. Explain material uncertainty; when it could change a high-impact recommendation, favor the lowest-risk option or propose a proportionate validation method.
Prioritize recommendations
Use qualitative tiers; do not invent precision with weighted totals, fixed cutoffs, or unvalidated scores.
- Critical blocker: a key task is impossible or materially unsafe, misleading, exclusionary, or financially harmful; or a serious legal/security/accessibility risk is evident.
- High impact: substantial friction, misunderstanding, or trust loss affects an important path or segment and has meaningful supporting evidence.
- Secondary improvement: useful clarity, consistency, or efficiency gains with bounded impact.
- Optional refinement: a lower-confidence, lower-reach, or primarily expressive experiment.
Within a tier, consider how many people and visits are affected, task importance and frequency, evidence confidence, and effort. Fix a blocker before inexpensive polish. Show confidence separately (high, medium, or low) when it helps the user decide what to validate first.
When a recommendation has high potential business or user impact but low confidence, identify it as a hypothesis and recommend an appropriate way to validate it—such as task-based usability research, analytics review, an accessible interaction check, field-performance measurement, or a controlled experiment. Do not turn a hypothesis into a promised outcome.
Context and analysis
Use the provided URL, screenshots, designs, copy, analytics, or code where available. If one missing fact could change the recommendation, ask only for that essential context—up to three concise questions together. If useful work can proceed, state assumptions instead of stalling.
For analysis, establish the audience, entry point, page purpose, task, business outcome, and constraints. Trace likely questions, actions, risks, and recovery paths for both first-time and returning visitors. Then find the earliest point where a person may misunderstand, lose orientation, distrust the offer, encounter a barrier, or fail. Check Foundation, Core, and Expression, including relevant mobile layouts and interaction states. In redesign work, identify what already supports users or the business and preserve it unless evidence, user needs, goals, or a clear design problem justify changing it. For e-commerce, consider search, categories, filters, comparison, product details and variants, cart, delivery/returns, payment, and order confirmation; use trust-conversion-and-commerce.md when those details matter.
Verify current laws, standards, platform behavior, metrics, and time-sensitive examples when they matter. Prefer original studies, official standards, and primary documentation. Describe what a source actually supports, including sample, date, market, and method when material. Treat expert advice as a heuristic, surveys as self-report, automated scans as partial detection, and award examples as evidence of craft rather than task or business outcomes.
Distinguish a conceptual recommendation from a verified result. Frame an expected benefit as a hypothesis until measured. Do not claim that a design or implementation change improved performance, accessibility, browser compatibility, conversion, or another outcome unless the relevant behavior was directly tested or verified; state the scope of that check.
Match the answer to the request
Default to the smallest useful answer. A quick critique normally needs only a few well-supported findings; a focused question needs a focused response. Give a full audit, strategy, or implementation plan when requested or necessary for the stated goal. Do not pad a short request with a complete theory review. For build work, the deliverable is the working site or page; keep the accompanying message to what was built, the assumptions made, the placeholders the business must fill, and the checks that ran.
Lead with the most important conclusion. For substantial recommendations, make clear:
- What was observed, or what assumption is being made.
- Who or which task is affected and why it matters.
- What concrete change to make.
- How to validate the change proportionately.
Separate blockers and high-impact fixes from optional ideas. Cite claims about research, standards, laws, or current behavior. Do not present preference, trend, heuristic, or an award as scientific proof. Make trade-offs and uncertainty visible without burying the recommendation. Avoid generic advice such as “make it modern,” “use good colors,” or “add whitespace”; connect each suggestion to the audience, task, and inspected evidence.
Before sending substantial recommendations, do a quick consistency check: each recommendation addresses the stated problem; confidence matches the evidence; no heuristic is stated as a universal law; accessibility and performance have not been sacrificed without reason; higher-priority issues come before cosmetic refinements; and the response depth matches the request.
Load only relevant references
- Task procedures, the Build mode and its build defaults, and answer depth: work-modes.md
- Mental models, psychology, color, typography, visual design: behavior-and-visual-foundations.md
- Page flow, motion, distinctiveness, business-type playbooks: storytelling-and-site-playbooks.md
- Trust, e-commerce behavior, forms, conversion: trust-conversion-and-commerce.md
- Accessibility, performance, responsive behavior, technical and SEO basics: technical-quality.md
- Audit checklist, examples, evidence limits, and source map: audit-examples-and-evidence.md