Inżynieria wymagań a satysfakcja klienta
Systemy informatyczne, które przechodzą wszystkie testy funkcjonalne, a mimo to zostają odrzucone przez rynek, należą do najdroższych błędów projektowych. Napięcie między mierzalnymi wymaganiami technicznymi (IREB) a subiektywnymi odczuciami użytkownika (UXQCC) nie jest błędem w procesie, tylko jego naturalną częścią. Problem zaczyna się wtedy, gdy zgodność ze specyfikacją uznaje się za ostateczny dowód jakości, ignorując sposób, w jaki system jest faktycznie odbierany i używany.
Pozorna obiektywność specyfikacji technicznej
Wymagania techniczne dążą do jednoznaczności: spełnione lub niespełnione. Standardy inżynierii wymagań, takie jak IREB, promują mierzalność, spójność i weryfikowalność. Z tej perspektywy system jest dobry, jeśli spełnia określone parametry – na przykład czas odpowiedzi serwera nie przekracza 200 ms, a dane zachowują integralność.
To podejście jest konieczne, ale niewystarczające. Pomija bowiem kontekst użycia, czyli to, w jaki sposób człowiek faktycznie wchodzi w interakcję z systemem.
Przykład (bankowość): aplikacja bankowa spełnia wszystkie wymagania bezpieczeństwa – wymusza silne hasło, SMS-owe potwierdzenia i dodatkową autoryzację operacji. W testach systemowych wszystko działa poprawnie, w praktyce użytkownicy zaczynają zapisywać hasła w notatkach albo używać tych samych schematów w wielu serwisach, bo proces logowania jest zbyt uciążliwy. Formalnie system jest więc bezpieczny, ale realne bezpieczeństwo spada, bo użytkownicy obchodzą mechanizm ochrony.
To klasyczny przykład sytuacji, w której poprawność techniczna nie przekłada się na rzeczywistą jakość.
Mierzenie doświadczenia użytkownika
Jednym z częstszych błędów w zespołach projektowych jest traktowanie użyteczności jako kwestii gustu. Współczesne podejścia UX (w tym praktyki opisane w programach takich jak UXQCC (User Experience Quality Certification Center)) pokazują, że doświadczenie użytkownika można badać i opisywać w sposób systematyczny, choć nie w pełni obiektywny.
Zamiast opierać się wyłącznie na opiniach, zespoły korzystają z metod takich jak testy użyteczności, pomiar skuteczności realizacji zadań czy kwestionariusze, np. System Usability Scale (SUS).
Wyniki tych badań pozwalają przekształcić subiektywne odczucia użytkowników w mierzalne wskaźniki. Nie oznacza to jednak pełnej obiektywizacji UX – dane ilościowe zawsze wymagają interpretacji w kontekście użytkowników, ich celów i środowiska pracy. Na przykład wynik SUS poniżej średniej wartości (ok. 68 punktów) może wskazywać na problemy z użytecznością, ale nie stanowi sam w sobie jednoznacznego „defektu krytycznego”. Jest sygnałem, który wymaga dalszej analizy jakościowej i projektowej.
Przykład (e-commerce): sklep internetowy spełnia wszystkie wymagania funkcjonalne. Koszyk działa, płatność przechodzi, integracje są poprawne. Mimo to konwersja spada. Analiza pokazuje, że użytkownicy rezygnują na etapie checkoutu, bo:
- formularz jest za długi,
- wymagane jest założenie konta,
- koszty dostawy pojawiają się dopiero na końcu.
Badania pokazują, że to właśnie problemy z UX checkoutu są jedną z głównych przyczyn porzucania koszyka. Dodatkowo ponad połowa użytkowników rezygnuje z zakupu, gdy koszty pojawiają się dopiero na końcu procesu.
System działa więc poprawnie. Użytkownicy – odchodzą.
Użytkownik powinien przeczytać instrukcję
W środowiskach o wysokim rygorze technicznym często pojawia się antywzorzec polegający na przenoszeniu odpowiedzialności za błędy na użytkownika. Stwierdzenie „użytkownik nie przeczytał instrukcji” jest w praktyce sygnałem problemu projektowego.
Podejście zorientowane na człowieka, opisane m.in. w normie ISO 9241-210, zakłada, że system powinien być dopasowany do użytkownika – jego wiedzy, doświadczeń i modeli mentalnych – a nie odwrotnie. Ignorowanie tego założenia prowadzi do sytuacji, w której system formalnie działa poprawnie, ale w praktyce generuje błędy, frustrację i spadek efektywności.
Szczególnie wyraźnie widać to w obszarze bezpieczeństwa. Wymagania takie jak częsta zmiana hasła czy wieloskładnikowe uwierzytelnianie przy każdej operacji mogą być technicznie uzasadnione, ale jednocześnie zwiększają obciążenie użytkownika. W efekcie pojawia się zjawisko „zmęczenia bezpieczeństwem”. Użytkownicy zaczynają obchodzić zabezpieczenia, co w rzeczywistości obniża poziom bezpieczeństwa systemu, mimo pełnej zgodności ze specyfikacją.
Przykład (fintech/aplikacje mobilne): w wielu systemach uwierzytelniania proces logowania jest niekonsekwentny między urządzeniami, komunikaty bezpieczeństwa nie są jasne, a użytkownik nie ma pewności, czy operacja jest bezpieczna. Badania nad systemami uwierzytelniania pokazują, że brak spójności i zrozumiałości zwiększa frustrację i ryzyko błędów użytkownika.
Integracja UX z inżynierią wymagań
Rozwiązaniem nie jest kompromis polegający na osłabieniu wymagań technicznych, lecz ich rozszerzenie o perspektywę użytkownika. Propozycje:
1. Traktowanie wymagań UX jako wymagań jakościowych (NFR). Użyteczność, łatwość nauki czy satysfakcja użytkownika powinny być definiowane i mierzone podobnie jak wydajność czy bezpieczeństwo.
2. Weryfikacja założeń na wczesnym etapie. Testy korytarzowe i prototypowanie pozwalają sprawdzić decyzje projektowe zanim zostaną utrwalone w kodzie.
3. Identyfikacja ryzyk UX. Analiza punktów, w których wymagania techniczne mogą kolidować z percepcją użytkownika, umożliwia świadome projektowanie mechanizmów łagodzących, takich jak komunikaty statusu czy progresywne ujawnianie informacji.
Podejścia UX, rozwijane m.in. w ramach UXQCC, zakładają iteracyjność i ciągłą weryfikację rozwiązań z udziałem użytkowników, a nie jednorazowe potwierdzenie zgodności ze specyfikacją.
Jakość jako doświadczenie, nie tylko zgodność
Jakość oprogramowania nie jest sumą spełnionych wymagań technicznych, ale stopniem, w jakim system pozwala użytkownikowi osiągnąć jego cele w konkretnym kontekście. Zgodność techniczna jest warunkiem koniecznym, ale niewystarczającym. Ostateczna weryfikacja jakości odbywa się na styku technologii i psychologii, czyli tam, gdzie system spotyka się z realnym użytkownikiem. Bez uwzględnienia perspektywy UX ryzyko stworzenia produktu poprawnego techniczne, lecz nieakceptowalnego przez rynek, pozostaje wysokie.
Źródła:
https://www.iso.org/standard/77520.html
https://en.wikipedia.org/wiki/System_usability_scale
https://en.wikipedia.org/wiki/Usability_of_web_authentication_systems
https://www.nngroup.com/articles/ten-usability-heuristics/
https://edtechbooks.org/encyclopedia/cognitive_load_theory
https://usability-academy.com/en/articles-all/400-iso-9241-iec-62366-many-norms-pardon
https://baymard.com/research/checkout-usability