Files
j_kedzierski/prompts/04-jak-sie-umowic.md

80 lines
3.5 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Jak się umówić / Terminvereinbarung — `/pl/jak-sie-umowic` i
`/de/terminvereinbarung` (page id 3)
Bloki: `pageHeader` → `process` → `contactInfo` → `finalCta`. To strona o
najniższym progu wątpliwości — ktoś, kto tu trafia, jest już prawie
zdecydowany. Cel wizualny: nie stawiać żadnej przeszkody, potwierdzić że
„to naprawdę jest proste".
---
## 1. PageHeader
**[ZACHOWAĆ treść]** „Jak się umówić" / „Prosty, przejrzysty i w 100% zdalny
proces". Layout jak w [03-uslugi.md](./03-uslugi.md) §1 — spójny wzorzec
page-header w całym serwisie.
---
## 2. Process (`blockType: process`, pełna wersja — 3 kroki)
**[ZACHOWAĆ treść]** WhatsApp → dokumenty → gotowe rozliczenie do podpisu.
To jest ROZWINIĘTA wersja tych samych 3 kroków co na home (tam skrócone jako
teaser) — musi wyglądać podobnie, ale bardziej szczegółowo, nie jak inny
komponent.
**Layout:** pionowa oś czasu (timeline) na całą szerokość kolumny treści —
numer kroku w kółku po lewej połączony pionową linią `line-draw` z kolejnym
krokiem, tytuł + pełny opis po prawej. To już opisany wzorzec z home §6, tu
pełniejszy (dłuższe opisy — np. wymienione konkretne dokumenty:
Lohnsteuerbescheinigung, IdNr/PESEL).
**Zdjęcie (`image`, puste):** jedno zdjęcie kontekstowe obok osi czasu —
propozycja: dłonie trzymające telefon z otwartym WhatsAppem + dokumenty na
stole obok. Łączy wizualnie 3 kroki (komunikacja + dokumenty) w jednym kadrze,
zamiast szukać osobnego zdjęcia do każdego z 3 kroków (co prowadziłoby do
zbyt rozdrobnionej, „stockowej" sekcji).
**Animacja:** `line-draw` scroll-linked (linia oś czasu rysuje się w miarę
przewijania — dokładnie ten sam wzorzec co na home, świadomie powtórzony, bo
to ta sama treść w rozwiniętej formie — powtórzenie tu buduje rozpoznawalność,
nie jest duplikacją bez sensu).
---
## 3. ContactInfo (`blockType: contactInfo`)
**[WYMAGA DANYCH OD KLIENTA]** obecnie `address: "DO POTWIERDZENIA PRZEZ
KLIENTA"`, telefon i e-mail placeholder — patrz [10-architektura-cms.md](./10-architektura-cms.md) §1.
Nie da się tego sensownie zaprojektować bez realnych danych — poniżej sam
wygląd, niezależny od treści.
**Layout:** karta w formie „wizytówki" — adres, telefon (klikalny `tel:`),
e-mail (klikalny `mailto:`), godziny — 2×2 grid ikon+tekstu na desktopie,
pionowa lista na mobile. Traktować jak fragment papeterii firmowej: cienka
ramka, może z delikatnym narożnikiem „zagięcia rogu" (subtelny `box-shadow`
sugerujący kartkę, nie dosłowny origami-efekt).
**Animacja:** `reveal-up`, brak dodatkowych efektów — to czysta informacja
użytkowa, ktoś tu szuka faktu (numeru telefonu), nie doświadczenia.
---
## 4. FinalCTA
**[ZACHOWAĆ treść]** „Chcesz szybko odzyskać podatek?" — spójny wzorzec, patrz
[02-strona-glowna.md](./02-strona-glowna.md) §10.
---
## Uwaga UX: ta strona i WhatsApp floating button
Na tej konkretnej stronie floating WhatsApp button (patrz
[02-strona-glowna.md](./02-strona-glowna.md) §0) jest szczególnie istotny —
to strona, na którą ktoś trafia PO decyzji „chcę się umówić", więc przycisk
musi być widoczny od pierwszego ekranu, nie dopiero po scrollu do FinalCTA.
Nie ukrywać go tu w obrębie sekcji Process/ContactInfo (tylko w obrębie samego
FinalCTA, zgodnie z regułą ogólną) — to jedyne odstępstwo od reguły „ukryj przy
FinalCTA" wspomnianej w pliku 02, bo tu jest tylko jeden FinalCTA na dole, a
reszta strony powinna mieć stały dostęp do CTA.