Dlaczego nie ma idealnych rozwiązań IT?

Wyobraź sobie projekt marzeń. Sponsor ma jasny, sensowny cel. Budżet jest otwarty. Biznes słucha i nie zmienia zdania co tydzień. Zespół to doświadczeni, zgrani, otwarci specjaliści – analitycy, projektanci, deweloperzy, UX designerzy, testerzy. Użytkownicy są włączani w proces projektowania od samego początku. Wszyscy mówią wspólnym językiem i starają się wykonywać swoją pracę jak najlepiej.

Oczywiście, nawet w tak utopijnych warunkach stworzone rozwiązanie IT będzie nieidealne. Bo idealne rozwiązanie IT nie istnieje – podobnie jak idealna analiza, idealny warsztat czy uniwersalny przepis na to, żeby wszyscy Cię lubili. Brzmi jak banał, ale w praktyce projektowej potrafimy o tym naprawdę szybko zapomnieć.

Jeśli jesteś ciekawy, co na to wpływa i czy można coś z tym zrobić, zostań ze mną. Nie będę zatrzymywać się przy oczywistych powodach, takich jak brak kompetencji w zespole, złe zarządzanie projektem czy ewidentnie nietrafione decyzje biznesowe. Pominę też temat zależności od innych systemów, czyli problemów na styku integracji – to wątki, o których pisano już wiele razy.

W tym tekście opowiem o sytuacjach niejednoznacznych: o napięciach, paradoksach i pozornie niewidocznych mechanizmach, które są bardzo trudne do całkowitego wyeliminowania.

Ograniczone perspektywy

Mózg interpretuje nowe sytuacje przez pryzmat wcześniej zbudowanych schematów poznawczych (ang. cognitive schemas). To zjawisko, opisywane m.in. w kontekście koncepcji schematów poznawczych Jeana Piageta, jest jednym z podstawowych ograniczeń ludzkiego poznania: nie patrzymy na świat „na czysto”, tylko przez to, co już wiemy, czego doświadczyliśmy i co uznajemy za oczywiste.

Każdy zespół patrzy na problem przez zbiór własnych perspektyw. Nawet najbardziej otwarty i uważny członek zespołu jest ograniczony subiektywnym postrzeganiem rzeczywistości.

• Pracujemy w dużych miastach? Łatwo przeoczyć ograniczenia infrastruktury cyfrowej w małych miejscowościach czy na wsiach (np. białe plamy internetu).
• Zespół projektowy jest w Polsce? Łatwo pominąć złożoność etniczną i kulturową w projekcie realizowanym dla klienta w Stanach Zjednoczonych.

Z łatwością kupujemy bilet komunikacyjny w pociągu za pomocą smartfona? Prawdopodobnie nie weźmiemy pod uwagę, że dla kogoś przeszkodą może być nie sama aplikacja, ale np. strach przed przewróceniem się w komunikacji miejskiej.

By zminimalizować wpływ ograniczonych perspektyw na projektowane rozwiązanie IT, można:

• Zdefiniować kilka person – potencjalnych użytkowników. Warto poświęcić na to ćwiczenie więcej czasu i opisać personę naprawdę szczegółowo.

TIP: zrób szybki skan w głowie – czy ktoś z Twojej rodziny lub znajomych mógłby być użytkownikiem tej aplikacji? Co mogłoby być dla tej osoby trudne, nieoczywiste albo wykluczające?

• Wykorzystać na warsztatach technikę facylitacji TRIZ, żeby wspólnie zastanowić się „dla kogo nasze rozwiązanie na pewno nie zadziała” lub „jak musielibyśmy zaprojektować to rozwiązanie, żeby dla danej persony na pewno nie zadziałało”. Takie ćwiczenie pomaga nazwać założenia, które zwykle pozostają niewidoczne, i poszerza perspektywę zespołu.

Empatia poznawcza pomaga, ale nie jest wystarczająca

Nawet jeśli bardzo się staramy zobaczyć cudzą perspektywę, bardzo trudno jest nie narzucać dodatkowo własnego postrzegania. I właśnie dlatego empatia poznawcza pomaga, ale nie wystarcza.

Jest fundamentalna różnica między rozumieniem zagadnienia lub problemu intelektualnie a przeżyciem go na własnej skórze.

Projektant może rozumieć, że część użytkowników korzysta ze starszych telefonów, słabszego internetu albo ma trudność z koncentracją, a mimo to niecelowo tworzyć rozwiązania wymagające szybkiego sprzętu, stabilnego połączenia i pełnej uwagi. Nie dlatego, że ignoruje potrzeby użytkowników. Raczej dlatego, że własna codzienność nieustannie zaburza projektowanie dostosowane do rzeczywistości innych.

Niemożliwym jest przewidzieć wszystkie preferencje i ograniczenia użytkowników (np. ograniczenia kognitywne). Nawet gdyby było to możliwe, aplikacja tworzona z ambicją „dla każdego, w każdej sytuacji” bardzo szybko stałaby się projektem bez końca:

• kosztownym,
• rozciągniętym w czasie
• i pełnym sprzecznych potrzeb.

User research, wywiady, persony – to narzędzia, które bardzo pomagają, ale żadne z nich nie przenosi projektanta do innego ciała, innej historii życia ani innego kontekstu ekonomicznego. Możemy jedynie próbować zbliżać się do doświadczeń innych.

Minimalizowanie ograniczeń

By zminimalizować wpływ tego ograniczenia na projektowane rozwiązanie IT, warto:

• Zaplanować wyjście awaryjne dla przypadków, które pominęliśmy – np. podanie numeru kontaktowego dla osób, które potrzebują dodatkowego wsparcia.

Pamiętaj, że obsługa każdego przypadku nie musi być cyfrowa – czasami wystarczy dodatkowa informacja lub e-mail, na który zagubiony użytkownik może napisać.

• Testować rozwiązanie w mniej komfortowych warunkach niż własne.

Warto sprawdzić aplikację na starszym telefonie, przy słabym internecie, w pośpiechu, na zewnątrz, w hałasie albo z ograniczoną możliwością skupienia. Takie testy nie oddadzą w pełni doświadczenia użytkownika, ale pomogą wyjść poza domyślne warunki pracy zespołu.

TIP: Zrób prosty eksperyment: spróbuj wykonać kluczowy proces w aplikacji, używając niedominującej ręki lub zmień celowo rozdzielczość swojego ekranu na niską (1024×768).

Projektujemy dla wybranego modelu użytkownika

W fazie analizy i projektowania tworzymy listę założeń, scenariuszy, wersji procesów i typów użytkowników. Nawet jeśli robimy to świadomie i rzetelnie, zwykle opieramy się na pewnym modelowym scenariuszu.

Zakładamy, że użytkownik jest umiejscowiony w konkretnym kontekście biznesowym, chce osiągnąć określony cel, ma czas, rozumie proces, działa w typowych warunkach i porusza się po skończonej liczbie ścieżek.

Jeśli jednak przyjrzymy się temu uważniej, okaże się, że projektujemy rozwiązanie dla człowieka, który w praktyce prawie nie istnieje – spokojnego, skoncentrowanego, w dobrym humorze, cierpliwego i z pełną baterią telefonu czy laptopa.

Prawdziwi użytkownicy bywają zupełnie inni. Logują się do aplikacji na mrozie, jedną ręką. Wypełniają formularze po całonocnej opiece nad chorym dzieckiem. Obsługują aplikację w trakcie kryzysu finansowego lub emocjonalnego. Nie mają czasu, więc w pośpiechu klikają w formularze, próbując załatwić sprawę między jednym spotkaniem a drugim.

Nic dziwnego, że w takich warunkach coś może zadziałać w nieoczekiwany dla użytkownika sposób. Większość z nas zna to uczucie, kiedy mamy wrażenie, że „jakiś głupi system” przeszkadza, a nie pomaga.

Co zrobić?

By zmniejszyć wpływ projektowania pod zbyt idealny model użytkownika, można:

• Skonsultować rozwiązanie z osobą niezaangażowaną w projekt.

Najlepiej z kimś, kto nie zna Twoich założeń i skrótów myślowych. Taka osoba szybciej zauważy miejsca, które dla zespołu stały się „oczywiste”, choć dla użytkownika wcale takie nie będą.

• Opisywać wymagania bardziej kontekstowo.

Zamiast pisać o generycznym „użytkowniku”, warto osadzić wymaganie w konkretnym scenariuszu życiowym. To pomaga zespołowi zobaczyć nie tylko cel użytkownika, ale też warunki, w jakich będzie próbował go osiągnąć.

Na przykład zamiast neutralnego:

Jako użytkownik

chcę zgłosić urodzenie dziecka online,

żeby nie musieć robić tego osobiście w urzędzie.

można napisać:

Jako ojciec nowonarodzonego dziecka, niewyspany po pierwszych dniach opieki,

chcę zgłosić online urodzenie dziecka,

żeby nie musieć jechać osobiście do urzędu.

Taki opis łatwiej zmienia perspektywę i przekierowuje myślenie z „nijakiego usera” na prawdziwego człowieka.

Przeciążenie poznawcze i życie w cyfrowym świecie

Ludzkie mózgi nie powstały w świecie powiadomień, niekończących się feedów, kilkunastu aplikacji dziennie i ciągłego przełączania uwagi.

W psychologii ewolucyjnej opisuje się to jako evolutionary mismatch – niedopasowanie między mechanizmami, które kształtowały się w dawnych warunkach środowiskowych, a bodźcami i wymaganiami współczesnego świata. W przypadku technologii cyfrowych oznacza to, że nasze systemy poznawcze i społeczne są wystawiane na dużą ilość, tempo i intensywność bodźców.

W obszarze UX pisze się między innymi o tym, że wysoki cognitive load utrudnia znajdowanie informacji i kończenie zadań.

Użytkownicy korzystają z interfejsów bez specjalnego skupienia i dość niedbale. I nie możemy mieć do nich o to pretensji, gdyż rozwiązania IT są temu współwinne (polecam perspektywę Sary Wachter-Boettcher, która w swojej książce pisze o rozwiązaniach IT, które uznaje za toksyczne). Na przykład, social media zawierają wiele funkcji projektowanych po to, żeby użytkownik został jeszcze chwilę. A potem jeszcze chwilę. I jeszcze jedną.

Efekt? Coraz trudniej skupić się na jednym zadaniu dłużej niż na kilkanaście, kilkadziesiąt sekund.

Dlatego też długie formularze, wiele kroków, komunikaty błędów napisane technicznym językiem, brak możliwości zapisania postępu oraz to, że ten konkretny formularz działa inaczej niż 10 innych podobnych – mogą powodować stres.

Rozwiążmy to

By zmniejszyć wpływ przeciążenia poznawczego na projektowane rozwiązanie IT:

• Zacznij od zaprojektowania najprostszej ścieżki użytkownika, która pozwoli osiągnąć cel procesu (MVP).

Podczas warsztatów zastanów się, jak można to zrobić najprościej. Może skorzystać z techniki User Story Mapping, która pomaga w dzieleniu zakresu na iteracje. Jeśli uczestnicy warsztatów nie chcą z niczego zrezygnować i mówią, że wszystko jest równie ważne, sięgnij do metody priorytetyzacji 100 dolar method.

• Miej z tyłu głowy, że gdy projektujemy rozwiązanie IT, często jesteśmy podekscytowani, „zanurzeni w kontekście”, zaangażowani w realizację projektu, ale dla użytkownika to tylko kolejny system. Chce osiągnąć swój cel i iść dalej. Warto mu to ułatwić – wtedy będzie bardziej zadowolony z korzystania z naszej aplikacji.

Trudno pogodzić oczekiwania wszystkich pokoleń w jednym narzędziu

Kolejnym aspektem wartym wspomnienia jest fakt, że użytkownicy jednej aplikacji mogą należeć do różnych generacji, być w różnym wieku i posiadać różne doświadczenia cyfrowe.

Pokolenia różnią się nie tylko poziomem kompetencji cyfrowych, ale też oczekiwaniami wobec technologii, zaufaniem do niej oraz sposobem wchodzenia z nią w interakcję.

Widać to choćby w danych o kompetencjach cyfrowych: według Eurostatu w 2025 roku tylko 60% osób w wieku 16–74 lat w UE miało co najmniej podstawowe umiejętności cyfrowe, mimo że unijny cel na 2030 rok wynosi 80%. Wśród młodych osób ten poziom jest wyższy – 76% młodych kobiet i 73% młodych mężczyzn miało co najmniej podstawowe kompetencje cyfrowe.

Młodsze generacje oczekują natychmiastowego rezultatu w zakresie mobilności i intuicyjności. Starsze potrzebują przewidywalności, prostoty i marginesu na błąd.

To, co dla jednych jest „oczywistym ułatwieniem” – logowanie biometryczne, powiadomienia push, onboarding przez wideo – dla innych jest barierą lub źródłem niepokoju. Nielsen Norman Group zwraca uwagę, że użytkownicy 65+ mierzą się z konkretnymi wyzwaniami w korzystaniu ze stron i aplikacji, a wzrost kompetencji cyfrowych tej grupy nie zwalnia projektantów z obowiązku dostosowywania rozwiązań do starszych użytkowników.

Rozwój technologiczny, AI, wprowadzanie coraz bardziej zaawansowanych rozwiązań zwiększają cyfrowe wykluczenie. Życie w cyfrowym świecie nie oznacza, że wszyscy szybko się dostosują. To ważne, by przy projektowaniu rozwiązań IT nie zapominać o tym, że użytkownicy mają różnorodne priorytety w życiu – nie dla wszystkich będzie to spędzanie wieczorów na nauce tego, jak działa BLIK albo czym jest uwierzytelnianie dwuskładnikowe.

Możemy protestować i oczekiwać, że ludzie się dostosują – bo przecież tak działa dzisiejszy świat! Tylko że to nieprawda. Wystarczy się rozejrzeć, a okaże się, że anegdota „moja matka twierdzi, że nigdy nie ustawiała żadnego hasła do maila i zawsze działało” jest bardzo powszechna, a takie osoby mamy w swoim najbliższym otoczeniu.

Młodsze pokolenia urodziły się niemal z tabletami w dłoniach. To osoby dużo bardziej świadome cyfrowo niż poprzednie pokolenia, ale z innymi ograniczeniami.

Zastanawialiście się kiedyś, jak wiele osób z pokolenia Z i młodszych umie pisać na klawiaturze? Otóż, coraz mniej – przynajmniej na to wskazują obserwacje i dane przywoływane w tekstach o spadku kompetencji pisania na klawiaturze u młodszych użytkowników. Młode pokolenia korzystają znacznie częściej z urządzeń mobilnych z ekranami dotykowymi niż z tradycyjnych komputerów lub laptopów. A przecież aplikacje czy formularze na urządzenia mobilne projektuje się inaczej niż te na urządzenia z fizyczną klawiaturą.

Różnice pokoleniowe – co z nimi?

By zmniejszyć wpływ różnic pokoleniowych na projektowane rozwiązanie IT, można:

• Projektować alternatywne ścieżki dla istotnych kroków procesu.
  Nie każde „nowoczesne ułatwienie” powinno być jedyną drogą. Biometria jest wygodna – ale warto mieć alternatywę. Powiadomienie push jest szybkie – ale nie każdy je zauważy albo zrozumie. Im ważniejszy proces, tym mniej powinien zależeć od jednego urządzenia, jednego kanału albo jednej kompetencji cyfrowej.

TIP: Walidując wymagania z interesariuszami albo omawiając je z zespołem podczas refinementu, odwołuj się do przygotowanych person. Dobrym pomysłem może być dodanie do Definition of Ready punktu, który będzie przypominał o sprawdzeniu wymagań pod kątem różnych typów użytkowników. Na przykład: „Wymaganie zostało zwalidowane względem kluczowych person i ich ograniczeń cyfrowych”.

To nie oznacza, że każda funkcja musi mieć pięć wariantów dla pięciu pokoleń. Chodzi raczej o to, żeby przy ważnych procesach świadomie sprawdzić, czy nie projektujemy rozwiązania, które wykluczy kogoś, kto ma inny sposób rozumienia technologii lub zwyczaje niż członkowie zespołu projektowego.

Data bias – dane nie odzwierciedlają rzeczywistości

Można łatwo powiedzieć: dobrze, ludzie mają ograniczoną perspektywę, więc oprzyjmy się na danych. Problem w tym, że dane też nie są magicznym portalem do obiektywnej rzeczywistości.

Dane, na podstawie których podejmowane są decyzje, również nie są w pełni neutralne. Statystyki, badania użytkowników czy wyniki ankiet rzadko przedstawiają pełny obraz sytuacji. Częściej pokazują obraz tej grupy, którą udało się zbadać, zmierzyć albo której zachowania najłatwiej było zarejestrować w systemie. NIST zwraca uwagę, że bias w systemach AI wynika nie tylko z problemów technicznych, ale też z ludzkich, społecznych i instytucjonalnych uprzedzeń obecnych w danych i procesach ich tworzenia.

Dość popularnym przykładem jest narzędzie Amazona do automatycznej selekcji CV, które firma ostatecznie porzuciła. System uczył się na danych z wcześniejszych rekrutacji, a ponieważ w branży technologicznej przez lata dominowali mężczyźni, zaczął odtwarzać ten wzorzec. Według Reutersa narzędzie obniżało ocenę CV zawierających słowo „women’s” oraz kandydatur absolwentek żeńskich uczelni.

Podobny problem widać w medycynie. Przez lata kobiety były niedostatecznie reprezentowane w badaniach klinicznych. NIH zaczął formalnie zachęcać do ich włączania dopiero pod koniec lat 80. Efekt takich luk widać choćby w interpretacji chorób serca. Za „typowe” objawy zawału często uznaje się silny ból w klatce piersiowej, ale u kobiet częściej pojawiają się też mniej oczywiste symptomy: duszność, nudności, ból pleców, szczęki lub ramienia, nietypowe zmęczenie albo osłabienie.

Dane, po które sięgamy przy decyzjach projektowych, odzwierciedlają więc nie tylko rzeczywistość, ale też trendy, braki, uproszczenia i uprzedzenia ludzi, którzy te dane zbierali, opisywali albo wcześniej na ich podstawie podejmowali decyzje.

Co z tym zrobimy?

By zmniejszyć wpływ data bias na projektowane rozwiązanie IT, można:

• Sprawdzać, kogo w danych brakuje.

Zanim przyjmiesz dane za pewnik, sprawdź, kogo one opisują. Zapytaj o metryczkę badania lub respondenta. Ważną informacją jest też jakiego czasu dotyczą dane – czy ten okres był nietypowy (np. z powodu wydarze historycznych) i mógł sprawić, że dane w obecnych warunkach nie będą zupełnie wiarygodne.

• Łączyć dane ilościowe z jakościowymi.

Nie polegaj tylko na jednym źródle danych. Jeśli ze statystyk wynika jedno, a podczas warsztatów uczestnicy mówią co innego, to znaczy, że omawiane zagadnienie wymaga dodatkowej weryfikacji.

Wykorzystywanie AI w projektach znacząco pomaga, ale nie pozwala wykluczyć błędów

Na koniec dołóżmy AI – sztuczną inteligencję – narzędzie, które potrafi przyspieszyć pracę, uporządkować informacje i zautomatyzować część zadań. Ale AI nadal działa w granicach danych, na których zostało zbudowane, oraz kontekstu, który jesteśmy w stanie mu dostarczyć.

Sztuczna inteligencja uczy się przede wszystkim na utrwalonych danych, na tym, co zostało zapisane. Tymczasem duża część wiedzy potrzebnej w projektach IT ma charakter ukryty (tacit knowledge) i jest osadzona w doświadczeniu, intuicji, relacjach i kontekście.

Michael Polany opisywał to słowami:

Wiemy więcej, niż potrafimy powiedzieć.

A więc nie całą wiedzę da się łatwo zamienić w dokumentację, wymaganie albo prompt.

Jeśli nasz utopijny zespół wspomaga się narzędziami AI, prawdopodobnie szybciej napisze kod, streści dokumentację albo przygotuje pierwszą wersję wymagań. Nie znaczy to jednak, że przewidzi zachowania użytkownika w wielu możliwych kontekstach: w stresie, pośpiechu, zmęczeniu albo sytuacji, której nikt wcześniej dobrze nie opisał.

Do tego dochodzą halucynacje, czyli odpowiedzi brzmiące wiarygodnie, ale nieprawdziwe lub nieprecyzyjne. A my – ludzie – dokładamy do tego automation bias, czyli tendencję do nadmiernego polegania na automatyzacji.

AI może być świetnym wsparciem w projekcie, ale nie powinno być traktowane jak zewnętrzny, obiektywny ekspert. To raczej bardzo szybki współpracownik, który pomaga zobaczyć wzorce, ale nadal może się mylić.

Zadziałajmy

By zmniejszyć wpływ ograniczeń AI na projektowane rozwiązanie IT, można:

• Traktować odpowiedzi AI jako hipotezy, nie decyzje.

AI może podsunąć wymaganie, scenariusz albo ryzyko, ale ktoś z zespołu powinien sprawdzić, czy pasuje to do rzeczywistego kontekstu projektu i czy ma sens. AI to tylko narzędzie – odpowiedzialność za jego użycie pozostaje po stronie człowieka.

Zrozumienie to pierwszy krok do tworzenia lepszych systemów

Idealne oprogramowanie nie istnieje i należy to zaakceptować. Ale głowa do góry – to nie oznacza, że nasze rozwiązania nie mogą być lepsze.

Zrozumienie, dlaczego systemy projektowane nawet w najlepszych warunkach zawodzą, zmienia sposób projektowania. Zamiast pytać: „jak zrobić system dla wszystkich?”, zaczynamy pytać: „dla kogo ten system może nie zadziałać?”.

Nie jest to łatwe pytanie, szczególnie w analizie i zarządzaniu produktem, gdzie operujemy na wysokim poziomie abstrakcji. Mówimy o procesach, rolach, scenariuszach, wymaganiach, KPI-ach. Pod tym wszystkim są ludzie – zmęczeni, zestresowani, starsi, młodsi, wykluczeni, przebodźcowani, w kryzysie, bez zasięgu, bez zaufania albo bez cierpliwości.

Nie stworzymy idealnego systemu, ale możemy projektować bardziej świadomie: szukać luk w naszej perspektywie, sprawdzać, kogo nie widać w danych, testować rozwiązania w mniej idealnych warunkach i pytać o scenariusze, które nie mieszczą się w „happy path”.

Pomagają w tym między innymi:

• persony uwzględniające różne kompetencje cyfrowe, konteksty życiowe i ograniczenia,
• analiza kontekstu użycia – nie tylko „kto korzysta”, ale też „kiedy, gdzie i w jakim stanie emocjonalnym/fizycznym”,
• user stories pisane z perspektywy konkretnych ludzi, a nie abstrakcyjnego „usera”,
• warsztaty oparte na pytaniu: „dla kogo to rozwiązanie na pewno będzie trudne?”,
• badania z użytkownikami spoza najłatwiej dostępnej grupy,
• monitorowanie produktu po wdrożeniu: kto odpada, gdzie odpada i dlaczego,
• awaryjne ścieżki dla osób, których przypadków nie przewidzieliśmy.

Digital

Zwiększ zysk i poszerzaj grono zadowolonych klientów dzięki naszym usługom inżynierii oprogramowania, e-commerce, mobile i digital customer experience.

Oferta Digital

Podsumowanie

Powyższe narzędzia nie sprawią, że system stanie się idealny, ale im lepiej rozumiemy, skąd bierze się ta nieidealność, tym większą mamy szansę projektować uważniej, uczciwiej i mniej krzywdząco.

W moim odczuciu właśnie o taki poziom odpowiedzialności warto walczyć w projektach IT.