24
cz.
2013
palikowski

User eXperience w aplikacjach korporacyjnych

Ostatnio w mojej praktyce zawodowej widzę, że coraz większą wagę przykłada się do użyteczności aplikacji. Wiele lat były one wytwarzane bez zwracania uwagi na ten element. Teraz firmy starają się jakoś wygrzebać z bezliku różnorodnych interfejsów, formatek, typów pól i sposobów na osiągnięcie tego samego.

Dlaczego do tego doszło?

Problem z często beznadziejną użytecznością oraz brakiem spójności w interfejsach aplikacji pisanych na zamówienie przez duże firmy dla dużych firm jest między innymi taki, że budżet konsumowany jest często jeszcze przed dotarciem do testów użyteczności.

[drobna złośliwość]
W tym miejscu powinien wyskoczyć skrzacik albo diabełek i zapytać Cię, drogi czytelniku, "W projektach korporacyjnych zawsze planujecie testy użyteczności na wczesnym etapie, prawda?".
[/drobna złośliwość]

Wykonawcy aplikacji "na zamówienie" muszą spełnić wiele kosztownych wymagań - integracja z wieloma systemami, szkolenia, testy akceptacyjne, poprawki z gatunku "bo nam się przypomniało że...", dokumentacja analityczna, projektowa i techniczna (wiele razy przepisywana), dedykowane instrukcje stanowiskowe i tak dalej. To wszystko kosztuje.

Co innego aplikacje pudełkowe, dla masowego odbiorcy. Tam raz zaprojektowana i napisana aplikacja sprzedaje się głównie dzięki temu, że jest funkcjonalna, użyteczna, estetyczna i przyjazna. Interfejs użytkownika (często sprawdzany przed kupnem za pomocą wersji trial) jest niemal krytyczną kwestią. Aplikacja musi nie tylko działać ale wyglądać i wyróżniać się na plus w gronie konkurencji.

Wracając do aplikacji "korporacyjnych". Przy pewnym poziomie frustracji związanym z przekroczeniem budżetu, terminów i granic zdrowego rozsądku jeśli chodzi o moment i zakres zgłaszanych poprawek i zmian, sporo projektów jest odbierana i wrzucana na produkcję na zasadzie "skończmy to wreszcie a poprawiać będziemy na podstawie feedbacku użytkowników i po godzinach w ramach osobnego projektu".

Ta, jasne. Zaczynamy kolejny projekt a na poprawienie słabego interfejsu czasu brak, bo przecież "ważne, że działa". Działa tu podobny mechanizm jak z długiem technologicznym.

W dużej korporacji pisze się kilka(naście, dziesiąt) mniejszych i większych aplikacji jednocześnie. Każda może być budowana przez inny zespół - zarówno ze strony biznesu, wewnętrznego IT jak i dostawcy z rynku. Każdy dostawca ma swoje wypracowane wzorce projektowe, preferowane biblioteki kontrolek i tak dalej. Zapanowanie nad tym naprawdę nie jest łatwe.

Teoretycznie to co zalecają specjaliści od ux to spisanie dokumentu standardów, wytycznych, zaleceń co do użyteczności. Dokument zawierający szereg szablonów, wzorców projektowych, nawet gotowych bibliotek z CSSami i kontrolkami, który przekazujemy potem wykonawcy celem ułatwienia mu życia.

Brzmi super, ale czy takie coś faktycznie pomaga, sprawdza się? Jak szczegółowo to projektować - objąć tym 80% najczęściej spotykanych widoków, raportów, tabel, kontrolek? Jak duży nakład pracy poświęcić później na uaktualnianie i jak restrykcyjnie tego pilnować?

Mam nadzieję, że za rok-dwa będę miał powyższe wątpliwości "przepracowane" i że podzielę się z Wami tym co udało mi się zaobserwować. Tymczasem pozdrawiam :)