Dôvera sa nedá prilepiť na koniec projektu

Dôvera nie je jeden banner

Najviditeľnejší príklad je privacy. Web sa postaví. Analytics sa zapojí. Marketingové skripty fungujú. A nakoniec pridáme cookie lištu.

Formálne sme možno vyriešili jednu vrstvu. Ale otázka dôvery je širšia.

Takéto rozhodnutia patria do architektúry. Nie iba do bannera.

Accessibility ovplyvňuje dizajn skôr než QA

Podobné je to s prístupnosťou. Ak ju začneme riešiť až pri hotovom dizajne, veľmi často opravujeme dôsledky: nedostatočný kontrast, zlá hierarchia, interakcie závislé iba od myši, komponenty bez stavov, nezrozumiteľné formuláre, obsah bez správnej štruktúry.

Prístupnosť podľa mňa nie je „vrstva pre špeciálnych používateľov“. Je to súčasť kvality rozhrania. A preto má vstupovať do foundation a design-system rozhodnutí oveľa skôr.

Security je tiež produktová vlastnosť

Bezpečnosť sa často vníma ako práca technického tímu po implementácii. Samozrejme, veľká časť security je technická. Ale množstvo rizika vzniká už v produktových rozhodnutiach.

Aké oprávnenia existujú? Kto môže čo vidieť? Ktoré akcie sú vratné? Ako sa rieši obnovenie účtu? Ako sa správajú administrátorské roly? Čo logujeme? Ktoré dáta vôbec ukladáme? To všetko sú zároveň produktové otázky.

Bezpečnosť nie je iba firewall okolo hotovej logiky. Je aj kvalita samotnej logiky.

Compliance nie je synonymum pre právne posúdenie

Pri compliance som opatrný ešte z iného dôvodu. Rôzne oblasti majú rôzne autority – právnik, privacy špecialista, accessibility expert, security tím, produktový vlastník. Nikto z nich by nemal predstierať, že vlastní všetko.

Dobrý systém podľa mňa nepotrebuje jedného univerzálneho „compliance človeka“. Potrebuje vedieť, ktorá otázka patrí komu a kedy má vstúpiť do projektu.

To je podstatný rozdiel.

Dôvera vzniká aj z obyčajnej prevádzkovej kvality

Trust však nie je iba regulácia. Používateľ si dôveru vytvára aj z veľmi praktických signálov. Funguje web? Nezlyhá platba? Dostanem potvrdenie? Vieme obnoviť dáta? Je jasné, čo sa stane po odoslaní formulára? Dokáže firma priznať incident? Vie ma kontaktovať, keď je problém?

Aj technická spoľahlivosť a service recovery sú súčasťou dôvery. Práve preto ma baví pozerať sa na trust širšie než cez právnu stránku vo footeri.

Audit má prísť aj pred launchom, aj po ňom

Nie všetko vieme vyriešiť návrhom. Potrebujeme kontrolu:

• security audit,
• accessibility audit,
• compliance kontrolu,
• performance,
• technickú spoľahlivosť,
• AI readiness.

Ale audit podľa mňa nemá byť iba jednorazová brána pred launchom. Systém sa mení. Pridáme nový plugin, nový formulár, nový tracking, novú funkciu. Zmení sa regulácia. Objaví sa regresia.

Preto mi dáva zmysel kombinovať kvalitné vstupné požiadavky s priebežným retestom a revalidáciou.

Trust je architektonická vlastnosť

To je asi najpresnejšia formulácia, ku ktorej som sa dopracoval. Dôvera nie je vrstva, ktorú na produkt pridáme. Vzniká zo spôsobu, akým je produkt navrhnutý, postavený, komunikovaný a prevádzkovaný.

L1Z pravdivých claimov

L2Z bezpečných oprávnení

L3Z prístupného dizajnu

L4Z primeraného zberu dát

L5Z kvalitnej prevádzky

L6Z jasnej komunikácie

L7Z toho, ako reagujeme, keď sa niečo pokazí

A preto sa podľa mňa nedá dôvera prilepiť na koniec projektu. Musí byť súčasťou rozhodnutí od začiatku.