---
id: travel-trip-com-representative-en
service: Trip.com
website: https://www.trip.com
category: travel
prompt: representative
language: en
generated: 2026-07-18
---

# Trip.com

> **Integrated build prompt** · Travel · Product, UX, UI, frontend, SEO/AEO, performance, and QA in one build specification.

## When to use this prompt

Use this document when you are planning, designing, or building a product where **destination discovery and booking** matters. Study the public information architecture of [Trip.com](https://www.trip.com), but reinterpret it for your own problem. Do not reproduce its logo, copy, images, proprietary assets, or pixel-level layout.

- Reference service: Trip.com
- Core entities: itineraries, stays, and reservations
- Primary risk: dates, prices, and cancellation terms
- Starting interface direction: discovery and comparison flow · clear and confident · medium information density · criteria -> discovery cards -> price and policy comparison -> booking or order · #287DFA · Trip.com

## Public interface design analysis

- Reference basis: These are recurring visual and structural patterns from public landing screens and representative task flows. Verify the current live capture because services change over time.
- Interface archetype: discovery and comparison flow
- Tone and manner: clear and confident
- Information density: medium
- Color strategy: restrained brand accents on neutral surfaces (#287DFA)
- Navigation model: lightweight top navigation
- Structural sequence: criteria -> discovery cards -> price and policy comparison -> booking or order
- Reusable patterns: hero search, date control, comparison card, price policy, sticky action
- Independent application rule: Use the order and decision principles only. Do not reproduce logos, copy, imagery, icons, or proprietary screen composition.

## Project inputs to replace

```yaml
product_name: "[Your product name]"
target_users: "[Primary users and context]"
problem: "[Problem they need to solve]"
core_features: "[Three to five essential features]"
business_goal: "[Conversion, activation, retention, or another metric]"
technology_stack: "[For example, Next.js and Tailwind CSS]"
brand_tone: "[For example, clear, calm, and trustworthy]"
```

## Copy-ready prompt

```text
Act as a senior product designer, UX strategist, frontend architect, and technical SEO lead.

Create an implementation-ready product specification and, when requested, production-quality code for [Your product name]. Use Trip.com (https://www.trip.com) only as a reference for information architecture and decision flow in a product designed for destination discovery and booking. Do not copy the service's brand, logo, wording, images, protected assets, or exact screen composition.

Project context:
- Target users: [Primary users and context]
- Problem: [Problem they need to solve]
- Core features: [Three to five essential features]
- Business goal: [Conversion, activation, retention, or another metric]
- Technology stack: [Framework, styling, data, and hosting]
- Brand tone: [Voice and visual character]

Required design and implementation criteria:
1. Make the relationships and states of itineraries, stays, and reservations understandable at a glance.
2. Provide prevention, explanation, and recovery paths for dates, prices, and cancellation terms.
3. Specify loading, empty, error, success, disabled, permission-denied, and partial-data states.
4. Preserve content priority and navigation at 360px, 768px, and 1280px.
5. Use semantic HTML, logical keyboard order, visible focus, 44px touch targets, and WCAG AA contrast.
6. Define page structure, components, data, actions, microcopy, edge cases, and measurable acceptance criteria.
7. Give every indexable page a unique title, meta description, canonical URL, heading hierarchy, and crawlable internal links.
8. Answer important user questions directly in visible content. Keep WebSite, WebPage, BreadcrumbList, and CreativeWork structured data consistent with that content.
9. Set performance budgets for the main image, fonts, JavaScript, Core Web Vitals, and slow-network behavior.
10. Return a testable result rather than general design advice.

Output in this order:
- Goals, assumptions, and success metrics
- User flow and information architecture
- Screen and component specification
- Data model, states, and error recovery
- Responsive and accessibility rules
- SEO, AEO, and structured-data plan
- Implementation plan or code
- Verifiable completion checklist
```

## Starting design tokens

```css
:root {
  --color-primary: #287DFA;
  --color-ink: #17201D;
  --color-canvas: #F6F8F7;
  --color-surface: #FFFFFF;
  --color-tint: #287DFA22;
  --color-danger: #DC2626;
  --radius-card: 8px;
  --space-1: 4px; --space-2: 8px; --space-3: 12px;
  --space-4: 16px; --space-6: 24px; --space-8: 32px;
}
```

These tokens are a starting point, not a request to clone Trip.com. Validate contrast, hierarchy, density, and brand distinctiveness for your own users.

## Expected deliverables

- Product requirements tied to user outcomes and measurable success criteria
- Information architecture and the critical end-to-end flow
- Component contracts covering data, states, actions, and accessibility
- Mobile, tablet, and desktop adaptation rules
- SEO/AEO content model, structured data, and internal-link plan
- Performance budgets, analytics events, tests, and release acceptance criteria

## Follow-up prompts

1. "Take the most important flow and define normal, loading, empty, partial-data, validation-error, server-error, permission-denied, and success states with one consistent data model."
2. "Convert the specification into semantic, reusable components with realistic English content at 360px, 768px, and 1280px. Include keyboard and screen-reader behavior."
3. "Audit the result for dates, prices, and cancellation terms. Rank failures by severity and give observable evidence, a fix, a verification method, and a completion condition."
4. "Remove anything that resembles Trip.com's brand or proprietary layout while preserving only the useful information-architecture principle."
5. "Split the result into engineering tickets with purpose, data requirements, component API, edge cases, accessibility criteria, tests, and dependencies."

## Validation checklist

- [ ] Trip.com is used only as an information-architecture reference.
- [ ] Project-specific users, problems, features, and metrics replace every placeholder.
- [ ] The priority and state changes of itineraries, stays, and reservations are explicit.
- [ ] Trust and recovery paths address dates, prices, and cancellation terms.
- [ ] Empty, delayed, partial, failed, and permission-restricted states are covered.
- [ ] Keyboard, screen reader, 200% zoom, reduced motion, and contrast can be tested.
- [ ] The final design has its own product language and visual identity.