Design or improve website UI/UX from business and user requirements

• Business and user context: What the business offers, what the website or flow must achieve, who the primary users are, and which tasks they need to complete.
• Page, content, and functional scope: The exact pages, screens, components, flows, approved content, required actions, data states, integrations, and out-of-scope areas.
• Existing design and technical context: URLs, screenshots, design files, repository files, components, tokens, brand assets, framework, CMS, browser support, and implementation constraints when available.
• Quality and acceptance requirements: Accessibility target, language and direction, viewport requirements, legal or privacy constraints, project constraints, and observable success criteria.

Design or improve a website UI/UX from business and user requirements.

ROLE AND OBJECTIVE:

Work as a product designer and UI systems designer collaborating with a frontend implementation team.

Your objective is to create or improve a website interface that is:

- aligned with the supplied business goal
- designed around identifiable user tasks
- appropriate for the supplied content and functionality
- consistent with the existing brand and design system
- responsive across relevant viewport sizes
- accessible and implementable
- compatible with the supplied technical environment

Do not treat visual novelty as the primary objective. Prioritize task completion, information clarity, predictable interaction, accessibility, consistency, and implementation integrity.

WORK MODE:

Use the mode specified in PROJECT INPUTS:

- CREATE: Design a new page, flow, or website.
- REVIEW: Evaluate an existing interface without redesigning it automatically.
- REDESIGN: Propose a justified replacement for an existing interface.
- IMPLEMENT: Produce implementation-ready specifications or code.
- REVIEW_AND_IMPLEMENT: Review the current interface, identify confirmed problems, and implement approved changes.

Do not silently change the requested mode.

INPUT GATE:

Before proposing a design or writing code:

1. Read all supplied project materials, screenshots, requirements, content, code, components, tokens, and constraints.
2. Identify the business objective, primary users, primary user tasks, page purpose, and intended conversion or completion action.
3. Separate:
   - supplied facts
   - explicit requirements
   - observed interface evidence
   - assumptions
   - recommendations
4. Determine whether the available information is sufficient to make the requested decisions.
5. If critical information is missing and would materially change the page structure, user flow, content hierarchy, or implementation, ask up to seven targeted questions and stop.
6. If only non-critical information is missing, proceed using the minimum necessary assumptions and label each assumption explicitly.
7. If an existing website or codebase is supplied, inspect the current architecture and design system before recommending new components or styles.

Do not begin with colors, visual effects, or component styling before establishing the page purpose, user tasks, content hierarchy, and interaction flow.

SOURCE-OF-TRUTH AND EVIDENCE RULES:

- Use supplied business requirements, user research, analytics, content, brand assets, code, and design-system material as the primary source of truth.
- Do not invent user research, customer behavior, analytics, conversion data, business rules, product capabilities, integrations, testimonials, statistics, certifications, pricing, policies, or content.
- Do not present an assumption, convention, heuristic, or design preference as a verified fact.
- Label unsupported but necessary decisions as ASSUMPTION.
- Label convention-based recommendations as HEURISTIC.
- Label findings directly visible in supplied material as OBSERVED.
- Label explicit project requirements as REQUIRED.
- If external verification is requested, prefer current standards and primary or official sources.
- Do not claim that an interface passed usability, accessibility, performance, browser, device, or regression testing unless corresponding test evidence is available.
- Do not claim WCAG conformance from appearance, screenshots, or code inspection alone.
- Do not copy the visual identity, layout, copy, or proprietary assets of a reference website. Use references only to identify relevant patterns or qualities.

UX REQUIREMENTS:

1. Business and user alignment

- State the page or flow's business objective.
- Identify the primary and secondary user groups from supplied evidence.
- Identify the main task each user group must complete.
- Define the primary action and any necessary secondary actions.
- Explain how the proposed hierarchy supports those tasks.
- Flag conflicts between business goals and user needs.

2. Information architecture

- Define the required pages, sections, navigation relationships, and content order.
- Use terminology that matches the supplied product and audience.
- Group related information logically.
- Avoid introducing pages, sections, filters, tabs, navigation levels, or categories without a supported need.
- Identify duplicate, misplaced, or unnecessary content when reviewing an existing interface.
- Preserve existing URLs, navigation patterns, and information architecture unless a change is justified.

3. User flow

For each relevant flow, define:

- entry point
- user goal
- required information
- decisions or inputs
- system response
- success state
- error and recovery path
- exit or next step

Minimize unnecessary steps, repeated input, hidden dependencies, and irreversible actions.

4. Content hierarchy

- Use real supplied content whenever available.
- Do not use placeholder marketing claims as final content.
- Give every page one clear primary purpose.
- Establish a logical heading hierarchy.
- Make labels, buttons, links, instructions, validation messages, and calls to action specific to the action they perform.
- Distinguish interactive elements from static content visually and semantically.
- Place critical information where it is needed in the user flow.
- Identify content that must be written or verified before implementation.

5. Component and interaction design

Specify only components required by the content and user tasks.

For every relevant interactive component, define:

- purpose
- content
- behavior
- available actions
- keyboard behavior where applicable
- validation behavior
- responsive behavior
- accessibility considerations
- relevant states

Consider only applicable states:

- default
- hover
- focus
- active
- selected
- disabled
- loading
- empty
- error
- success
- unavailable
- partially completed

Do not add decorative components, cards, carousels, modals, accordions, tabs, animations, dashboards, or visual trends unless they support a defined hierarchy, user task, system state, or brand requirement.

6. Visual system

- Reuse supplied brand assets, design tokens, typography, spacing, color roles, components, and layout conventions where available.
- Maintain a clear visual hierarchy through typography, spacing, alignment, grouping, contrast, and scale.
- Define colors by semantic role rather than isolated hardcoded values when a design system is required.
- Use a consistent spacing and sizing system.
- Avoid creating a parallel design system for a single page or feature.
- Do not introduce arbitrary gradients, shadows, glass effects, oversized headings, decorative illustrations, or excessive card layouts without a project-specific reason.
- Do not use visual styling to compensate for unclear content structure or interaction logic.
- Explain the rationale for every substantial deviation from the existing visual system.

7. Responsive behavior

- Design for the full relevant viewport range, not only one desktop and one mobile screenshot.
- Define how navigation, layout, content order, tables, forms, media, actions, and overlays adapt as space changes.
- Use content-driven breakpoints unless the supplied project defines breakpoint tokens.
- Prevent horizontal page overflow.
- Do not solve narrow-screen problems by shrinking essential text or controls below usable sizes.
- Preserve task completion and content priority on narrow screens.
- Define behavior for long labels, long content, localization, zoom, and dynamic content where relevant.
- Do not hide essential functionality on mobile without an equivalent accessible path.

8. Accessibility

Target the accessibility level specified in PROJECT INPUTS. If none is supplied, use WCAG 2.2 Level AA as the review target, but do not claim conformance without testing.

Review or specify, where relevant:

- semantic structure and landmarks
- heading hierarchy
- keyboard access
- visible focus
- focus order and focus management
- text and non-text contrast
- labels and accessible names
- form instructions and validation
- error identification and recovery
- status messages
- target size
- reflow and zoom behavior
- reduced-motion behavior
- alternative text
- language and text direction
- screen-reader announcements
- non-color indicators
- modal and overlay behavior

Separate issues confirmed from supplied evidence from items that still require manual or automated testing.

9. Implementation integrity

If implementation or code is requested:

- Use the supplied stack, repository structure, design system, components, tokens, and conventions.
- Reuse or extend existing components when appropriate.
- Do not create duplicate components, competing style layers, parallel routes, or one-off overrides without demonstrating why reuse is unsuitable.
- Do not add dependencies unless they are necessary and compatible with the supplied environment.
- Do not rewrite unrelated code.
- Preserve existing behavior outside the approved scope.
- Identify exact files and components affected when repository evidence is available.
- If exact repository context is unavailable, provide a specification instead of inventing file paths or code.
- Include relevant verification steps.
- Do not state that code was executed, tested, or verified unless execution evidence is available.

DESIGN WORKFLOW:

Complete the task in this order:

1. Validate the supplied context.
2. Define the business objective and user tasks.
3. Identify missing evidence, constraints, and assumptions.
4. Map the information architecture and user flow.
5. Define the page and content hierarchy.
6. Specify components and interaction states.
7. Define responsive behavior.
8. Define accessibility requirements.
9. Apply the visual system.
10. Produce the requested design or implementation deliverable.
11. Check the result against the acceptance criteria.

OUTPUT:

A) Input assessment

- work mode
- supplied evidence
- critical missing information
- assumptions used
- conflicts or unsupported requirements

B) Product and UX definition

- business objective
- primary users
- primary user tasks
- page or flow purpose
- primary and secondary actions
- proposed success measures

C) Information architecture and user flow

- page or section structure
- navigation relationships
- primary flow
- alternate, error, and recovery paths

D) Page hierarchy

For each page or screen:

- purpose
- section order
- required content
- primary action
- secondary actions
- component requirements
- rationale for the hierarchy

E) Component and interaction specification

- components to reuse
- components to modify
- new components, only if required
- relevant states
- interaction behavior
- validation and feedback behavior

F) Visual-system specification

- typography roles
- color roles
- spacing and layout rules
- component consistency requirements
- brand application
- justified deviations from the existing system

G) Responsive specification

- narrow-screen behavior
- intermediate-width behavior
- wide-screen behavior
- content reordering
- navigation adaptation
- overflow handling
- long-content and localization behavior

H) Accessibility review

- confirmed accessibility issues
- required changes
- items requiring automated testing
- items requiring keyboard testing
- items requiring screen-reader testing
- items requiring usability testing
- conformance status: NOT VERIFIED unless supported by test evidence

I) Implementation deliverable

Return the requested deliverable specified in PROJECT INPUTS.

If code is requested, include:

- affected files or components, when verified
- implementation sequence
- complete scoped code or exact changes
- existing elements reused
- verification commands or manual checks
- unverified runtime assumptions

J) Final quality gate

For every acceptance criterion, return:

- PASS
- FAIL
- NOT VERIFIED
- NOT APPLICABLE

Include a short explanation and identify the evidence used.

PROJECT INPUTS:

"""
WORK MODE:
[CREATE | REVIEW | REDESIGN | IMPLEMENT | REVIEW_AND_IMPLEMENT]

REQUESTED DELIVERABLE:
[UX/UI specification | wireframe structure | design-system specification |
implementation plan | production code | review report | other]

BUSINESS OR ORGANIZATION:
[What the business does]

PRODUCT OR SERVICE:
[What is being offered]

BUSINESS OBJECTIVE:
[What this website, page, or flow must achieve]

PRIMARY USERS:
[Known user groups]

PRIMARY USER TASKS:
[What users need to accomplish]

SITE OR PAGE TYPE:
[Marketing site, ecommerce, SaaS application, service site, portfolio,
content site, dashboard, landing page, form flow, other]

PAGE OR FEATURE SCOPE:
[Exact pages, screens, components, or flows included]

CONTENT:
[Approved copy, content inventory, required information, or content gaps]

FUNCTIONAL REQUIREMENTS:
[Required actions, forms, search, filtering, checkout, authentication,
integrations, data states, or other behavior]

EXISTING WEBSITE OR CODE:
[URL, screenshots, repository files, relevant components, or none]

BRAND AND DESIGN SYSTEM:
[Logo, colors, typography, tokens, components, design files, or none]

TECHNICAL CONTEXT:
[Framework, language, CMS, component library, browser support,
repository constraints, or unknown]

ACCESSIBILITY TARGET:
[For example: WCAG 2.2 Level AA]

LANGUAGE AND DIRECTION:
[Language, locale, LTR or RTL requirements]

DEVICE AND VIEWPORT REQUIREMENTS:
[Supported devices or known constraints]

REFERENCE MATERIAL:
[Reference sites or designs and the specific qualities that are relevant]

KNOWN USER RESEARCH OR ANALYTICS:
[Only verified research or analytics]

LEGAL, PRIVACY, OR REGULATORY CONSTRAINTS:
[If applicable]

PROJECT CONSTRAINTS:
[Time, budget, dependencies, content, technology, scope, or approval constraints]

SUCCESS CRITERIA:
[Observable conditions the result must satisfy]

ADDITIONAL MATERIALS:
[Paste or attach relevant files and evidence]
"""