Shared visual system
Problem and scope
Trips, the day view, Pailas, My Pailas and the all-days plan had diverged: hardcoded colors, green-tinted and warm neutrals, different card sizes, inconsistent status colors, and conflicting design documents. The founder requested a shared visual system and a frontend-only design pass, with the landing page lower priority.
The implementation specification is nepwalk-fe/design-system.md. nepwalk-fe/DESIGN.md now points to it rather than maintaining a second set of rules. Tokens live in src/config/theme.ts; common presentation classes and semantic variables live in src/app/globals.css.
Final visual rules
| Element | Rule |
|---|---|
| Canvas | Warm off-white, approximately #F9F8F6 |
| Working surfaces | White |
| Borders | Warm neutral #E2DED6 |
| Main text / supporting text | #1A1A1A / #6B6B6B |
| Brand / main action | Forest green #008437 / #007832 |
| Pending or unsaved | Amber tint, dark amber text, clock or alert icon |
| Confirmed | Pale green tint, dark green text, check icon |
| Failure or destructive action | Red; never used for an ordinary waiting state |
| Typography | Satoshi; 24–30px app title, 18px card title, 14px body, 12px metadata |
| Shape | 16px cards, 12px controls, pill badges |
| Spacing | 16px phone gutters, 24px desktop gutters, 32px between sections |
| Controls | At least 44px targets, visible focus, readable labels |
| Motion | Quiet color transitions; reduced motion respected |
Use one primary action per task area. Keep drawer and service-panel actions outlined. Status badges have background, border, icon and label; status is never communicated by color alone. Service tabs retain clear selection styling independent of their status badges.
Page treatment
/trips: shared headings, warm canvas, compact consistent trip cards and wrapping filter navigation./trips/<id>: retain the day navigation and itinerary; align colors, surfaces, typography and confirmation treatment./pailas: add a clear page heading and use the same card, filter and field language./my-pailas: match collection layout, titles, search and route cards; use “Use Paila”./trips/<id>/plan: white panels, shared controls, readable status badges, request-all action above tabs and one request action per category./: retain hero photography; align colors, search control and typography. This is a consistency pass, not a landing-page content redesign.
Acceptance checks
- Moving between the five app routes preserves the same canvas, button green, border tone, card radius and title hierarchy.
- Pending is amber, confirmed is green, errors are red; a saved choice does not become a confirmed booking.
- Long titles and controls remain readable at 390px; cards and page filters do not force horizontal page scrolling.
- Keyboard focus is visible, tabs remain operable, and reduced-motion preferences are respected.
- The plan's service panel and fixed page action remain reachable on short desktop and phone screens.
- Existing trip editing, Paila selection, vendor choices and confirmation permissions keep their behavior.
Integration boundary and verification
Only frontend design and these docs are in scope. Existing service exclusions remain preview-only; request buttons still use the existing vendor-choice save behavior. A persistent exclusion API and a distinct confirmation-request lifecycle are separate implementation work.
Checked on 19 Oct: type checking, lint, unit tests and an isolated production build pass. Browser tests were not run. The checks above remain manual acceptance work: passing the build does not show that every state or viewport is right.