Jak przygotować „teczkę dowodową” dla usług UI/UX na B2B: Figma, backlog, ticketing, changelog, protokoły odbioru a spór o stawkę ryczałtu

05.02.2026

W realiach współpracy B2B w obszarze UI/UX spór rzadko dotyczy „czy coś zostało zrobione”, a częściej: co dokładnie było objęte zakresem, kiedy nastąpiła zmiana zakresu, kto ją zatwierdził i czy ryzyka „rozjechania” estymacji miały zostać pokryte w ramach wynagrodzenia ryczałtowego. Dobrze przygotowana teczka dowodowa pozwala odtworzyć przebieg projektu w sposób uporządkowany i „sądoodporny” – od pierwszego briefu i makiet w Figma po protokoły odbioru oraz finalne rozliczenie.

1) Najpierw: jaki reżim prawny ma umowa UI/UX?

W praktyce umowy na UI/UX funkcjonują jako umowy o wykonanie oznaczonego rezultatu (często porównywane do umowy o dzieło) albo jako umowy starannego działania (świadczenie usług). Ma to znaczenie dla argumentacji w sporach o ryczałt i odbiór.

Jeżeli strony uzgadniają wynagrodzenie ryczałtowe wprost w logice umowy o dzieło, punktem odniesienia pozostaje art. 632 Kodeksu cywilnego, w tym zasada, że wykonawca co do zasady nie może żądać podwyższenia ryczałtu, a wyjątek dotyczy sytuacji nadzwyczajnych, grożących rażącą stratą. 

Gdy współpraca jest kwalifikowana jako świadczenie usług, przepisy odsyłają do regulacji o zleceniu (art. 750 Kodeksu cywilnego), a sam ryczałt wynika przede wszystkim z treści kontraktu i zasady swobody umów (art. 3531 k.c.). 

Z perspektywy dowodowej najbezpieczniejsze jest przyjęcie założenia, że spór będzie rozstrzygany „po dokumentach”: kontrakt i załączniki mają wskazywać rezultat, zakres, kryteria akceptacji, sposób obsługi zmian oraz powiązanie płatności z oddaniem i odbiorami.

2) „Teczka dowodowa” – po co i jak działa w sądzie?

Spór o stawkę ryczałtu w B2B rozbija się o ciężar dowodu. Co do zasady ciężar udowodnienia faktu spoczywa na stronie, która wywodzi z niego skutki prawne (art. 6 k.c.). Dodatkowo strony są obowiązane wskazywać dowody dla stwierdzenia faktów (art. 232 k.p.c.). 

W projektach cyfrowych kluczowe jest także to, że dowodami są nie tylko „papierowe” dokumenty. Kodeks postępowania cywilnego przewiduje zasady dotyczące dokumentów zawierających tekst (w tym elektronicznych) oraz odrębnie dowody z zapisów obrazu/dźwięku. W praktyce oznacza to, że eksporty z narzędzi (Jira, Linear, Asana), logi, wiadomości e-mail, komunikatory czy zrzuty z Figma mogą stanowić materiał dowodowy – o ile zostaną odpowiednio zabezpieczone.

Istotne jest również rozróżnienie między „treścią” a „autorstwem”. Dokument prywatny w formie pisemnej albo elektronicznej stanowi dowód tego, że osoba, która go podpisała, złożyła oświadczenie zawarte w dokumencie (art. 245 k.p.c.). W przypadku dokumentów elektronicznych szczególną wagę ma sposób podpisu oraz identyfikowalność wystawcy. 

3) Co powinno wejść do teczki: warstwy dowodowe projektu UI/UX

Skuteczna teczka dowodowa nie jest zbiorem przypadkowych screenów. Powinna układać się w logiczną oś czasu i odpowiadać na pytania: co uzgodniono, co wykonano, kto zatwierdził, kiedy i jak rozliczono.

3.1. Warstwa kontraktowa: fundament sporu o ryczałt

• umowa główna + wszystkie aneksy (zakres, wynagrodzenie, zasady zmian, terminy, odpowiedzialność, prawa autorskie),
• załączniki typu SOW/SoP: opis etapów (Discovery, wireframes, UI kit, prototyp, testy), definicje „Done” i „Acceptance”,
• ustalenia o narzędziach: Figma, repozytorium, system ticketing, komunikacja,
• polityka zmian: kiedy powstaje change request, kto akceptuje wpływ na termin i budżet.

Warto dopilnować, aby kontrakt wprost rozróżniał: „zmiany w ramach iteracji” (np. liczba rund feedbacku) od „zmiany zakresu” (nowe funkcjonalności, nowe widoki, przebudowa przepływów). W sporze o ryczałt jest to często „punkt zapalny”. 

3.2. Warstwa produktowa: Figma jako „repozytorium decyzji”

Figma może być dowodem nie tylko rezultatu (makiety, komponenty), ale także procesu decyzyjnego (komentarze, historia zmian, wersje). W teczce dowodowej powinny znaleźć się:

• eksporty kluczowych ekranów i prototypów w datach „kamieni milowych” (PDF/PNG + opis),
• zrzuty lub eksporty komentarzy akceptacyjnych (kto, co zaakceptował / odrzucił),
• wersjonowanie: oznaczenia release candidate, „v1/v2”, tagi dla sprintów,
• mapa przepływów (user flows) i zestaw wymagań niefunkcjonalnych, jeżeli wpływały na zakres.

Praktyczna wskazówka: eksport powinien zachować metadane (data wygenerowania, autor eksportu, identyfikatory pliku/projektu). Sam „screen” bez kontekstu bywa łatwy do podważenia.

3.3. Warstwa wykonawcza: backlog, ticketing, changelog

W sporze o stawkę ryczałtu największą wartość ma zderzenie: „co było w backlogu na start” vs „co doszło po drodze”. Dlatego teczka dowodowa powinna obejmować:

• snapshot backlogu na dzień startu (eksport listy ticketów/epiców + opis priorytetów),
• historię zmian ticketów: kto zmieniał opis/zakres, kiedy dodano wymagania,
• zależności: linki do plików Figma lub decyzji produktowych,
• changelog – najlepiej powiązany z kolejnymi odbiorami etapów (co zostało dowiezione i kiedy).

Jeżeli klient kwestionuje zakres, dokumentowanie „wejść” (nowe wymagania) i „wyjść” (co zrealizowano) pozwala wykazać, czy doszło do faktycznej zmiany zakresu, czy jedynie doprecyzowania.

3.4. Warstwa odbiorowa: protokoły odbioru i płatność

W umowach o rezultacie znaczenie ma moment oddania dzieła i jego odbioru. Co do zasady wynagrodzenie staje się należne w chwili oddania dzieła, o ile strony nie postanowiły inaczej (art. 642 k.c.), a zamawiający ma obowiązek odebrać dzieło wydane zgodnie ze zobowiązaniem (art. 643 k.c.). 

W praktyce projektowej protokół odbioru powinien być dokumentem „krytycznym”, bo stanowi pomost między dowiezioną pracą a rozliczeniem. Dobre protokoły zawierają:

• zakres odbieranego etapu (linki do plików, lista ekranów/komponentów),
• kryteria akceptacji i ich spełnienie (np. checklista),
• zestawienie usterek/wad oraz klasyfikację (istotne/nieistotne) i termin poprawek,
• podpis osoby uprawnionej po stronie zamawiającego (lub kwalifikowany podpis elektroniczny, gdy strony chcą zachować formę elektroniczną o mocy równoważnej pisemnej).

Jeżeli spór dotyczy „wad” i potrąceń, punkt odniesienia stanowią regulacje o odpowiedzialności za wady dzieła i odpowiednie stosowanie przepisów o rękojmi (art. 638 k.c.).

4) Jak zabezpieczać dowody elektroniczne, aby nie przegrać „na formalnościach”?

W projektach cyfrowych dowody powstają w systemach, które łatwo edytować. Dlatego kluczowe jest zabezpieczenie integralności i identyfikowalności:

• regularne eksporty (PDF/CSV) z narzędzi ticketing i dokumentów decyzyjnych,
• archiwizacja korespondencji (e-mail) oraz kluczowych ustaleń z komunikatorów w postaci plików z datą i uczestnikami,
• stosowanie podpisów: jeżeli strony chcą zachować formę elektroniczną równoważną pisemnej, przepisy wymagają kwalifikowanego podpisu elektronicznego (art. 781 k.c.), a rozporządzenie eIDAS przewiduje równoważność kwalifikowanego podpisu z podpisem własnoręcznym (art. 25). 
• utrwalanie materiałów audiowizualnych (np. nagrania demo) – jako potencjalne dowody z dokumentów zawierających zapis obrazu/dźwięku. 

Warto pamiętać, że oświadczenie woli może zostać złożone przez każde zachowanie ujawniające wolę w sposób dostateczny (art. 60 k.c.). W sporach gospodarczych często oznacza to, że akceptacje „mailowe” lub „w narzędziu” mogą mieć znaczenie, o ile da się je wiarygodnie przypisać osobie i odtworzyć ich treść oraz kontekst. 

5) Spór o stawkę ryczałtu: typowe scenariusze i jak teczka dowodowa „robi robotę”

Najczęstsze scenariusze konfliktowe przy ryczałcie w UI/UX to:

1. Scope creep – klient oczekuje rozszerzeń bez formalnej zmiany umowy.
2. „To tylko drobna poprawka” – spór o kwalifikację zmian jako iteracji vs zmiany zakresu.
3. Spór o odbiór – brak podpisanych protokołów, odbiory „na czacie”, równolegle rosnące roszczenia o rabat.
4. Spór o prawa do plików/projektu – gdy nie jest jasne, czy i kiedy nastąpiło przeniesienie praw lub udzielenie licencji (co w UI/UX bywa istotne, bo projekty mogą stanowić utwór w rozumieniu prawa autorskiego). 

W każdym z tych scenariuszy teczka dowodowa powinna umożliwić sądowi „rekonstrukcję projektu”: od backlogu startowego, przez decyzje produktowe w Figma, aż po odbiory i rozliczenia. W przypadku umów o dzieło szczególnie ważne jest udokumentowanie, czy powstały przesłanki do wyjątkowych roszczeń związanych z ryczałtem (art. 632 k.c.) – jednak w praktyce to materiał dowodowy przesądza, czy doszło do sytuacji nadzwyczajnej, czy jedynie do niedoszacowania lub niekontrolowanej zmiany zakresu. 

6) Kiedy warto włączyć prawnika „zanim” zrobi się spór?

W projektach B2B na UI/UX największe straty wynikają z braku formalizacji: niejednoznacznych definicji zakresu, nieopisanych zasad zmian i „rozmytych” odbiorów. Włączenie wsparcia prawnego na etapie projektowania umowy i procedur dowodowych (protokoły, change requesty, matryca akceptacji, polityka archiwizacji) zwykle kosztuje mniej niż późniejsza eskalacja do sporu.

W ramach wsparcia przedsądowego kancelaria Kopeć Zaborowski Adwokaci i Radcowie Prawni może pomóc w ułożeniu procesu dokumentowania projektu (tak, aby tworzył spójną teczkę dowodową), przeanalizować ryzyka kontraktowe związane z ryczałtem oraz przygotować strategię negocjacyjną i dowodową na wypadek sporu o rozliczenie, odbiór lub zakres.

Bibliografia (źródła)

• Kodeks cywilny – art. 6, art. 3531, art. 632, art. 638, art. 642, art. 643, art. 750, art. 781, art. 60. 
• Kodeks postępowania cywilnego – art. 232, art. 2431, art. 245, art. 308. 
• Ustawa o prawie autorskim i prawach pokrewnych – art. 1 (definicja utworu). 
• Rozporządzenie (UE) nr 910/2014 (eIDAS) – art. 25 (skutki prawne podpisów elektronicznych).