──/02 selected work

idealo ads.

cały b2c mvp retail media — solo designer, 6 miesięcy, od dziedziczonego kodu do launchu.

klientidealo (axel springer group)

czas11/2025 — 5/2026

rolasolo product designer

teampo, tech lead, ~5 devs

outcomelaunch on time, 0 ślizgów

idealo Decision Media — retail media, built for the decision moment

── idealo decision media · brand framing platformy

"my nie damy rady zrobić całej apki w pół roku?" ── szef działu, kickoff

6miesięcy do mvp

4typy kampanii

1designer (solo)

0ślizgów

──/01 problem

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.

──/02 research

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 zrobiłam zamiast

01

competitive review

meta ads, amazon ads, allegro ads — pattern mining: ia, content, billing.

02

internal stack audit

know-how od kolegów z rasp, którzy projektowali dziedziczony kod.

03

walidacja przez proxy

internal operatorzy idealo z ad-tech background — w innym kontekście niż reklamodawcy.

──/03 design

co musiało powstać end-to-end w 6 miesięcy.

cała apka — od pierwszego logowania do faktury wystawionej księgowemu.

/01onboarding + sign-up

/024 typy kampanii + creative upload

/03account / subaccount / permissions

/04billing + invoicing flow

/05raporty + dashboardy

/06views dla operatorów (managed mode)

/07bilingual content (pl/en)

/08handoff: design system, dokumentacja

zamiast pokazywać każdy ekran — pokażę dwie decyzje, które zaważyły na tym, że dowieźliśmy.

──/03 design / 01
system thinking

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

── fig 01 · macierz status × akcja × info (wycinek — pełna ma 7 statusów × 12 kolumn)

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 ↓

── struktura

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.

── jak była używana

devy — kopiowali bezpośrednio do logiki walidacji frontendu i backendu.
content team — dla każdej komórki w kolumnie copy generowali pl + en wersję, wiedząc dokładnie w jakim kontekście wyświetli się komunikat.
ba — używali jako check-listy do walidacji reguł z biznesem.

── konsekwencja

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.

──/03 design / 02
scope cut

€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.

── propozycja (odrzucona)

pivot table jak w excelu

€9–30k

+ ryzyko ślizgu

analityka multi-dimensional. case użycia: "na zaś".

── reframe (zaakceptowany)

flat table dla billingu

€7–9k

w 2 tygodnie, bez ślizgu

eksport csv dla księgowych. faktury bez debtor id.

── fig 02 · scope cut: research + cost-benefit + reframe

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 ↓

── researche bibliotek

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.

── reframe use case'u

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.

── argument za reframe'em

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.

──/03 design / 03
side quest

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.

──/04 outcomes

launch on time, zero ślizgów.

── mierzalne

0

ŚLIZGÓW

launched on time mimo scope expansion.

~€22k

ZAOSZCZĘDZONE

flat billing vs proponowany pivot module.

4

TYPY KAMPANII

w mvp, ia gotowa pod skalowanie.

── design ready (gotowe pod kolejne iteracje)

/01subaccount settings

/02self-service mode

/03pełen analytics module

/04migracja pod nowy ds

──/05 wtopy
& lekcje

co poszło nie tak — i co z tego wynieśliśmy.

/01

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 ↓

── co konkretnie się mieszało

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.

── przed

admin
owner
user
analityk

── po

cały app

wybrane konta

tier 1

admin

owner

tier 2

—

user / analityk

── płaski model 4 ról → two-axis matrix (scope × rola)

── argument za refactorem

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.

/02

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.

/03

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.

/04

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.