Słownictwo,
którym pracujemy.

Każda współpraca biegnie przez te same 8 kroków: Diagnose → Map → Standardize → Build → Govern → Ship → Measure → Iterate. Głębokość każdego kroku skaluje się do wielkości engagementu; sekwencja zostaje stała. Ta stałość to co czyni pracę przewidywalną - niezależnie czy obsługujemy 47 lokalizacji czy 470.

Design ops to system decydujący co jest brief'owane, przez kogo, w jakim formacie, z jakimi bramkami akceptacji, w jakiej kolejności, do jakich standardów - nie sam design. To różnica między zatrudnieniem designerów a zbudowaniem działającej kreatywnej organizacji.

Operacyjna praca designerska dla brand'ów obsługujących wiele lokalizacji, venues, nieruchomości lub równoległych kampanii. Inne niż praca dla single-location brand'u - bottleneckiem nigdy nie jest creative, tylko koordynacja, governance i zarządzanie wariantami w wielu równoległych ścieżkach.

Trzy sekwencyjne bramki akceptacji. Bramka 1 (Master): jeden zaakceptowany koncept, internal sign-off r352. Bramka 2 (Variant): mid-level acceptance po stronie klienta, per lokalizacja lub wariant kampanii. Bramka 3 (Pre-production): senior client sign-off przed finalną produkcją. Bez tych bramek multi-location launche zapadają się w 200-mailowe wątki z dyrektorami będącymi w biurze 2 dni w tygodniu.

Brief volume = ile zapytań designerskich/kampanijnych przerabia Twój zespół w okresie. Decision velocity = średni czas od przyjścia briefu do zaakceptowanego kierunku. Pomnóż je - to Twój realny creative throughput. Zatrudnienie więcej designerów podnosi pojemność volume'u, ale nie naprawia velocity. Bottleneckiem jest prawie zawsze decision velocity.

Agencje sprzedają kreatywne deliverables, billing'owane godzinowo lub per project, z sukcesem mierzonym w nagrodach i portfolio. Operatorzy sprzedają działające systemy, billing'owane productized lub retainer'em, z sukcesem mierzonym w metrykach operacyjnych (zredukowany czas ops, decision velocity, brand consistency score). r352 to to drugie.

Tribal knowledge to co się dzieje gdy senior designer staje się jedyną osobą wiedzącą jak briefy są triage'owane, gdzie master files się znajdują, który dyrektor co akceptuje. Gdy ta osoba odchodzi, nowa osoba spędza 3 miesiące reverse-engineering'iem wszystkiego. Multi-location brand'y płacą ten koszt cyklicznie - i rzadko go uwzględniają w P&L.

Brief w każdy poniedziałek. Async check-in w każdy czwartek. Drop delivery packu w każdy piątek. Quarterly review. Cadence to produkt - to co pozwala klientom planować wokół output'u r352, zamiast czekać na kolejny wielki reveal. Przeciwieństwo to heroic launch model: miesiące ciszy, potem jeden wielki drop, który nie wytrzymuje kontaktu z multi-location rzeczywistością.

5 dni roboczych. Audytujemy obecne design operations - wywiady ze stakeholder'ami, 5-7 spriorytetyzowanych bottlenecków - i dostarczamy jednostronicową pisemną diagnozę z 60-dniową roadmapą. Często używane jako low-commitment fit test przed pełnym Sprint'em lub Operating Partner.

Zdefiniowany scope, fixed price. Używany gdy jest znany deliverable do dostarczenia - nowy operating system, campaign toolkit, brief intake process. Sprinty nie drift'ują; jeśli scope rośnie, staje się to nowym sprint'em z odrębną scope agreement.

30-day notice, scope reviewed kwartalnie. Używany gdy jest ciągła warstwa operacyjna wymagająca utrzymania - tygodniowe briefy, governance reviews, ad-hoc problem solving. Większość engagement'ów r352 osiada w Retainer po początkowym Sprint'cie.

Używany dla pełnych rollout'ów design operations w dziesiątkach lub setkach lokalizacji - brand standardization, brief intake redesign, governance gate implementation, training internal teams. Zawiera pre-production support i post-rollout audit.

12-miesięczne minimum. r352 staje się de facto design operations lead w organizacji klienta - uczestnictwo w leadership reviews, ownership operating systemu, hiring decisions dla zespołu designerskiego, vendor selection. Najbliższy model do posiadania head of design ops bez zatrudniania osoby na etacie.

Każdy piątek o 17:00 CET, klient otrzymuje delivery pack: folder z finalnymi asset'ami, 8-minutowy Loom walkthrough, jednostronicowe podsumowanie co zostało dostarczone i co dalej. Delivery pack to puls engagement'u - gdy się spóźnia, coś poszło źle z systemem, nie z pracą.

Każdy krok r3loop kończy się jednym binarnym pytaniem - decision gate. Diagnose zamyka się pytaniem "czy wiemy, który friction point kosztuje najwięcej?" Standardize - "czy nowa osoba w zespole wyprodukuje brief zgodny ze standardem bez pytania kogokolwiek?" Jeśli odpowiedź brzmi nie, krok nie jest skończony - żadna ilość aktywności nie zastępuje bramki. Decision gates utrzymują loop w uczciwości: zamieniają otwartą pracę konsultingową w sekwencję weryfikowalnych checkpointów.

Każdy krok r3loop jest winien następnemu zdefiniowany artefakt w zdefiniowanym formacie - to jego output contract. Diagnose jest winien rankowaną listę friction points. Standardize - templaty plus QA checklist. Measure - baseline KPI. Ponieważ kontrakt określa strukturę, nie tylko treść, outputy są reużywalne między engagement'ami - i produktyzowalne: ten sam output contract, który zasila rollout u klienta, może zasilić narzędzie. Praca, która nie wypełnia kontraktu, nie idzie dalej.

Presence curve opisuje, ile hands-on zaangażowania operatora (r352) wymaga każdy krok r3loop. Diagnose działa przy ~90% obecności operatora - wywiady, osąd, synteza. Przy Measure i Iterate obecność spada do ~15%: system, templaty i własny zespół klienta niosą pracę, a r352 robi review wyjątków. Opadająca krzywa to sens engagement'u - jeśli obecność operatora pozostaje płaska, kupiłeś zależność, nie system.