Aplikacja dla wąskich grup odbiorców. O projektowaniu specjalistycznym.

Aplikacje specjalistyczne, domenowe to zwykle aplikacje obsługiwane przez wyspecjalizowany personel, niedostępne dla zwykłych użytkowników. Aplikacje specjalistyczne zwykle wspierają zarządzanie i rozwiązywanie problemów i pozwalają analizować duże wolumeny danych. Zazwyczaj pozwalają na interakcje pomiędzy użytkownikami oraz rolami, łączą różne niejednorodne źródła danych. Obsługa takich aplikacji ma wspierać działanie i podejmowanie decyzji, które mogą powodować daleko idące konsekwencje, między innymi: finansowe (systemy bankowe), zarządcze (systemy energetyczne), jak i zdrowotne (branża medyczna) i inne. Tym samym proces projektowy wiąże się z dużą odpowiedzialnością.

Po czym poznać, że masz do czynienia z aplikacją specjalistyczną/domenową?

Aplikacje specjalistyczne, domenowe to zwykle aplikacje obsługiwane przez wyspecjalizowany personel, niedostępne dla zwykłych użytkowników. Aplikacje specjalistyczne zwykle wspierają zarządzanie i rozwiązywanie problemów i pozwalają analizować duże wolumeny danych. Zazwyczaj pozwalają na interakcje pomiędzy użytkownikami oraz rolami, łączą różne niejednorodne źródła danych. Obsługa takich aplikacji ma wspierać działanie i podejmowanie decyzji, które mogą powodować daleko idące konsekwencje, między innymi: finansowe (systemy bankowe), zarządcze (systemy energetyczne), jak i zdrowotne (branża medyczna) i inne. Tym samym proces projektowy wiąże się z dużą odpowiedzialnością.

Na początek warto zrozumieć różnice pomiędzy rozwiązaniami masowymi a rozwiązaniami specjalistycznymi.
Podejście do rozwiązań masowych:
• koncentracją na użytkowniku,
• duży nacisk na użyteczność,
• badania oparte na zadaniach.

Podejście do rozwiązań specjalistycznych:
• koncentruje się na procesie użycia,
• kładzie nacisk na używalność,
• badanie oparte na wielopoziomowej pracy z rozwiązaniem.
Projektowanie interfejsów specjalistycznych a katastrofa nuklearna
W czasach przed masową komputeryzacją, czyli jeszcze w XX wieku, interfejsy były projektowane w formie fizycznej. Konsolety zawierające tysiące przycisków, lampek oraz przełączników. Jest to idealny przykład próby zaprojektowania interfejsu, który zawiera wszystkie elementy naraz. Co z jednej strony spełnia wymagania biznesowe, a z drugiej strony powoduje przeładowanie informacjami, prowadzące do błędów decyzyjnych.
28 marca 1979 roku w elektrowni jądrowej Three Mile Island doszło do awarii. Jest to druga największa awaria nuklearna w historii ludzkości. Analiza powodów awarii nuklearnej unaoczniła wiele problemów – w tym taki, że interfejs użytkownika w sterowni reaktora miał duże problemy z użytecznością. Jeden z kluczowych zaworów był wyposażony w światełko: przekręcenie zaworu uruchamiało światełko, można by więc sądzić, że zawór został włączony, gdy lampka pod przyciskiem zaczynała się świecić. Nic bardziej mylnego. Światło oznaczało jedynie, że zasilanie zostało włączone. Co nie było jednoznaczne z działaniem zaworu. Ten fałszywy dowód uniemożliwił identyfikowanie problemu przez kilka godzin, w konsekwencji czego doszło do awarii reaktora – 16 km wokół elektrowni zostało skażonych promieniowaniem.

„Obarczanie winą poszczególnych osób może być wygodnym sposobem postępowania w przypadku występowania błędów czy awarii. Dlaczego jednak system został zaprojektowany tak, aby pojedyncza czynność jednej osoby mogła spowodować takie konsekwencje? Co gorsza, obwinianie osoby bez naprawienia głównej przyczyny, nie rozwiązuje problemu. Ten sam błąd najprawdopodobniej ktoś powtórzy.”
Donald A. Norman,
„The Design of Everyday Things”

5 warstw złożoności rozwiązania

Im większa specjalizacja danego rozwiązania, tym większa potrzeba do UX-owego podejścia. Rozwiązania masowe, takie jak sklepy, blogi, serwisy informacyjne, są na tyle proste, przebadane i zrozumiałe, że pominięcie badań w kontekście ich projektowania nie musi stanowić automatycznie o porażce. Im bardziej złożona (a co za tym idzie – niszowa) aplikacja, tym bardziej kluczowe staje się projektowanie poprzez doświadczenia użytkowników. Brak takich badań w wielu przypadkach będzie stanowił o automatycznej porażce rynkowej danego rozwiązania.
Złożoność z definicji jest trudna do okiełznania. Celem tej części będzie rozbicie idei złożoności na bardziej szczegółowe warstwy, celem lepszego zrozumienia problemu. W rezultacie czego będziemy w stanie lepiej rozłożyć siły oraz zaplanować proces projektowy, zaczynając od rdzenia, a kończąc na najbardziej ogólnej warstwie. Warto rozpisać sobie każdą warstwę złożoności, bo poznajemy dzięki temu nasze ograniczenia. Poznanie ograniczeń to podstawa do pozyskiwania wiedzy na temat danego projektu.

5 kluczowych warstw złożoności

Integracja. Jak wygląda architektura? Jak komunikują się ze sobą bazy danych? Jakie są ograniczenia backendowe rozwiązań, które przyjdzie nam integrować?
UX to nie tylko ładne obrazki. Najlepszy UX to taki, którego nie widać. Moje doświadczenie z projektami branży finansowej, w tym dla Ministerstwa Finansów, nauczyło mnie, że takie instytucje posiadają wiele źródeł danych. Dziś problemem nie są dane, ale umiejętne ich wykorzystanie. Nieumiejętne połączenie już istniejących baz czy systemów może ograniczyć chociażby tak prozaiczną czynność, jak wypełnianie deklaracji PIT. Dane na temat podatników już były. Często niedoskonałe, innym razem rozsiane po różnych systemach. Sztuką jest zauważyć, jak połączyć za pomocą „sznurków” te różne źródła i, zamiast po raz szósty prosić użytkownika o te same informacje, pobrać je z już istniejących baz. Co prowadzi do oszczędności czasu milionów osób.
Integracja, czyli de facto uproszczony model architektury, opisuję sobie w formie diagramu. Diagram pozwala mi zrozumieć przepływy, a ponadto pozwala mi dodawać notatki do poszczególnych klocków. Spotkania z poszczególnymi osobami pozwalają mi na dodawanie i uszczegółowienie poszczególnych elementów.

Informacja. Na jakich informacjach, danych pracują użytkownicy? Z jakimi wolumenami danych mierzą się każdego dnia? Jakie informacje są kluczowe, nadmiarowe? A jakich informacji brakuje? Jakie cele mają realizować? Jak często użytkownicy sięgają po wybrane dane?
Jest to warstwa wyższa od Integracji. Pozwala nam wejrzeć już w konkretne jednostki danych, dzięki czemu jesteśmy w stanie je zrozumieć i poukładać. Gdy znamy już podstawową infrastrukturę, jest nam łatwiej zaprojektować rozwiązanie możliwe do realizacji. Nie sztuką jest stworzyć makietę z idealną formą oraz danymi, których infrastruktura nie jest w stanie dostarczyć (powodów może być wiele np. wydajność,

dostępność pod kątem bezpieczeństwa, jakość zawartych danych czy ilość potrzebnych transformacji, aby uzyskać daną informację w pożądanej formie).
Informacje zdobędziemy od użytkowników końcowych rozwiązania, podczas testów funkcjonalnych. Notujmy i zbierajmy informacje w grupy i klastry.

Intencja. W przypadku klasycznych aplikacji, np. serwisów typu e-commerce, jesteśmy w stanie z dużą dokładnością wymodelować większość kluczowych procesów, które trzeba spełnić, aby osiągnąć cel. W przypadku aplikacji specjalistycznych może się to okazać niemożliwe. Cele i zadania mogą być niestrukturyzowane, praca może być nieliniowa, zmienna, a ponadto bardzo często nie istnieje nic takiego, jak kluczowy scenariusz użycia. Przez to projektanci mogą nie w pełni rozumieć zakres przypadków użycia lub przepływów prac, które dane rozwiązanie powinny obsługiwać. W przypadku wielu dostępnych celów oraz ścieżek informacje na ich temat możemy zbierać podczas testów funkcjonalnych, wywiadów, rozmów z testerami oraz analitykami. Ponadto możemy je uzyskiwać również z danych ilościowych, jeżeli system jest monitorowany. Tutaj też musimy dokonać ich pogrupowania oraz hierarchizacji. Jest to absolutnie kluczowe w przypadku infrastruktury krytycznej. Jeżeli jakiś scenariusz (np. odpalanie ładunków nuklearnych) jest wykorzystywany przez jedną osobę (np. prezydenta, za pomocą podręcznej walizki), to mimo że w ramach organizacji (tu: Ameryka) nie zdarzyło się wykorzystanie takiego scenariusza, to jest on absolutnie krytyczny. W przypadku systemów specjalistycznych warunki, dla których jakieś wykorzystanie jednego scenariusza jest istotniejsze od drugiego scenariusza, opiera się na bazie zupełnie innych przesłanek niż w przypadku aplikacji otwartych.

Środowisko. Miejsce wykorzystania danego rozwiązania może być kluczowe w kontekście jego projektowania. Bez znajomości fizycznej otoczenia trudno jest się wczuć w sytuację. Kabina pilota, która drży, bo porusza się z prędkością naddźwiękową, radiowóz podczas nagłej interwencji czy sala operacyjna podczas 8-godzinnego zabiegu na otwartym sercu – wszystkie wymienione tutaj przypadki są absolutnie skrajne, ale niewzięcie pod uwagę środowiska podczas projektowania aplikacji może kosztować zdrowie lub życie. W moim życiu spotkałem się z ciekawym przypadkiem. Projektowana aplikacja była skierowana do personelu medycznego. Aplikacja miała być obsługiwana na sali, za pomocą panelu dotykowego. Jakie było zdziwienie, gdy okazało się, że personel medyczny obsługuje ekran w lateksowych rękawiczkach! Niestety, zamówione bez tej wiedzy ekrany dotykowe nie działały, ponieważ bariera rękawiczek blokowała dotyk. Przez to zaniedbanie trzeba było mierzyć się z kolejnym problemem, którego można było uniknąć, gdyby poznało się środowisko pracy użytkowników systemu.
Informację na temat środowiska zdobędziemy za pomocą wywiadów kontekstowych. Aby poznać szerszą perspektywę, możemy wykorzystać narzędzie w postaci badań dzienniczkowych.

Instytucja. Organizacja pracująca nad złożonym, specjalistycznym produktem może składać się z pracowników z wieloletnim stażem, ale też z osób, które nie mają wiedzy ani doświadczenia w projektowaniu nowych rozwiązań. Może to skutkować tym, że osoby, z którymi przyjdzie nam pracować, będą odwoływały się do archaicznych podejść, będą sugerowały się nieużytecznymi rozwiązaniami i będą je forsowały. Taka organizacja naturalnie będzie ograniczała wszystkie innowacyjne inicjatywy. Najgorszym możliwym rozwiązaniem jest pójście na zwarcie i forsowanie swojego podejścia. Proces UX to proces wspólny grupowy.

Krokiem podstawowym jest zrozumienie powiązań i zależności osobowych w organizacji. Uzyskamy to, rozmawiając i obserwując organizację. Kolejnym krokiem jest pozyskanie wsparcia mocno osadzonych w organizacji osób. Powinniśmy zyskiwać zaufanie w ich oczach, dzięki czemu uzyskamy większe przełożenie i szacunek organizacji. Kluczowa dla powodzenia procesu w takim miejscu jest praca organiczna. Staraj się być moderatorem warsztatów, podczas których to zespół wpada na pomysły, wypracowuje rozwiązania. Zademonstruj problemy i dane tak, by delikatnie, niedyrektywnie wskazać im kierunek prac, dzięki czemu dużo trudniej będzie im zakwestionować pomysły, które ubierzesz w makiety czy interfejsy.

Jak zmierzyć się z tym wyzwaniem?

Narzędziem wręcz stworzonym do badania użytkowników i rozwiązań specjalistycznych jest wywiad kontekstowy. W przypadku aplikacji można wykorzystać pewien miks i połączyć wywiad kontekstowy z badaniem funkcjonalnym. Wywiad kontekstowy jest bardzo elastycznym narzędziem, stworzonym do bardzo abstrakcyjnych problemów, gdzie hipotezy są mgliste lub jest ich brak.
Wywiad kontekstowy trwa około 2h i powinien być prowadzony przez jednego moderatora. Warto wyposażyć się w dyktafon oraz przygotować do nagrywania ekranu na komputerze użytkownika. Celem takiego spotkania będą: rozeznanie środowiska pracy użytkownika, zrozumienie kolejności aplikacji czy narzędzi, którymi się posługuje, zrozumienie procesów oraz problemów użytkownika. Wywiad można podzielić na 2 części: pierwszą eksploracyjną, drugą – test funkcjonalny. Czyli zaczynamy od ogółu, zmierzamy ku szczegółom. W przypadku aplikacji specjalistycznych pozyskanie 10 osób do testów może być dużym wyzwaniem, dlatego rekomendujemy zapewnienie nie mniej niż 3 użytkowników, których pracę będziemy mogli obserwować.

Pozyskany materiał w postaci notatek, nagrań audio lub wideo oraz zdjęć miejsca pracy rozsyłamy do zespołu projektowego. Taka paczka jest dobrym wstępem do warsztatu interpretacji, czyli grupowego analizowania wywiadów. Taki warsztat może polegać na wspólnym oglądaniu materiałów i spisywaniu wniosków lub przygotowaniu na warsztat wniosków, które wspólnie analizujemy. Podczas takiego spotkania możemy wykorzystać takie ćwiczenia, jak: mapa podróży użytkownika, diagram bliskości, 4C, głosowanie kropkami, how might we, mapowanie spektrum i wiele innych.

Podsumowanie

Wszystko powinniśmy zacząć od zidentyfikowania tego, czy mamy do czynienia z aplikacją specjalistyczną. Jeżeli odpowiedź jest pozytywna, wtedy potrzebujemy uwzględnić ograniczenia, które wynikają z tego typu rozwiązania. Pomocnym modelem do tego będzie 5 warstw złożoności – dzięki temu poznamy od podszewki nasz problem, zrozumiemy jego ograniczenia oraz specyfikę. Bez tej lekcji nie będziemy w stanie realnie zaproponować rozwiązania, które byłoby możliwe do akceptacji przez użytkowników, jak i możliwe do wydewelopowania przez zespół. Gdy zdobędziemy podstawy, warto zaplanować i przeprowadzić badania kontekstowe. Badania kontekstowe dadzą nam namacalne problemy, których usprawnienie pozwoli zmienić lub zaprojektować od nowa aplikację, z którą przyjdzie nam się mierzyć. Takie badania mogą być idealnym wejściem zespołu w proces tworzenia rozwiązania. A jak dalej poprowadzić taki proces? O tym dowiecie się w kolejnych artykułach.