Większość problemów
z designem to nie
problemy z designem.

r3loop - wszystkie 8 kroków, decision gates i KPI

1. 01 - Diagnoza: Znaleźć realny problem zanim cokolwiek zaprojektujemy

   Audytujemy stan obecny - workflow, wąskie gardła, stakeholderzy, narzędzia i ścieżki decyzyjne. Bez założeń, tylko dowody z danymi o kosztach czasowych.

   Co robimy: Wywiady ze stakeholderami, audyt workflow, analiza źródeł requestów, przegląd narzędzi i mapowanie pain-pointów z szacowanym kosztem czasowym.

   Co dostajesz: Jednostronicowa diagnoza operacyjna z 5-7 priorytetyzowanymi wąskimi gardłami i zalecaną sekwencją działań na 60 dni.

   Dlaczego to ważne: Bez diagnozy każde rozwiązanie to zgadywanka - nawet jeśli wygląda dobrze.

   Typowy czas: 3-5 dni dla fokusowanych projektów, 1-2 tygodnie dla zaangażowań organizacyjnych.

   Decision gate: Czy potrafimy opisać problem operacyjny w jednym zdaniu z konkretną liczbą kosztu czasowego? Jeśli nie - zostań w Diagnozie.

   KPI: Czas do zidentyfikowania przyczyny każdego powtarzającego się problemu.

2. 02 - Mapowanie: Zrozumieć krajobraz popytu

   Mapujemy co przychodzi - kto, co, jak często, w jakim formacie, z jaką pilnością. To zamienia nieskończony backlog w sklasyfikowany, zarządzalny system.

   Co robimy: Audyt skąd przychodzą requesty, klasyfikacja typów requestów, analiza wolumenu per stakeholder i mapowanie sezonowości.

   Co dostajesz: Mapa popytu pokazująca wolumen requestów per stakeholder, powtarzające się wzorce sezonowe, jasne kategorie requestów i listę requestów do zaakceptowania, odrzucenia lub odłożenia.

   Dlaczego to ważne: Nie priorytetyzujesz tego, czego nie sklasyfikowałeś. Mapowanie zamienia 'wszystko jest pilne' w system, gdzie każdy request ma jasne miejsce.

   Typowy czas: 1 tydzień. Często przebiega równolegle z diagnozą przy większych zaangażowaniach.

   Decision gate: Czy nowy request da się sklasyfikować do kategorii na wejściu w 30 sekund, przez kogokolwiek? Jeśli mniej niż 95% klasyfikuje się czysto - dopracuj taksonomię.

   KPI: % requestów z jasną kategorią na wejściu (cel 95%+).

3. 03 - Standaryzacja: Ustalić zasady zanim ruszy produkcja

   Wprowadzamy standardy briefingu, Definition of Ready, logikę priorytetyzacji i benchmarki jakości. To jest kontrakt między stakeholderami a produkcją.

   Co robimy: Szablony briefów dla standardowych, lokalnych i ekspresowych requestów, lista gotowości zanim ruszy produkcja, prosty system scoringowy dla priorytetu, pilności, wartości biznesowej i nakładu produkcyjnego, cotygodniowe review requestów, standardy jakości kreatywnej i quality review checklisty per typ assetu.

   Co dostajesz: Biblioteka szablonów, system priorytetyzacji, standardy jakości kreatywnej, quality review checklisty, prompty AI asystenta briefu i 90-dniowy plan adopcji.

   Dlaczego to ważne: Standardy eliminują pętle poprawek zanim się zaczną. Kiedy brief jest kompletny a kryteria jakości są jasne, feedback staje się precyzyjny zamiast polityczny.

   Typowy czas: 2-3 tygodnie. Najcięższa faza intelektualnie - tutaj pisze się operacyjna logika systemu.

   Decision gate: Czy junior może wypełnić brief bez zadawania pytań lead designerowi, korzystając tylko z szablonu i checklisty? Jeśli nie - dopracuj szablon.

   KPI: % briefów spełniających listę gotowości przy pierwszym złożeniu (cel 80%+).

4. 04 - Budowa: Tworzyć to, co idzie na produkcję

   Egzekucja na seniorskim poziomie zgodnie ze standardami z Fazy 03. Niezależnie czy to UX/UI, system marki, toolkit kampanijny czy playbook operacyjny - budujemy gotowe do produkcji deliverables, nie koncepty.

   Co robimy: Design UX i interfejsów, systemy marki, assety kampanijne, biblioteki komponentów, workflow produkcji, mapa ownership akceptacji per typ assetu, instrukcje handoffu i integracje narzędzi.

   Co dostajesz: Gotowe do produkcji pliki, systemy i dokumentacja. To może obejmować service blueprinty, diagramy workflow, biblioteki komponentów, assety kampanijne lub interfejsy - w zależności od potrzeb projektu.

   Dlaczego to ważne: Rzemiosło bez struktury łamie się przy dostawie. Łączymy seniorską egzekucję z jasnymi standardami, więc jakość staje się powtarzalna zamiast heroiczna.

   Typowy czas: 2-12 tygodni w zależności od zakresu. Dostarczane w tygodniowych sprintach z widocznym postępem na każdym checkpoincie.

   Decision gate: Czy developer lub zespół może to wdrożyć bez zadania ani jednego pytania? Przetestuj 3 losowe elementy. Jeśli pytają - domknij specyfikacje.

   KPI: Cycle time od zatwierdzonego briefu do dostarczonego assetu.

5. 05 - Governance: Zdefiniować kto decyduje, jak i kiedy

   Definiujemy ownership, ścieżki akceptacji, zasady change requestów i logi decyzji - żeby decyzje były śledzalne i nie blokowały się na jednej osobie.

   Co robimy: Model ownership decyzji, zasady akceptacji, ścieżki eskalacji, proces change requestów, zasady rozwiązywania konfliktów i struktura logu decyzji.

   Co dostajesz: Jasny decision playbook. Każdy wie kto akceptuje co, jak obsługiwane są zmiany i gdzie dokumentowane są ważne decyzje.

   Dlaczego to ważne: Większość pętli poprawek nie dotyczy jakości. Pojawiają się bo ownership jest niejasny. Kiedy wszyscy wiedzą kto decyduje o czym, projekty idą szybciej.

   Typowy czas: 1-2 tygodnie. Definiowane równolegle z Budową, egzekwowane od pierwszej dostawy.

   Decision gate: Czy dla dowolnego artefaktu potrafimy wskazać kto go zatwierdził, kiedy i jakie było uzasadnienie? Jeśli śledzalność poniżej 95% - napraw logowanie.

   KPI: Średni czas decyzji i wskaźnik cofania decyzji (oba w trendzie spadkowym).

6. 06 - Dostawa: Dostarczać z quality gates, nie nadzieją

   Każdy deliverable przechodzi przez ustrukturyzowane QA i akceptację przed handoffem. Nic nie wychodzi niedopieczone. Nic nie wychodzi bez sign-offu od właściwej osoby.

   Co robimy: Quality review checklisty dla każdego typu assetu, ustrukturyzowane rundy review, zasady akceptacji stakeholderów, dokumentacja handoffu i specyfikacje dla developerów tam gdzie potrzebne.

   Co dostajesz: Zatwierdzone, gotowe do produkcji pliki z jasnymi instrukcjami handoffu. Twój zespół wie co zostało dostarczone, dlaczego powstało i jak tego użyć lub wdrożyć.

   Dlaczego to ważne: Dostawa to moment w którym większość procesów się łamie. Zastępujemy 'wygląda ok chyba' ustrukturyzowanym quality review, które każdy w zespole może stosować spójnie.

   Typowy czas: Wbudowane w każdy sprint. Quality review dzieje się ciągle, nie tylko na końcu.

   Decision gate: Czy deliverable odpowiada briefowi ORAZ przeszedł quality checklistę ORAZ ma sign-off od nazwanego ownera? Jeśli którakolwiek odpowiedź brzmi nie - nie wysyłaj.

   KPI: % prac przechodzących quality review w pierwszej rundzie (cel 70%+).

7. 07 - Pomiar: Śledzić co się naprawdę zmieniło

   Stawiamy infrastrukturę pomiarową - dashboardy KPI, kadencje review, tracking adopcji. Bez danych nie udowodnisz że system działa ani nie znajdziesz gdzie przecieka.

   Co robimy: Setup dashboardu workflow performance, pomiar bazowy, struktura miesięcznego review, tracking adopcji per zespół i integracja AI workflow tam gdzie to ma sens.

   Co dostajesz: Framework pomiarowy, którego Twój zespół może używać do śledzenia cycle time, wskaźników poprawek, jakości briefów, powtarzających się wąskich gardeł i adopcji nowego procesu.

   Dlaczego to ważne: Jeśli nie mierzysz workflow, kończysz zarządzając opiniami zamiast realnymi problemami.

   Typowy czas: 1-2 tygodnie na setup. Potem działa ciągle jako część rytmu operacyjnego.

   Decision gate: Czy możemy pokazać 3 mierzalne usprawnienia względem baseline'u w ciągu 60 dni? Jeśli nie - system nie działa albo pomiar jest zepsuty.

   KPI: Dashboard live + pierwszy baseline uchwycony w ciągu 2 tygodni od launchu systemu.

8. 08 - Iteracja: Utrzymać system żywym, nie zamrożonym

   Prowadzimy monthly review, kwartalne governance checks i cykle optymalizacji procesu. System adaptuje się do zmieniającej się organizacji - nie staje się półkowym dokumentem.

   Co robimy: Miesięczne sesje review, kwartalne review procesu, sprinty optymalizacji, sprawdzanie powrotu do starych nawyków workflow, aktualizacje AI workflow i coaching zespołu.

   Co dostajesz: System, który ciągle się poprawia zamiast stawać się przestarzały. Twój zespół dostaje zaktualizowane szablony, rekomendacje procesowe, kwartalne review trendów i jasny rytm poprawy tego jak praca jest wykonywana.

   Dlaczego to ważne: Każdy proces się degraduje. Zespoły się zmieniają, narzędzia się zmieniają i priorytety się przesuwają. Bez rytmu review system powoli przestaje działać a zespół wraca do starych nawyków.

   Typowy czas: Ciągłe - typowo 1 sesja miesięcznie. Może być częścią retainera lub w pełni przekazane Twojemu zespołowi.

   Decision gate: Czy właściciel systemu może wziąć 2 tygodnie urlopu bez tego, żeby cokolwiek się rozsypało? Jeśli nie - system jeszcze nie działa samodzielnie. Zostań w Iteracji.

   KPI: Trend kwartał-do-kwartału wszystkich metryk z faz 03-06.