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

14.04.2026

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

Teczka dowodowa w usługach UI/UX na B2B to uporządkowany zestaw dokumentów i śladów cyfrowych, które pozwalają wykazać, co było przedmiotem umowy, jakie prace faktycznie wykonano, kiedy i przez kogo, jak rozliczono zakres oraz w jaki sposób klient potwierdził odbiór. W praktyce jest to narzędzie ograniczające ryzyko sporu o wynagrodzenie ryczałtowe, o zakres zmian (change requests) oraz o to, czy rezultat spełnia ustalone kryteria.

W realiach biznesowych spór o wynagrodzenie ryczałtowe w UI/UX zwykle nie dotyczy samej „stawki”, lecz tego, czy wykonawca wykonał więcej niż obejmował uzgodniony zakres i czy takie prace powinny być dodatkowo płatne. Teczka dowodowa ma znaczenie nie tylko w negocjacjach i mediacjach, ale także w procesie cywilnym, gdzie ciężar dowodu co do faktów spornych wynika z art. 6 Kodeksu cywilnego [1].

Dlaczego w UI/UX ryczałt najczęściej „pęka” na dowodach

Ryczałt (art. 632 § 1 Kodeksu cywilnego) co do zasady oznacza z góry określone wynagrodzenie za wykonanie określonego dzieła, niezależnie od nakładu [1]. W usługach UI/UX problemem bywa to, że „zakres” jest opisany skrótowo, a produkt ewoluuje w sprintach. Jeśli nie ma uporządkowanych śladów decyzji, wersji i akceptacji, pojawiają się typowe punkty zapalne:

• klient twierdzi, że część pracy była „oczywista” w ryczałcie, a wykonawca traktuje ją jako zmianę zakresu,
• brak jednoznacznych kryteriów ukończenia (Definition of Done) i odbioru,
• brak dowodu, że klient znał konsekwencje zmian (czas, koszt),
• spór o to, czy mamy do czynienia z umową o dzieło (rezultat), czy ze świadczeniem usług/umową starannego działania, co wpływa na ocenę odpowiedzialności za nienależyte wykonanie (art. 471 KC) [1].

Podstawy prawne, które realnie „pracują” w sporze

W sporach B2B o UI/UX najczęściej stosuje się konstrukcje z Kodeksu cywilnego, w zależności od treści umowy i modelu współpracy:

• Art. 6 KC (ciężar dowodu) – kto z danego faktu wywodzi skutki prawne, ten powinien go udowodnić [1].
• Art. 471 KC (odpowiedzialność kontraktowa) – znaczenie ma wykazanie niewykonania lub nienależytego wykonania zobowiązania oraz związku przyczynowego ze szkodą; w praktyce sporne bywa też, czy dłużnik ponosi odpowiedzialność (chyba że wykaże brak swojej odpowiedzialności) [1].
• Art. 632 KC (wynagrodzenie ryczałtowe przy umowie o dzieło) – ogranicza możliwość żądania podwyższenia, ale spór często dotyczy tego, czy dana praca była w ogóle objęta ryczałtem [1].
• Art. 353¹ KC (swoboda umów) – strony mogą uregulować sposób akceptacji, procedurę zmian, komunikację i narzędzia [1].

Fakt: sąd ocenia dowody zgodnie z zasadą swobodnej oceny (art. 233 § 1 KPC) [2]. Opinia: w sporach technologicznych większą wagę mają dowody „operacyjne” (repozytoria, ticketing, logi, eksporty), bo najlepiej pokazują chronologię i decyzje.

Co powinno znaleźć się w „teczce dowodowej” UI/UX

Teczka nie musi być rozbudowana, ale powinna być kompletna i możliwa do odtworzenia. Kluczowe jest, aby materiały miały jednoznaczną datę, autora i kontekst (do jakiego zlecenia/sprintu się odnoszą).

1) Umowa, załączniki i reguły współpracy

• umowa główna (B2B) wraz z definicją przedmiotu, wynagrodzenia ryczałtowego (jeśli zastosowano ryczałt), harmonogramu i zasad odbioru,
• załącznik: opis zakresu (np. moduły, widoki, user flows),
• zasady change request: kto zatwierdza, jak, w jakim terminie, jak wyceniane są zmiany,
• zasady komunikacji: kanały (e-mail, Slack, Jira), osoby decyzyjne po stronie klienta.

2) Figma jako dowód zakresu i wersjonowania

Figma bywa kluczowym dowodem, ale tylko jeśli można wykazać, co było wersją „do odbioru”. W teczce powinny znaleźć się:

• linki do plików i projektów z nazwami zgodnymi z backlogiem,
• eksporty PDF/PNG z datą (snapshot) dla wersji oddawanych do akceptacji,
• historia wersji i komentarzy: kto zgłaszał uwagi, kiedy zostały zamknięte,
• notatka, co stanowi „final” na dany etap (np. oznaczenia stron/ramek).

3) Backlog i ticketing: Jira/YouTrack/Trello jako „oś czasu”

Backlog i ticketing są często najczytelniejszą osią czasu: pokazują zgłoszenie, priorytet, estymację, zmianę statusu i akceptację. Dla celów dowodowych pomocne są:

• eksport sprintów oraz listy ticketów z datami i osobami przypisanymi,
• ticket „change request” jako osobna kategoria,
• komentarze i decyzje (zwłaszcza o rezygnacji z części zakresu lub o „must have”),
• materiały powiązane: link do Figmy, prototypu, researchu.

4) Changelog i wersje: co się zmieniło i dlaczego

Changelog porządkuje spór o to, czy doszło do „dodatkowych prac”. Minimalny standard to wpisy: data, element, przyczyna (bugfix, zmiana wymagań, decyzja biznesowa), wpływ na termin/koszt (choćby opisowo). Jeżeli UI/UX jest wdrażany do produktu, warto spiąć changelog z wydaniami (release notes) zespołu developerskiego.

5) Protokoły odbioru i akceptacje etapowe

W sporach o ryczałt protokół odbioru jest często kluczowy, bo zamyka etap i ogranicza późniejsze kwestionowanie. W praktyce w teczce powinny znaleźć się:

• protokoły odbioru etapów (np. Discovery, IA, makiety, UI kit, prototyp),
• akceptacje mailowe z jednoznacznym „akceptuję” i wskazaniem wersji,
• lista usterek/uwag i termin ich usunięcia,
• informacja o warunkowym odbiorze, jeśli był stosowany.

Trzy wyjątki, o których firmy zwykle zapominają

Wyjątek 1: „Jedno źródło prawdy” nie jest dowodem, jeśli nie da się go odtworzyć. Sam link do Figmy lub Jiry może być niewystarczający, jeśli po zakończeniu współpracy dostęp zostanie odebrany albo dane zostaną zmienione. Dowodowo bezpieczniejsze są eksporty i archiwizacja wersji na moment odbioru.

Wyjątek 2: Milczenie klienta nie zawsze oznacza akceptację. Jeżeli umowa nie wprowadza mechanizmu odbioru przez brak uwag w terminie, to brak odpowiedzi nie musi zamknąć etapu. Wtedy istotne jest konsekwentne wzywanie do odbioru i dokumentowanie prób przekazania rezultatów.

Wyjątek 3: „Drobne poprawki” potrafią stać się sporem o zakres. Jeżeli w ticketach i changelogu nie odróżnia się poprawek mieszczących się w usuwaniu wad od zmian wynikających z nowych potrzeb biznesowych, wykonawca traci argument o dodatkowej pracy. Warto mieć prostą kwalifikację: wada, doprecyzowanie, zmiana wymagania.

Jak uporządkować teczkę, żeby działała w praktyce

1. Ustalić strukturę: Kontrakt, Zakres, Zmiany, Odbiory, Komunikacja, Artefakty (Figma), Ticketing, Changelog, Rozliczenia.
2. Ujednolicić nazewnictwo: ten sam identyfikator funkcji/ekranu w Figmie i w ticketach.
3. Archiwizować cyklicznie: snapshoty na koniec sprintu lub etapu.
4. Spinać z rozliczeniem: faktura lub etap płatności powinny wskazywać, co zostało odebrane.

Ryzyka dla zarządu i firmy przy braku dokumentacji

Fakt: brak dokumentacji zwiększa ryzyko przegrania sporu dowodowego, a w konsekwencji utraty należności albo konieczności zwrotu części wynagrodzenia (w zależności od roszczeń). Opinia: w spółkach technologicznych ryzyko reputacyjne bywa równie kosztowne jak ryzyko finansowe, bo spór o „niedostarczony UX” łatwo eskaluje w relacjach z inwestorem, audytem lub w kolejnych przetargach.

W wątkach compliance warto też pamiętać, że niespójna dokumentacja finansowa i kontraktowa w B2B może zwiększać ryzyko pytań ze strony organów podatkowych, w tym w ramach kontroli celno-skarbowej prowadzonej przez Krajową Administrację Skarbową, jeżeli dokumentacja jest niespójna względem faktycznego przebiegu współpracy.

Praktyczna rekomendacja: minimalny „pakiet dowodowy” na 30 dni

• zaktualizować załącznik zakresu i procedurę zmian,
• wprowadzić obowiązkowy protokół odbioru etapowego (nawet 1 strona),
• ustalić, że każde CR ma osobny ticket i wpis do changelogu,
• robić eksport Figmy i sprintu do archiwum po każdym odbiorze,
• powiązać faktury z etapami i identyfikatorami z backlogu.

Materiał ma charakter informacyjny i nie stanowi porady prawnej; w razie sporu o ryczałt lub konieczności ułożenia procesu dowodowego w organizacji warto zlecić analizę dokumentów i artefaktów projektu kancelarii Kopeć & Zaborowski, dlatego w sprawie dalszych kroków najlepiej skontaktować się bezpośrednio przez właściwą stronę internetową kancelarii.

FAQ: teczka dowodowa dla usług UI/UX na B2B

Czy w umowie UI/UX lepszy jest ryczałt czy time & material?

To zależy od stabilności wymagań i dojrzałości procesu zmian. Ryczałt wymaga precyzyjnego zakresu i procedury change request, inaczej spór przenosi się na interpretację „co było w cenie”.

Czy Figma może być dowodem w sądzie?

Może, ale praktycznie istotna jest możliwość wykazania wersji na konkretną datę oraz autorstwa i treści komentarzy. Dlatego zaleca się archiwizację snapshotów (np. eksport PDF) na moment odbioru.

Jak udowodnić, że klient zaakceptował etap bez podpisanego protokołu?

Pomocne są jednoznaczne akceptacje mailowe, zamknięcie ticketów jako „Accepted/Done” przez osobę decyzyjną oraz dowód przekazania kompletnej paczki rezultatów do odbioru. Skuteczność zależy od postanowień umowy i praktyki współpracy.

Czy „drobne poprawki” zawsze mieszczą się w ryczałcie?

Nie zawsze. Jeżeli poprawki wynikają z nowych wymagań biznesowych, a nie z wad, mogą stanowić zmianę zakresu. Kluczowe jest rozróżnienie i konsekwentne tagowanie w ticketach oraz changelogu.

Jakie minimum powinien mieć protokół odbioru UI/UX?

Co najmniej: opis etapu, lista dostarczonych artefaktów z identyfikatorami wersji, data przekazania, decyzja (odebrano/warunkowo/odmowa), lista uwag i terminy ich zamknięcia.

Czy backlog i ticketing muszą być po stronie klienta, żeby miały wartość dowodową?

Nie. Wystarczy, aby strony faktycznie z nich korzystały i aby dało się wykazać integralność danych (eksporty, logi, spójne identyfikatory). Dodatkowo warto ustalić w umowie, że wskazane narzędzia są kanałem roboczym i służą do zatwierdzeń.

Bibliography