──/02 selected work
idealo ads.
cały b2c mvp retail media — solo designer, 6 miesięcy, od dziedziczonego kodu do launchu.
"my nie damy rady zrobić całej apki w pół roku?"
── szef działu, kickoff
cała platforma od zera, na cudzym kodzie, w pół roku.
- idealo wchodzi w retail media — własna platforma reklamowa dla brandów i merchantów.
- rasp dziedziczył kod z innego, niewystartowanego use case'u — fundament był, ale brakowało ia, designu, contentu, integracji z marką.
- idealo oddał projekt na zewnątrz świadomie — typowe dla retail media w grupach typu axel springer.
- ja: solo, 6 miesięcy, split attention z innymi projektami.
cytat szefa na kickoff to uczciwa kalkulacja, nie sceptycyzm. ten case study go obala — ale nie udaje, że było łatwo.
trzy constrainty, trzy obejścia.
- niemieckojęzyczni reklamodawcy poza zasięgiem (brak budżetu na translatora).
- limitowany research support od klienta — efekt externalizacji projektu.
- split attention z innymi projektami.
validation przez proxy nie zastępuje real userów. ramuję to w deliverach, żeby nie sugerować falszywej walidacji.
co musiało powstać end-to-end w 6 miesięcy.
- cała apka — od pierwszego logowania do faktury wystawionej księgowemu.
zamiast pokazywać każdy ekran — pokażę dwie decyzje, które zaważyły na tym, że dowieźliśmy.
macierz status × akcja × info — jeden artefakt, trzy odbiorcy.
- logika walidacji była ad-hoc, per ticket. brak jednego źródła prawdy.
- zaprojektowałam pełną macierz dla każdego statusu kampanii.
- devy → source of truth. content → kontekst dla copy. ba → lista do walidacji z biznesem.
| status | edytowalne pola | akcje | info w ui |
|---|---|---|---|
| draft | wszystkie | save, schedule, delete | — |
| scheduled | budget, daty, targeting | edit, pause, cancel | start in: 3d 4h |
| delivering | budget (+), daty (end) | pause, end early | impressions, ctr |
| budget reached | budget (+ only) | top-up, end | budget exhausted |
| completed | żadne | duplicate, archive | final stats, csv |
z całego projektu z tego jestem najbardziej dumna — nie z ui, z faktu że systemowe źródło prawdy przed dewelopmentem zaoszczędziło iteracje walidacyjne.
— co konkretnie obejmowała pełna macierz i jak była używana
- 7 statusów kampanii: draft, scheduled, delivering, budget reached, completed, inactive, archived.
- 12 kolumn: edytowalne pola (per kategoria), dostępne akcje, info w ui, tooltips, błędy walidacji, copy pl/en, edge cases.
- reguły przejść między statusami: które są automatyczne, które wymagają user action, które wymagają operator action.
- devy — kopiowali bezpośrednio do logiki walidacji frontendu i backendu.
- content team — dla każdej komórki w kolumnie copy generowali pl + en wersję.
- ba — używali jako check-listy do walidacji reguł z biznesem.
- nowe pola czy statusy są dodawane do macierzy zanim trafią do kodu.
- edge cases identyfikowane przed userem.
- artefakt żyje po launchu — używany przy każdym dodatku do platformy.
€22k zaoszczędzone na 2 tygodnie przed launchem.
- tech lead i po proponują dosypać moduł analityczny w stylu pivot tables.
- research bibliotek mit-licensed — każda wymaga custom code'u, ryzyko ślizgu.
- plus reframe: analityka dla analityków vs billing dla księgowych. realna potrzeba — flat table.
nie powiedziałam "nie" autorytetem. pokazałam research, cost-benefit, prawdziwy use case. launch on time, zero ślizgów.
— jak doszłam do tego reframe'u i co dokładnie zaważyło na akceptacji
- constraint projektowy: tylko mit-licensed.
- testy: ag-grid free, react-pivottable, pivottable.js, plus dwa mniejsze.
- każda miała braki funkcjonalne: brak custom export, sztywne formatowanie, brak edge cases dla null values.
- każda wymagała custom code'u — od €4k do €18k czasu deweloperskiego.
- spytałam tech leada: kto będzie tego używał, do czego konkretnie?
- odpowiedź: "wewnętrzni operatorzy idealo, do różnych analiz."
- spytałam dalej: jakich analiz dziś nie da się zrobić?
- okazało się: jedyna realna potrzeba to billing — księgowy potrzebuje agregatów miesięcznych, eksportu csv, faktur dla firm bez debtor id.
- flat table = wystarcza.
- nie "nie róbmy tego" — tylko "róbmy to inaczej".
- cost-benefit pokazany w jednym wierszu: €7-9k vs €9-30k + ryzyko.
- realny use case zamiast hipotetycznego.
- po i tech lead zaakceptowali bez oporu.
ds idealo w transition — minimum viable convergence.
- start: stary ds idealo (consumer e-commerce, niedopasowany do enterprise saas).
- koniec projektu: nowy ds idealo dostępny.
- decyzja: upodabniamy do nowego, nie przepisujemy. lista alignmentu w sprintach po-mvp.
launch on time, zero ślizgów.
co poszło nie tak — i co z tego wynieśliśmy.
przerysowałam spec po 1:1, bez challenge'u.
permissions: czterostopniowa hierarchia admin / owner / user / analityk. czas naciskał, czas oszczędzałam. moduł poszedł do dewelopmentu. dopiero post-deploy, klikając po apce, zobaczyłam, że hierarchia miesza scope (do czego masz dostęp) z rolą (co możesz zrobić). refactor wszedł na two-axis matrix, drogi (większość logic była już napisana), ale przed launchem.
lekcja: spec od domain experta wart jest 30 minut critical reading zanim zacznę rysować — zwłaszcza gdy czas naciska.
— jak wyglądał refactor i diagram before/after
- scope — cały app albo wybrane konta.
- rola — pełne uprawnienia albo tylko podgląd.
- "user" w płaskim modelu = niejednoznaczny (ograniczony scope czy rola?).
- wieloznaczność wychodziła przy każdym onboardingu i ticketcie.
- admin
- owner
- user
- analityk
- scaling: 4 role w płaskim modelu = ok, 6+ (z roadmap'y) = chaos.
- wspólny język z po — skala, nie estetyka.
- po: zaakceptował z entuzjazmem.
przegrana walka o layout flow create vs edit kampanii.
argumentowałam, że kontekst ma znaczenie (mental model tworzenia ≠ edycji). stakeholderzy: jeden layout = krótszy development. mój argument był jakościowy, ich mierzalny — i timeline był krytyczny.
lekcja: następnym razem przygotuję proxy-evidence po stronie ux (np. error rate w mixed context z analogicznych produktów), żeby tradeoff był liczba vs liczba, nie zasada vs liczba.
chaotyczna migracja pod nowy ds idealo.
późne domknięcie spotkania z designerem idealo — figma i prod zaczęły się rozjeżdżać. w pewnym momencie sama nie miałam pewności, co jest source of truth.
lekcja: przed migracją zdefiniować, co jest source of truth (kod albo figma) i utrzymywać synchronizację jako proces, nie ad-hoc.
brak spec challenge session jako stałego rytuału.
permissions story to konsekwencja tej procesowej luki. 30-minutowy spec challenge przed wejściem w design wyłapałby błąd, który wyszedł post-deploy.
lekcja: pre-flight checklist dla designera — pierwszą pozycją jest "30 minut na critical reading specu".
najwartościowsze deliverables to nie były ekrany — to artefakty systemowe (macierz walidacji, two-axis permissions, cost-benefit dla scope-cuts), które żyją po launchu.
── następny projekt