Dbamy o Twoją prywatność

Pliki cookie są ważne dla prawidłowego funkcjonowania witryny. Aby poprawić Twoje doświadczenia, używamy plików cookies, które zbierają statystyki w celu optymalizacji funkcjonowania serwisu. Kliknięcie przycisku „Akceptuję wszystkie” oznacza, że ​​wyrażasz zgodę na wszystkie pliki cookie. Aby zmienić zgodę, kliknij „Ustawienia zaawansowane”. Szczegółowe informacje o plikach cookies oraz nasza informacja o ochronie prywatności znajducookies oraz nasza informacja o ochronie prywatności znajduje się tutaj: polityka cookies.

Przejdź do głównej zawartości strony
  • Ludzie

Prawo jako strażnik procesu projektowego

Zespół Projektowania UX III

Klaudia Kofin-Brończyk, Joanna Konopińska-Manthey, Juliusz Łabęcki

Podczas pracy nad produktem cyfrowym następuje moment, w którym prawo daje o sobie znać. Czasami musimy coś dostosować ze względu na ustawę czy wprowadzić nową funkcję. Pewnie kojarzy Ci się to z ograniczeniami w tworzeniu czy problemem, który trzeba szybko rozwiązać? Jest jeszcze jedna strona medalu. W Centralnym Ośrodku Informatyki to właśnie prawo wyznacza kierunek działań w procesie powstawania produktów cyfrowych. Jasne, że na co dzień mierzymy się z różnego rodzaju wyzwaniami.

Grudzień 2024 | Przeczytasz w: 15 minut

Wymagania prawne bywają wyzwaniem

Choć w tym artykule skupiamy się na pozytywnych aspektach, to oczywiście tworzenie produktów czy usług wynikających z prawa może się też wiązać z wyzwaniami i ograniczeniami. Z naszego doświadczenia jest to najczęściej:

  1. Ograniczenie w dalszym rozwoju
    Zbyt szczegółowy opis prawny usługi może utrudnić jej dalszy rozwój -jak przy każdym produkcie, w ramach jego używania, pojawiają się pomysły na usprawnienia, wychodzą nieprzewidziane scenariusze użycia i błędy logiczne. Poprawienie takiej usługi wymaga wówczas niestety zmiany ustawy, a to często nie jest łatwe i może zająć bardzo dużo czasu.
  2. Ograniczona kreatywność
    Wspomniana wcześniej zbytnia szczegółowość opisu usługi w akcie prawnym ogranicza również kreatywność analityków biznesowych i projektantów. Nawet jeśli w trakcie prac projektowych, powstanie lepszy pomysł realizacji potrzeby użytkowników, to sama ustawa może takie usprawnienie uniemożliwić.
  3. Uzależnienie od prawa jako ryzyko projektowe
    W niektórych przypadkach legislacja i jej zmienność może stanowić istotne ryzyko projektowe. Przykładem może tu być wpływ ustaw związanych z tzw. Polskim Ładem i częstotliwość ich zmian. Wymuszały one wiele modyfikacji we wszystkich usługach i produktach związanych z księgowością.
  4. Dług technologiczny
    Jeśli w akcie prawnym pojawiają się nazwy konkretnych rozwiązań technologicznych, to w dłuższej perspektywie może to stanowić istotny dług technologiczny. W związku z dynamicznym rozwojem technologii, wymuszanie konkretnych rozwiązań w legislacji jest bardzo ryzykowne. Biorąc pod uwagę, że od napisania aktu prawnego, do jego wejścia w życie często mija kilka lat, może się okazać, że już w momencie wejścia usługi do użytku, zastosowane rozwiązanie jest przestarzałe.

 

I choć są to kwestie znane pewnie wszystkim twórcom rozwiązań cyfrowych, to w tym momencie zmieńmy perspektywę. Spójrzmy, co daje nam prawo i jak wspiera powstawianie lepszych rozwiązań.

Usługi definiowane przez prawo

W ostatnich latach cyfryzujemy coraz więcej usług publicznych w Polsce. Standardem stały się e-recepty, a w trakcie wyborów możemy legitymować się mDowodem w aplikacji mobilnej. Za każdym z tych rozwiązań stoi jakaś ustawa. Testrony artykułów i paragrafów, które niejednego mogą przerazić, nie tylko definiują daną usługę, ale również zapewniają jej wdrożenie przez odpowiednie podmioty.

 

Po stronie projektowej taka ustawa to ni mniej ni więcej tylko odpowiednik dokumentacji znanej z rozwiązań komercyjnych. Oczywiście, często taka “dokumentacja” jest bardziej skomplikowana, odnosi się do wielu innych aktów prawnych i wymaga pomocy prawników do przełożenia jej na język produktowy. Na szczęście akty prawne w procesie projektowania usług publicznych to nie tylko ograniczenia i wymagania. To również cała masa regulacji, które gwarantują, że powstająca usługa będzie użyteczna, dostępna, napisana prostym językiem, spełni standardy bezpieczeństwa i zapewni ochronę danych osób, które będą z niej korzystać.

 

W naszym, autorów tego artykułu, przypadku takim źródłem jest ustawa o doręczeniach elektronicznych (1), która wprost odpowiada na potrzebę wyrażoną w rozporządzeniu unijnym (2). Prościej mówiąc, pracujemy nad elektronicznym odpowiednikiem listu poleconego za potwierdzeniem odbioru, który określony jest w prawie. Niektóre funkcje czy użyte słownictwo jest wprost przewidziane przez ustawę. Naszą rolą jest sprawienie, by korzystanie z rozwiązania było jak najbardziej użyteczne i nie tylko spełniało wymagania prawne, ale przede wszystkim odpowiadało na potrzeby odbiorców.

Czy użyteczność jest określona w prawie?

Użyteczność nie ma uniwersalnej definicji prawnej. Jednak zgodnie z orzeczeniem Sądu Najwyższego miarą użyteczności są ułatwienia w korzystaniu z produktu (3). Nie sposób nie odnieść się też do normy ISO 9241-11, która definiuje użyteczność jako „stopień, w jakim system, produkt lub usługa może zostać wykorzystana przez określonych użytkowników do osiągnięcia określonych celów ze skutecznością, wydajnością i satysfakcją w określonym kontekście użytkowania (4). Z analizy tych definicji można wyciągnąć wniosek, że użyteczność jest wartością, która ma służyć użytkownikom. Usługa powinna realizować cel, który został postawiony przez użytkownika, a jego wykonanie powinno był relatywnie łatwe, a także skuteczne.

Dostępność cyfrowa

W COI stoimy na straży twierdzenia, że nie ma użyteczności bez dostępności. W związku z tym nie sposób nie wspomnieć o aktach prawnych, które z dostępnością mają wiele wspólnego. Nie będziemy omawiać polskiej ustawy (5), bo to o unijnej dyrektywie o dostępności (6) jest ostatnio najgłośniej . Zgodnie z nią część produktów i usług musi być zaprojektowana w taki sposób, żeby była dostępna dla odbiorców dyrektywy.

 

Dostępne projektowanie nie jest czymś „co można”. Jest czymś „co trzeba” i jasno wynika to z unijnych regulacji prawnych. Każda osoba powinna bez przeszkód móc skorzystać z rozwiązań cyfrowych, takich jak np. serwisy bankowe.  W tym przypadku wymaganie prawne staje się strażnikiem procesu projektowego. Nie musimy odpowiadać na pytania o to, ilu mamy klientów z niepełnosprawnością i czy takie projektowanie się „opłaca”. To po prostu trzeba zrobić.

 

Pamiętasz rewolucję, którą spowodowało RODO? Obecnie obserwujemy podobny proces w kontekście dostosowywania produktów cyfrowych do regulacji European Accessibility Act. To, co do tej pory było dobrą praktyką, 28 czerwca 2025 stanie się obowiązkiem i wiele produktów cyfrowych będzie musiało spełniać standardy dotyczące dostępności. To dobry przykład na to, jak legislacja przyspiesza procesy i idzie w parze ze zmianami społecznymi. Jeszcze kilka lat temu dostępność była jednym z wyróżników dobrego UX, a powoli dla wielu firm staje się obowiązkiem.

 

Namawiamy jednak do tego, by wymagań dotyczących dostępności nie traktować jako przymusu. Po pierwsze dlatego, że po ludzku warto zadbać o osoby, które chcą funkcjonować w świecie tak, jak każdy inny. A po drugie – jeśli ten wzniosły argument jeszcze Cię nie przekonał –  to się po prostu opłaca. Dzięki projektowaniu w zgodzie z dostępnością możesz na przykład zwiększyć grono odbiorców swojego produktu. Jest jeszcze jedna kwestia, o której bardzo często zapominamy. Każdy z nas może czasowo stać się mniej sprawny. Złamana ręka? Zapalenie ucha i trudności ze słyszeniem? To znacznie wpłynie na nasze codzienne funkcjonowanie i zmieni sposób, w jaki postrzegamy niektóre rozwiązania.

 

Dostępność (nie tylko cyfrowa) jest tematem na odrębny artykuł. Jeśli Cię to interesuje, zajrzyj do badań, które przeprowadziły zespoły badawczy i dostępności.

Dark patterns (Akt o Usługach Cyfrowych, AUC)

Mamy dla Was zagadkę. Co łączy:

  • trudny do znalezienia link do anulowania subskrypcji,
  • wymuszanie zakładania konta na platformie,
  • link do anulowania subskrypcji z copy „Nie chcę dalej żyć w zdrowiu”?

 

Jakieś pomysły? Tak! Wszystkie z nich są dark patternami, czy inaczej „zwodniczymi interfesjami” (7). Akt o Usługach Cyfrowych (AUC) definiuje je jako praktyki, które w istotny sposób zniekształcają lub ograniczają zdolność odbiorców do podejmowania niezależnych i świadomych decyzji. Jako osoby projektujące musimy sobie zdawać sprawę, że takie działania są niezgodne z prawem (8). Dlatego kiedy następnym razem biznes przyjdzie do Ciebie z propozycją „chwytliwego” copy na przycisku anulowania subskrypcji, to zamachaj mu przed nosem AUC-em.

Komisja Europejska w swoim w raporcie (9) wskazuje na liczne przykłady dark patternów, które skategoryzowała na podstawie kryterium podmiotowego (np. market place, e-commerce, social media czy zdrowie i fitness). Jako przykłady wymienimy jedynie kilka, ale zachęcamy do zajrzenia do wskazanego opracowania, a także na stronę: https://www.deceptive.design/.

 

  1. Roach motel

Ten dark pattern możemy porównać do labiryntu, z którego trudno się wydostać. Chodzi o ukrywanie informacji lub alternatywnych wyjść podczas przechodzenia przez ścieżkę. Przykładem może być ukryty w tekście przycisk anulowania subskrypcji, zmiana jego koloru na kolor tła, ukrycie go pod kropką albo napisanie fontem o rozmiarze 2. Pół biedy, jeśli znajdziemy przycisk anulowania subskrypcji. Często przykłady tego dark patternu uniemożliwiają anulowanie jednym kliknięciem. Użytkownicy muszą dzwonić na infolinię lub szukać e-maila do obsługi. Konsekwencją jest to, że ludzie płacą za usługę, z której nie korzystają, bo nie potrafią z niej zrezygnować.

 

  1. Confirmshaming

Poczucie wstydu, strachu i bycia złym człowiek – tym karmi się confirmshaming. Często możemy spotkać się z tą praktyką podczas próby rezygnacji z czegoś. Przykładowo w 2018 roku link anulowania subskrypcji firmy Mymedic brzmiał tak: „Nie, wolę wykrwawić się na śmierć” (10). Jest to szczególnie niepokojąca praktyka, ponieważ może uderzyć w osoby chore, które są wystarczająco zestresowane swoim stanem zdrowia. Innym przykładem jest copy: „Nie, nie chcę zaoszczędzić pieniędzy” w przypadku braku chęci wykupienia opcji premium na platformie finansowej. Takie przykłady można mnożyć i jesteśmy pewni, że niejeden możesz przywołać ze swojego doświadczenia.

 

  1. Wymuszanie akcji (najczęściej zakładania konta)

W tym przypadku dostawca wita klienta z otwartymi ramiona, lecz jest to podszyte jakimś wymaganiem. Często opcjonalne działanie jest przedstawione jako wymagane, na przykład za pomocą primary buttona. Przykładem może być wymuszanie zakładania konta, jeśli ktoś chce tylko zapoznać się z funkcjami serwisu. Pod przyciskiem pierwszego rzędu znajdziemy link „Pomiń”, który jednak zupełnie się nie wyróżnia albo jego kontrast w stosunku do tła jest zbyt niski.

 

Przykładów dark patternów jest oczywiście o wiele więcej. Warto śledzić zwłaszcza podmioty e-commerce, w których możemy niestety nadal znaleźć wiele takich wzorców. Podczas projektowania warto zwracać uwagę na to, żeby nie zmuszać użytkowników i użytkowniczek do niekorzystnego dla nich działania. Czasami granica między kreatywnością a dark patternem jest niezwykle cienka i nie warto jej przekraczać.

Rola współpracy interdyscyplinarnej

Każdy, kto pracował przy dowolnym projekcie wie, że współpraca między wszystkimi zaangażowanymi stronami jest kluczowa. W przypadku projektów cyfrowych najczęściej jest to współpraca projektantów z badaczami, programistami, analitykami, projektantami treści, działami prawnym, marketingiem, czy tzw. “biznesem”. Oczywiście każdy z zaangażowanych zespołów jest odpowiedzialny za swoją część projektu, ale im lepiej wszyscy rozumiemy swoje role tym efektywniej możemy razem pracować. Kiedy projektantki czy projektanci znają chociaż podstawy programowania, szybciej tworzą rozwiązania, które są wykonalne i rzadziej słyszą brutalne “nie da się”. Tak samo jest z wymaganiami prawnymi. Im lepiej znamy regulacje prawne, które nas dotyczą, tym rzadziej usłyszymy od działu prawnego “nie możemy tego tak zrobić”. To, co u nas pełni kluczową rolę to przede wszystkim podejście pełne otwartości i ciekawości. Zamiast narzekać na trudne w przyswojeniu ustawy, staramy się szukać osób, które pomogą nam je lepiej zrozumieć i przełożyć na wymagania projektowe. Często są to analitycy czy architekci biznesowi.

 

W 2018 roku jak tsunami przez europejski internet przeszło RODO, czyli rozporządzenie o ochronie danych osobowych. Ten akt prawny wprowadził standard przetwarzania danych osobowych i zmusił wszystkie produkty cyfrowe, aby się do niego dostosować. Dla wielu przedsiębiorców stanowiło to duże wyzwanie w sposobie prowadzenia działalności i często wymagało przebudowy aplikacji, czy serwisów. Obecnie już na etapie projektowania, czy analizy biznesowej rozumiemy jak podchodzić do przetwarzania danych i znamy dobre praktyki, m.in.:

  • nie możemy zaznaczać żadnych zgód w imieniu użytkownika;
  • musimy wytłumaczyć użytkownikowi po co zbieramy konkretne dane i zbierać tylko te dane, które są potrzebne do działania usługi;
  • jasno oznaczamy, które dane są obowiązkowe, a które nie;
  • oddzielamy zgody na przetwarzanie danych w celu działania usługi od tych marketingowych.

 

Jak widzimy, są to wymagania pochodzące bezpośrednio z aktu prawnego, ale mają bezpośrednie przełożenie na pracę projektantów. Dzięki znajomości i implementacji tych reguł już na etapie projektowania, rola konsultacji prawnych sprowadza się w tym zakresie raczej do potwierdzenia, czy wszystko przewidzieliśmy, niż wywraca projekt do góry nogami.

Podsumowanie

Choć brzmi to patetycznie, to wiele w życiu zależy od naszego podejścia do sprawy. W COI tworzymy usługi oparte o wymagania prawne. To od nas zależy, czy będziemy traktować je wyłącznie jako trudności w osiągnięciu idealnego rozwiązania czy zauważymy w nich dodatkową wartość. Chcemy zostawić Cię z myślą, że prawo daje nam, twórcom rozwiązań, argumenty, by tworzyć produkty i usługi jak najwyższej jakości. Bez kompromisów w postaci pominięcia dostępności, badań użyteczności czy stosowania nieetycznych praktyk.

Materiały dodatkowe

Udostępnij artykuł