Brak Privacy by Design w UX/UI: 5 błędów, które mogą kosztować firmę miliony

Z punktu widzenia projektanta czy dewelopera, świetna aplikacja to taka, która ma intuicyjny UX, piękny UI i działa bez zarzutu. Jednak w świecie prawa wiemy, że to nie wystarczy. Jeśli na etapie makietowania zapomnisz o ochronie danych osobowych, Twój produkt może okazać się tykającą bombą prawną.

Dziś bierzemy na warsztat dwa pojęcia: Privacy by Design (prywatność w fazie projektowania) oraz Privacy by Default (prywatność domyślna). Co dokładnie oznacza ich brak w projekcie i dlaczego może Cię to słono kosztować?

Co to jest "Privacy by Design"?

Privacy by Design to zasada, która mówi: ochrona danych musi być wpisana w DNA Twojego projektu od samego początku. Brak Privacy by Design ma miejsce wtedy, gdy zespół najpierw buduje funkcjonalność (np. wielki system CRM lub aplikację randkową), a dopiero przed samym wdrożeniem pyta prawnika: "Ej, a co my właściwie mamy zrobić z tym całym RODO?".

Jak to wygląda w praktyce (błędy projektowe):

• Zbieranie danych "na zapas": Tworzysz prostą aplikację z latarką, która żąda dostępu do kontaktów, lokalizacji i mikrofonu użytkownika.

• Brak bezpiecznej architektury: Hasła użytkowników trzymane w bazie czystym tekstem (bez szyfrowania), bo na etapie projektowania bazy danych nikt nie pomyślał o bezpieczeństwie.

• Ciasne ramy czasowe: Kwestie bezpieczeństwa są pomijane w sprintach, bo priorytetem jest "dowiezienie" nowych funkcji (tzw. dług technologiczny i prawny).

Co to jest "Privacy by Default"?

Zasada Privacy by Default oznacza, że w momencie, gdy użytkownik zaczyna korzystać z Twojego produktu, jego ustawienia prywatności powinny być domyślnie ustawione na najbardziej restrykcyjny, chroniący go poziom.

Brak Privacy by Default to przerzucenie całego ciężaru dbania o prywatność na użytkownika. Twórca wychodzi z założenia: "Zbieramy wszystko co się da, chyba że użytkownik sam to wyłączy".

Jak to wygląda w praktyce (błędy UX/UI):

• Wstępnie zaznaczone zgody (Pre-ticked boxes): Zgoda na marketing czy udostępnianie danych partnerom jest domyślnie zaznaczona podczas rejestracji.

• Otwarte profile: Konto w nowej aplikacji społecznościowej zaraz po założeniu jest w 100% publiczne, a lokalizacja użytkownika widoczna dla każdego. Aby to zmienić, użytkownik musi przeklikać się przez pięć poziomów skomplikowanego menu.

• Dark patterns: Projektowanie interfejsu tak, aby opcja "Zgadzam się na wszystko" była wielkim, zielonym przyciskiem, a opcja "Zarządzaj prywatnością" małym, szarym i ledwo widocznym linkiem na dole strony.

Aspekty prawne: Co na to RODO?

Dobre praktyki to jedno, ale twarde prawo to drugie. Zasady Privacy by Design i Privacy to twardy obowiązek prawny wynikający wprost z art. 25 RODO.

Zgodnie z prawem, to na Administratorze Danych Osobowych (czyli najczęściej na właścicielu serwisu) ciąży obowiązek wdrożenia odpowiednich środków technicznych i organizacyjnych, by chronić dane użytkowników. Urzędy nadzorcze (w Polsce to Prezes UODO) podczas kontroli sprawdzają nie tylko to, czy masz napisaną "Politykę Prywatności", ale jak realnie działa Twój system.

Kary za ignorowanie art. 25 RODO

Brak uwzględnienia prywatności w projektowaniu to jedno z najpoważniejszych naruszeń. Kary finansowe przewidziane przez RODO mogą w tym przypadku wynieść nawet:

• do 10 000 000 EUR,

• lub do 2% całkowitego rocznego światowego obrotu przedsiębiorstwa z poprzedniego roku obrotowego.

Co więcej, błędy architektoniczne bardzo często prowadzą do wycieków danych, co wiąże się z gigantycznym spadkiem zaufania klientów i kryzysem wizerunkowym.

Jak projektować zgodnie z prawem? Check-lista dla twórców

Jak zatem uniknąć "braku" tych zasad i projektować w duchu Privacy by Design & Default? Oto kilka szybkich rad na start:

1. Zasada minimalizacji: Projektując formularze (UX), pytaj tylko o te dane, które są niezbędne do wykonania usługi.

2. Model opt-in, nie opt-out: Nigdy nie zaznaczaj checkboxów ze zgodami za użytkownika. Zgoda musi być świadomym działaniem.

3. Mapowanie danych przed kodowaniem: Zanim napiszesz pierwszą linijkę kodu, zastanów się: kto będzie miał dostęp do tych danych? Gdzie będą przechowywane? Kiedy zostaną usunięte?

4. Przejrzysty interfejs: Ustawienia prywatności muszą być łatwo dostępne (maksymalnie dwa kliknięcia od profilu), a język komunikatów prosty i zrozumiały, bez prawniczego żargonu.

Podsumowanie

Jeśli masz zapamiętać z tego tekstu tylko jedną myśl, niech będzie to fakt, że bezpieczeństwo danych zaczyna się w Figmie, a nie w dokumencie od prawnika. Domyślna ochrona prywatności to najprostsza droga do uniknięcia kryzysu wizerunkowego i zbudowania aplikacji, z której sami chcielibyśmy bezpiecznie korzystać.