Prawa autorskie do UI i UX: kiedy projekt graficzny jest utworem

UI, UX i prawa autorskie – podstawowe punkty wyjścia

Czym jest utwór w rozumieniu prawa autorskiego

Polskie prawo autorskie – podobnie jak większość systemów europejskich – nie chroni „wszystkiego, co zostało zrobione”, ale tylko utwory. Zgodnie z art. 1 ustawy o prawie autorskim i prawach pokrewnych, utworem jest każdy przejaw działalności twórczej o indywidualnym charakterze, ustalony w jakiejkolwiek postaci. To nie jest sucha definicja – z tych kilku słów wynika większość sporów o UI i UX.

Aby projekt graficzny interfejsu (UI) czy koncepcja doświadczenia użytkownika (UX) były chronione, muszą spełniać jednocześnie kilka warunków:

• przejaw działalności twórczej – coś więcej niż odtwórcze klikanie w generator;
• indywidualny charakter – efekt pracy ma odróżniać się od innych rozwiązań, a nie być standardową kalką;
• ustalenie – projekt musi przyjąć jakąś postać: plik Figma, szkic, prototyp, makieta.

Jeżeli któryś z tych elementów zawodzi, powstaje „produkt”, ale niekoniecznie powstaje utwór w rozumieniu prawa autorskiego.

Granica między pomysłem a utworem w projektowaniu

Prawo autorskie nie chroni pomysłów, koncepcji, idei. Chronione jest dopiero ich konkretne, twórcze wyrażenie. W projektowaniu UI/UX to rozróżnienie bywa wyjątkowo bolesne: sam pomysł „aplikacji do rezerwacji stolika jednym kliknięciem” nie jest chroniony, natomiast określony layout ekranu, oryginalny sposób prowadzenia użytkownika, charakterystyczne ikony czy mikrointerakcje – już jak najbardziej mogą być.

Dwie osoby mogą niezależnie od siebie zaprojektować podobne ekrany logowania. Jeśli obaj projektanci nie „ściągali” od siebie, każdy z nich może mieć prawa autorskie do swojego projektu, mimo podobieństwa. Prawu autorskiemu jest obojętne, ile podobnych aplikacji istnieje na rynku – liczy się indywidualna twórczość w konkretnym przypadku.

UI vs UX – co właściwie może być utworem

W praktyce warto rozdzielić dwie warstwy:

• UI (User Interface) – warstwa wizualna: kolorystyka, typografia, układ elementów, ikony, ilustracje, komponenty, animacje;
• UX (User Experience) – sposób prowadzenia użytkownika: architektura informacji, mapy ekranów, przepływy, scenariusze interakcji, mikrocopy, fokus na zadaniach użytkownika.

UI ma charakter przede wszystkim graficzny, a więc bardzo naturalnie wpisuje się w katalog chronionych utworów (utwory plastyczne, graficzne, wzornicze). UX bywa bardziej abstrakcyjny: sama „ścieżka typu: lista → koszyk → checkout” będzie raczej pomysłem, ale już konkretny sposób jej zaprojektowania – opisany, narysowany, wyrażony w makiecie – może przybrać formę utworu.

To właśnie w tej przestrzeni, pomiędzy abstrakcyjną koncepcją UX a konkretnym, zwizualizowanym projektem UI/UX, najczęściej pojawia się pytanie: „czy to już jest utwór?”. Odpowiedź zawsze zależy od konkretu, ale można wyznaczyć pewne typowe sytuacje i kryteria.

Kiedy projekt UI staje się utworem w rozumieniu prawa

Oryginalność i indywidualność projektu graficznego

Dla projektów UI kluczowe są dwa pojęcia: oryginalność i indywidualność. Oryginalność nie oznacza czegoś absolutnie nowego w skali świata, tylko to, że projekt nie jest zwykłym powieleniem gotowych schematów. Indywidualność oznacza, że projekt „nosi ślad osobowości twórcy” – można w nim dostrzec konkretne wybory estetyczne i kreatywne, a nie jedynie mechaniczne odtworzenie wytycznych.

Przykładowo, ekran listy produktów może korzystać z typowego wzorca (miniaturka – tytuł – opis – cena – przycisk „Dodaj”), ale jeśli:

• zastosowano charakterystyczną siatkę,
• opracowano autorski system ikon i przycisków,
• wprowadzono nietypowy sposób prezentacji zdjęć,
• dodano spójną, oryginalną ilustracyjną stylistykę,

to taki layout może spełniać przesłanki utworu, nawet jeśli jego ogólna logika jest „branżowym standardem”. Standard to kontekst, nie wyrok.

Elementy UI, które najczęściej stanowią utwór

W praktyce projektowej można wskazać kilka kategorii elementów UI, które najczęściej są samodzielnymi utworami lub fragmentami większego utworu:

• Zestaw ekranów aplikacji – spójne wizualnie, tworzące całość pod względem stylu i kompozycji.
• System designu (design system) – biblioteka komponentów, ikon, stylów, układów, przewodnik po stosowaniu tych elementów.
• Autorskie ikony i ilustracje – zaprojektowane „od zera”, a nie pobrane z darmowej bazy typu „flat icon”.
• Animacje i mikrointerakcje – na przykład unikalny sposób przejścia między ekranami albo autorska animacja ładowania.
• Nietypowe layouty – zwłaszcza w projektach marketingowych, landing page’ach, dashboardach.

To, że projektanci posługują się np. biblioteką Material UI czy wytycznymi iOS, nie wyklucza powstania utworu. Twórczość przenosi się wówczas na poziom konkretnej kompozycji, doboru elementów i stylu, a nie pojedynczych „cegiełek”.

Granica między standardem branżowym a ochroną prawnoautorską

W projektowaniu interfejsów istnieje szeroki katalog wzorów znormalizowanych: formularze logowania, koszyki, filtry, sortowanie, nawigacja dolna w aplikacjach mobilnych. W tych przypadkach o ochronie często rozstrzyga pytanie: ile w tym projekcie jest „standardu”, a ile autorskiej inwencji.

Przykłady rozwiązań, które zazwyczaj nie będą samodzielnym utworem:

• klasyczny formularz logowania: logo + e-mail + hasło + checkbox + przycisk, bez oryginalnych ingerencji graficznych,
• prosty ekran listy w stylu typowego UI systemowego, bez autorskiej typografii i stylu,
• wnętrze aplikacji zbudowane niemal wprost na gotowym szablonie z marketplace’u.

Natomiast gdy projektant świadomie „wychodzi poza szablon”, dodaje oryginalne kompozycje, ilustracje, odważne decyzje typograficzne – powstaje utwór, nawet jeśli w jego wnętrzu kryją się znane z branży wzorce nawigacji. Ochrona nie dotyczy samej idei „menu hamburgerowego”, lecz konkretnego sposobu zaprojektowania tego menu.

UX a prawo autorskie – czy doświadczenie użytkownika może być utworem

Co w UX jest tylko ideą, a co może być chronione

UX obejmuje szeroki zakres działań: od badań, przez makiety low-fi, po finalne prototypy hi-fi i scenariusze użycia. Prawnie można tu wyróżnić kilka warstw:

• Abstrakcyjne założenia – np. „użytkownik ma dotrzeć do płatności w maksymalnie trzech krokach”. To jest pomysł, nieutwór.
• Architektura informacji w formie prostych list, drzew, schematów blokowych – często zbyt ogólna, aby sama w sobie stanowiła przejaw indywidualnej twórczości.
• Konkretnie opracowane makiety i prototypy – zwłaszcza gdy zawierają unikalny układ treści, autorskie teksty, specyficzne sekwencje ekranów.
• Scenariusze interakcji opisane narracyjnie – np. „User journey map” z rozbudowaną warstwą tekstową i wizualną, która wychodzi poza prostą tabelkę.

Czysty „flow” typu: „ekran A → ekran B → ekran C” to raczej koncepcja. Ale rozbudowana, graficzna mapa podróży użytkownika, z autorskimi opisami, ilustracjami, sposobem wyróżnienia etapów i emocji użytkownika, może być już traktowana jako utwór (utwór słowno-graficzny).

Makiety low-fi, high-fi i prototypy klikane

Makieta low-fi (prostokąty, proste placeholdery, odręczne rysunki) nie jest z góry wyłączona spod ochrony. Jeżeli w układzie, zestawieniu elementów i sposobie prowadzenia wzroku pojawia się indywidualna koncepcja, to nawet prosty szkic może być utworem. Sąd raczej nie będzie analizował estetyki szkicu, lecz oryginalność kompozycji.

Makiety high-fi i prototypy klikalne często zawierają już elementy zachodzące na UI: konkretną kolorystykę, typografię, elementy graficzne. Wówczas ochronę ocenia się łącznie – jako utwór graficzny/interaktywny. To, że prototyp jest jeszcze „niekodowany”, nie ma znaczenia – utwór powstaje już w momencie ustalenia w Figma, XD, Sketch czy innym narzędziu.

W praktyce:

• jeśli low-fi jest jedynie odtworzeniem typowego szablonu (np. siatka kafelków z biblioteki UI), może nie być utworem,
• jeśli high-fi zawiera oryginalną oprawę wizualną i nieszablonowe rozwiązania, prawdopodobieństwo ochrony jest znacznie wyższe.

Dokumentacja UX, persony i user journey a prawa autorskie

Wiele materiałów UX-owych ma charakter tekstowy i koncepcyjny: persony, opisy scenariuszy, raporty z badań. Tu także może pojawić się ochrona, o ile dokumenty nie są wyłącznie mechanicznym wypełnieniem szablonu.

Przykłady materiałów UX, które często stanowią utwór:

• rozbudowane persony z opisami zachowań, cytatami, charakterystycznymi ilustracjami,
• mapy empatii z autorską warstwą opisową i graficzną,
• raporty z badań UX, w których wnioskowanie, opis, wizualizacja danych mają twórczy charakter,
• autorskie metody oceny użyteczności opisane i zilustrowane w oryginalny sposób.

Trzeba odróżnić twórcze treści od „pustej tabeli”. Format Excela, pusta siatka Miro czy gotowy szablon Notion nie są utworami. Utworem może być to, co zostało w nich wypełnione – jeżeli ma indywidualny, twórczy charakter (a nie jest tylko listą suchych faktów).

Przykłady projektów UI/UX, które zwykle są chronione lub nie

Typowe przypadki interfejsów objętych ochroną

Aby łatwiej ocenić własny projekt, można sięgnąć po przykłady typowych rozstrzygnięć, stosując uproszczoną klasyfikację:

W takich przykładach nawet jeśli poszczególne klocki (np. typowy przycisk CTA) są „branżowym standardem”, to całość kompozycji i stylizacje nadają projektowi charakter indywidualny.

Przypadki graniczne – UI „składany” z gotowych szablonów

Coraz częściej projekty powstają w oparciu o gotowe biblioteki i szablony: Bootstrap, Material Design, Tailwind, komercyjne zestawy UI. Tu pojawiają się dwie kwestie:

• prawa do samej biblioteki/szablonu – regulowane licencją dostawcy,
• twórczość w sposobie wykorzystania tych elementów.

Jeżeli projektant:

• korzysta z komponentów 1:1 zgodnie z dokumentacją,
• nie zmienia znacząco stylów,
• zachowuje standardowe układy i spacingi,

Skutki korzystania z gotowych bibliotek dla ochrony projektu

W takim scenariuszu wynik często będzie traktowany jako implementacja cudzego wzorca, a nie samodzielny utwór. Pojawia się wówczas problem „podwójnej zależności”:

• od licencji biblioteki (co wolno zmieniać, kopiować, komercyjnie wykorzystywać),
• od poziomu autorskiej ingerencji projektanta (czy dodano coś rzeczywiście własnego).

Sytuacja zmienia się, gdy projektant:

• mocno modyfikuje style (typografia, siatka, rytm pionowy, mikrointerakcje),
• tworzy nowe układy ekranów, których nie ma w dokumentacji biblioteki,
• łączy komponenty w oryginalne wzorce interakcji i narracji wizualnej.

Wtedy całość może być już utworem zależnym wobec biblioteki (opartym na cudzym utworze), ale w dalszym ciągu chronionym w zakresie własnych, twórczych elementów. Z punktu widzenia praktyki biznesowej oznacza to, że:

• trzeba przestrzegać licencji (np. zakaz odsprzedaży szablonu „as is”),
• projektant może mieć swoje prawa do autorskich modyfikacji i kompozycji.

Dlaczego ocena „czy to utwór” nigdy nie jest zero-jedynkowa

Prawo autorskie posługuje się pojęciami „indywidualny” i „twórczy”, które są nieostre. Sąd, biegły czy prawnik oceniają projekt całościowo, zadając sobie kilka praktycznych pytań:

• Czy inny projektant, mając to samo zadanie, stworzyłby raczej coś innego?
• Czy w projekcie widać styl autora, czy jest to poprawne rzemiosło według wzorca?
• Czy projekt da się rozpoznać wśród innych, czy ginie w tłumie podobnych realizacji?

Dwa bardzo podobne ekrany listy produktów mogą być ocenione odmiennie: jeden jako zwykłe odtworzenie wzorca, drugi – jako element szerszej, twórczej koncepcji (np. storytellingu wizualnego w całej aplikacji). Granica przebiega często nie na poziomie pojedynczego ekranu, lecz całego systemu doświadczenia.

Prawa do UI/UX w relacji projektant – klient – software house

Kto jest twórcą interfejsu i doświadczenia użytkownika

W projektach cyfrowych rzadko występuje „samotny autor”. Tworzą je:

• projektanci UI i UX,
• copywriterzy i content designerzy,
• grafice 2D/3D, motion designerzy,
• developerzy, którzy czasem wnoszą własne rozwiązania animacji czy efektów.

Tworzy się w ten sposób utwór współautorski. Każda z osób, która wniosła twórczy wkład (nie tylko „techniczną pracę”), może mieć do niego prawa. To ma praktyczne skutki:

• sam designer nie może „sprzedać” pełni praw, jeśli część interfejsu to np. autorskie ilustracje innej osoby,
• software house powinien dbać o umowy z całym zespołem, a nie tylko z klientem końcowym.

Współautorstwo nie dotyczy wyłącznie warstwy graficznej. Specjalista UX, który tworzy autorską strukturę aplikacji, scenariusze interakcji i opisy ekranów, również może być współtwórcą – nawet jeśli nie „przeciąga pikseli” w Figmie.

Umowa z projektantem: przeniesienie praw czy licencja

Przy ustalaniu zasad korzystania z UI/UX spotyka się zwykle dwa modele:

• przeniesienie autorskich praw majątkowych – klient staje się właścicielem utworu w określonych polach eksploatacji,
• licencja (wyłączna lub niewyłączna) – projektant zachowuje prawa, a klient otrzymuje określone uprawnienia do korzystania.

Dla UI/UX kluczowe są zwłaszcza takie pola eksploatacji:

• utrwalanie i zwielokrotnianie w pamięci urządzeń i na serwerach,
• publiczne udostępnianie w sieci (aplikacje, serwisy www, SaaS),
• tworzenie i wykorzystanie opracowań (modyfikacje layoutu, redesign, lokalizacje językowe),
• wprowadzanie do obrotu produktów, które wykorzystują projekt (np. white-label apps).

W praktyce dobrze skonstruowana umowa dla projektu cyfrowego:

• precyzuje, czy klient może samodzielnie rozwijać UI/UX bez udziału pierwotnego projektanta,
• rozróżnia elementy oryginalne od zasobów zewnętrznych (ikony z licencji stockowej, fonty, zdjęcia),
• reguluje, czy projektant może wykorzystywać fragmenty systemu (np. komponenty) w innych zleceniach.

Prawa osobiste projektanta a późniejszy redesign

Oprócz praw majątkowych istnieją także autorskie prawa osobiste, których co do zasady nie można zbyć. Projektant UI/UX zachowuje m.in.:

• prawo do autorstwa (bycia wskazanym jako twórca),
• prawo do nienaruszalności formy i treści utworu,
• prawo nadzoru nad sposobem korzystania z utworu.

To może generować konflikty przy gruntownym redesignie. Klient zmienia layout, kolorystykę, typografię, a autor pierwotnego projektu twierdzi, że naruszono jego koncepcję. Zderzają się tu dwie potrzeby:

• elastyczności biznesowej klienta (aplikacja musi się rozwijać),
• ochrony integralności dzieła (zakaz „okaleczania” projektu).

Rozwiązaniem są postanowienia umowne:

• zgoda projektanta na dokonywanie zmian bez dodatkowej akceptacji,
• określenie, że po wdrożeniu redesignu autor może żądać usunięcia swojego nazwiska z oznaczeń projektu,
• ewentualne zrzeczenie się wykonywania części praw osobistych (w granicach, które akceptuje praktyka orzecznicza).

Inspiracja, kopiowanie i „klony” interfejsów

Inspiracja cudzym UI kontra plagiat

Projektanci często korzystają z galerii typu Dribbble, Behance, Awwwards, podglądają aplikacje konkurencji. Samo zainspirowanie się cudzym projektem nie jest zakazane – zastrzeżenia pojawiają się, gdy:

• zostaje powielona konkretna kompozycja ekranów,
• powtarza się charakterystyczny zestaw elementów (kolory, layout, ikonografia, animacje) w sposób rozpoznawalny,
• użytkownik przeciętny mógłby pomylić oba interfejsy.

Kopiowanie jednej ikony czy pojedynczego ekranu może nie wystarczyć do uznania plagiatu, ale „przerysowanie” całego systemu – już tak. Sądy porównują zwykle ogólne wrażenie oraz konkretne, oryginalne rozwiązania, nie zaś drobne różnice typu inny kolor przycisku.

„Klony” popularnych aplikacji a odpowiedzialność prawna

Rynek gier mobilnych, marketplace’ów czy fintechu zna wiele przypadków aplikacji do złudzenia przypominających liderów. Technicznie mogą różnić się funkcjonalnością, ale:

• nawigacja,
• układ kluczowych ekranów,
• styl ilustracji i animacji

są niemal identyczne.

W takim przypadku dochodzić można nie tylko naruszenia praw autorskich do UI, ale też:

• czynu nieuczciwej konkurencji (wprowadzanie w błąd co do pochodzenia produktu),
• naruszenia praw ochronnych do znaków towarowych (np. podobne logo, nazwa, ikona aplikacji).

Odpowiedzialność nie zawsze spada wyłącznie na projektanta. Jeśli produkt wypuszcza software house lub spółka produktowa, to właśnie one są zazwyczaj pierwszym adresatem roszczeń. Projektant natomiast może odpowiadać wobec klienta na zasadzie regresu, jeśli w umowie gwarantował oryginalność i wolność od wad prawnych.

„Dark patterns” i nadużycia w UX a prawo

Choć ciemne wzorce (dark patterns) to przede wszystkim problem etyczny i regulacyjny (RODO, prawo konsumenckie), łączą się także z prawem autorskim. Projektant może:

• tworzyć oryginalne, ale manipulacyjne ścieżki użytkownika,
• kopiować istniejące dark patterns z innych serwisów.

Twórczość formalna nie legalizuje jednak naruszeń innych przepisów. Można mieć pełnię praw autorskich do szkodliwego wzorca UX, ale jego zastosowanie i tak naruszy prawo ochrony konsumentów, prywatności czy dobre obyczaje. W skrajnych przypadkach projektant, który świadomie projektuje systemy wprowadzające w błąd, może być objęty roszczeniami regresowymi klienta.

Dowody twórczości i praktyczne zabezpieczenie swoich praw

Jak dokumentować proces powstawania UI/UX

Spory o autorstwo i plagiat UI/UX często rozbijają się o brak dowodów. Z perspektywy projektanta pomocne są:

• zachowane wersje plików (historie wersji w Figmie, Sketchu, repozytorium design systemu),
• datowane szkice, notatki, makiety low-fi,
• komunikacja z klientem lub zespołem (maile, ticketing), pokazująca, kto zaproponował konkretne rozwiązania,
• eksporty PDF/PNG z datą utworzenia.

Dzięki temu można później pokazać ciągłość pracy i wskazać, że dany interfejs powstał przed projektem konkurencyjnym. W procesach sądowych biegli często analizują także metadane plików i historię repozytoriów.

Clauzule umowne, które pomagają uniknąć konfliktów

W kontraktach na projektowanie UI/UX przydają się zapisy:

• o tym, kto i w jakim zakresie jest twórcą (np. wskazanie podwykonawców),
• o sposobie przeniesienia praw lub udzielenia licencji wraz z polami eksploatacji,
• o odpowiedzialności za naruszenie praw osób trzecich (gwarancja oryginalności, oświadczenia projektanta),
• o zasadach wykorzystania szablonów i bibliotek UI (stock, marketplace, open source),
• o możliwości modyfikacji, rozwijania i refaktoryzacji interfejsu przez klienta.

Dla dużych produktów cyfrowych rozsądne jest też wyraźne rozdzielenie:

• praw do design systemu (biblioteka komponentów, tokeny),
• praw do konkretnych ekranów zaprojektowanych w ramach projektu.

Pozwala to np. przenieść na klienta prawo do korzystania z gotowego systemu komponentów w wielu produktach, przy jednoczesnym zachowaniu przez projektanta możliwości rozwijania jego wersji w innych branżach w zmodyfikowanej formie.

Specyficzne przypadki w projektowaniu UI/UX

Design system jako przedmiot ochrony

Systemy projektowe (Design Systems) łączą w sobie:

• warstwę wizualną (komponenty, style),
• warstwę semantyczną (nazewnictwo, tokeny, zasady stosowania),
• warstwę dokumentacyjną (guidelines, przykłady użycia).

Jako całość często stanowią złożony utwór. Ochronie może podlegać:

• konkretny wygląd komponentów,
• układ i forma dokumentacji (np. oryginalna prezentacja zasad typografii, kolorów, case studies),
• charakterystyczne nazwy i metafory stosowane w systemie.

Samo użycie słów typu „primary”, „secondary”, „danger” nie jest oczywiście chronione – to standard. Ale rozbudowana terminologia, wykorzystująca np. metafory świata gry czy muzyki, już może nosić cechy indywidualnej twórczości.

UI generowany przez sztuczną inteligencję

Coraz bardziej powszechne są narzędzia generujące layouty, ikony lub całe ekrany na podstawie promptów tekstowych. W takim środowisku pojawiają się pytania:

• czy wygenerowany UI jest w ogóle utworem w rozumieniu prawa autorskiego,
• kto, jeśli w ogóle, jest jego twórcą.

W aktualnym podejściu wielu systemów prawnych centralne jest założenie, że utwór musi pochodzić od człowieka. Jeśli narzędzie AI tworzy projekt w sposób w pełni automatyczny, bez istotnej, twórczej ingerencji użytkownika, powstają poważne wątpliwości co do zakresu ochrony.

Jeżeli jednak designer:

• traktuje wynik z AI jako punkt wyjścia,
• mocno go przerabia,
• wprowadza własne decyzje kompozycyjne, typograficzne i narracyjne,

Najczęściej zadawane pytania (FAQ)

Czy mój projekt UI jest automatycznie chroniony prawem autorskim?

Projekt UI jest chroniony prawem autorskim tylko wtedy, gdy spełnia kryteria „utworu” z ustawy: jest przejawem działalności twórczej, ma indywidualny charakter i został utrwalony (np. w Figmie, jako makieta, prototyp czy plik graficzny). Sama techniczna realizacja standardowego szablonu nie zawsze wystarczy.

Jeżeli interfejs powstał głównie przez „przeklikanie” gotowego template’u lub kopiowanie popularnych rozwiązań, bez własnych, oryginalnych decyzji projektowych, może zostać uznany za produkt, ale nie za utwór w rozumieniu prawa autorskiego.

Co dokładnie w UI może być utworem chronionym prawem autorskim?

Najczęściej ochroną prawnoautorską obejmowane są całe zestawy ekranów oraz ich wizualna koncepcja: kolorystyka, układ elementów, typografia, system ikon, ilustracje, animacje i mikrointerakcje, jeśli razem tworzą oryginalną, spójną całość. Nie chodzi o pojedynczy przycisk, ale o twórczy sposób ich zestawienia.

Za samodzielne utwory mogą uchodzić m.in. design system (biblioteka komponentów i wytyczne ich stosowania), autorskie zestawy ikon i ilustracji oraz nietypowe layouty np. stron landing page czy dashboardów, które wyraźnie odbiegają od prostych, powtarzalnych schematów.

Czy standardowy ekran logowania albo koszyk w e‑sklepie podlega ochronie?

Typowy ekran logowania (logo + e‑mail + hasło + checkbox + przycisk) czy standardowy koszyk z listą produktów, bez oryginalnej grafiki i nietypowych rozwiązań, zwykle nie będą samodzielnym utworem. Są traktowane jako branżowy standard, który każdy może stosować.

Ochrona może pojawić się dopiero wtedy, gdy projektant świadomie „wychodzi poza” wzorce – np. tworzy unikalną kompozycję, oryginalną typografię, własne ilustracje albo charakterystyczną animację przejść. Chroniony jest konkretny sposób zaprojektowania ekranu, a nie sama funkcja „logowanie” czy „koszyk”.

Czy UX (doświadczenie użytkownika) też może być chronione prawem autorskim?

Same pomysły UX – np. „użytkownik ma wykonać zakup w trzech krokach” – nie są chronione, bo prawo autorskie nie obejmuje idei ani koncepcji. Podobnie ogólne flow w stylu „ekran A → ekran B → ekran C” zwykle nie wystarczy, by mówić o utworze.

Ochrona może dotyczyć dopiero konkretnego, twórczego wyrażenia UX, np. rozbudowanych makiet i prototypów, graficznych map podróży użytkownika z autorskimi opisami i ikonografią, czy scenariuszy interakcji opisanych w oryginalny, indywidualny sposób (utwór słowno‑graficzny).

Czy makiety low‑fi i szkice UX mogą być utworem?

Makiety low‑fi i odręczne szkice nie są z góry wyłączone z ochrony. Jeżeli w ich układzie, sposobie prowadzenia wzroku, rozmieszczeniu bloków treści czy w opisie interakcji widać indywidualną, twórczą koncepcję, to nawet prosty rysunek może być utworem.

Sąd – gdyby doszło do sporu – nie będzie oceniał, czy szkic jest „ładny”, ale czy zawiera oryginalny, indywidualny pomysł na ukształtowanie interfejsu lub ścieżki użytkownika, wykraczający poza zwykłe powielenie typowych schematów.

Czy korzystanie z Material UI lub wytycznych iOS wyklucza powstanie utworu?

Nie, korzystanie z gotowych bibliotek komponentów (np. Material UI) czy guideline’ów systemów (iOS, Android) nie wyłącza ochrony prawnoautorskiej. Standardowe komponenty są „cegiełkami”, z których można tworzyć bardzo różne, mniej lub bardziej twórcze projekty.

Utworem może być oryginalny sposób ich połączenia: autorska kompozycja ekranów, dobór kolorów, typografii, ikon, animacji i layoutu. Ochrona nie obejmuje samych guideline’ów ani komponentów, ale to, co projektant z nich „zbuduje”, już może być chronione.

Jak sprawdzić, czy mój projekt UI/UX jest wystarczająco „twórczy” dla ochrony?

Nie ma jednego testu, ale pomocne są pytania:

• Czy podobny efekt uzyskałby każdy, kto weźmie ten sam szablon lub bibliotekę i „ustawi wszystko według instrukcji”?
• Czy w projekcie widać Twoje autorskie wybory estetyczne i koncepcyjne (kompozycja, styl, mikrointerakcje, teksty), których nie da się uznać za czystą kalkę standardów?

Jeśli odpowiedź na drugie pytanie brzmi „tak”, rośnie szansa, że projekt będzie traktowany jako utwór.

W razie wątpliwości warto zadbać o dokumentację procesu projektowego (iteracje, szkice, warianty), która pokazuje, że nie jest to tylko złożenie gotowego szablonu, lecz efekt indywidualnej pracy twórczej.

Najbardziej praktyczne wnioski

• Ochroną prawa autorskiego objęte są tylko utwory – czyli przejawy działalności twórczej o indywidualnym charakterze, utrwalone w jakiejkolwiek postaci (np. makieta, prototyp, plik projektowy).
• Prawo autorskie nie chroni samych pomysłów ani koncepcji UX; chronione jest dopiero ich konkretne, twórcze wyrażenie w postaci m.in. layoutów, scenariuszy czy makiet.
• Zarówno UI, jak i UX mogą być utworami: UI z reguły jako projekt graficzny, a UX wtedy, gdy przybiera formę zmaterializowanego, oryginalnego rozwiązania (np. opisanych flow, map ekranów, makiet).
• Oryginalność UI nie wymaga „wynalezienia koła na nowo” – wystarczy, że projekt nie jest mechanicznym powieleniem schematów i nosi widoczny „ślad” decyzji twórczych projektanta.
• Typowe elementy UI, które często są utworami, to m.in. zestawy ekranów, spójne design systemy, autorskie ikony i ilustracje, unikalne animacje oraz charakterystyczne layouty.
• Korzystanie z gotowych bibliotek (np. Material UI, wytyczne iOS) nie wyklucza ochrony – twórczość może przejawiać się w kompozycji, stylu i doborze elementów.
• Standardowe, „szablonowe” ekrany (np. proste logowanie, lista oparta na systemowym UI, gotowy template z marketplace’u) zwykle nie będą samodzielnymi utworami, jeśli brakuje w nich autorskiej inwencji graficznej.