Effective recruitment
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Mam kolejny projekt i dyskusje na temat jak wyżej. Coraz częściej skłaniam się ku tezie, że "formularze" i ich wygląd to jednak wymagania (nie mówię o stronach WWW tylko o systemach biznesowych).

Przekonałem się nie raz, że tak na prawdę dane są wprowadzane poprzez przepisywanie z formularzy papierowych (dokumenty przychodzące) lub wprowadzane do formularzy ekranowych od razu (dokumenty nowotworzne) a te w większości i tak lądują na papierze po ich wydrukowanie by wysłać (także PDF i wysyłka na email)

W efekcie niemalże 100% "mock-upów" to wzory dokumentów biznesowych. Tak więc w zasadzie wzory te powinien dostarczyć zamawiający.

Tu ciekawy artykuł opisujące różne "konwencję", mnie osobiście w związku z powyższym najbardziej "pasuje" konwencja Master/Detail:

Ukryty link (zaloguj się, żeby zobaczyć)

jakie są Wasze doświadczenia z etapu analizy wymagań?
Tomasz Tomaszewski

Tomasz Tomaszewski flight controller,
RS

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

IMHO wygląd formularzy, jak i całego systemu powinien być projektowany z uwzględnieniem zasad użyteczności. W systemach biznesowych nie trzeba tego robić tak gruntowanie jak w produktach skierowanych na rynek konsumencki, ale mimo wszystko. Podczas mojej krótkiej jeszcze kariery spotykałem się z mnóstwem systemów, których użytkownicy... nie potrafili go obsługiwać. W żaden sposób nie były one intuicyjne i wymagały przeprowadzenia długich szkoleń.

Tak więc przyjmować wzory dokumentów i formularzy - jak najbardziej. Warto jednak wspólnie się nad nimi pochylić razem z użytkownikami, którzy będą ich używać.

Podobnie w przypadku "konwencji" - o tym którą zastosować powinna decydować analiza i najlepiej krótkie badania z (...) Zobacz więcej
Tomasz Miodek

Tomasz Miodek biznes
analityk/analityk IT

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Wymaganiem biznesowym jest na pewno zestaw pól formularza (danych, które w ramach formularza muszą zostać zebrane). I to jest zestaw danych, które dostajemy "bezpośrednio" od biznesu. Reszta (układ, osłownikowanie, zależności) stanowi przedmiot analizy, ale nie spodziewajmy się, że biznes powie nam wprost co tam ma być. Musimy to omówić z biznesem bazując na:
- pytaniach zadawanych biznesowi (my musimy wiedzieć JAKIE zadać pytania)
- zasadach projektowania ergonomicznego interfejsu użytkownika
- własnym doświadczeniu
- logicznym myśleniu
Ostatecznie to wszystko musi zostać zaakceptowane przez zamawiającego (i w tym sensie stanowi część wymagań), ale zamawiający sam z siebie rzeczywiście powieli formularz papierowy. Dopiero my możemy pokazać wartość dodaną, jaka może wynikać z formy elektronicznej, wpływając tym samym na wymagania.
Często oznacza to prototypowanie na etapie (...) Zobacz więcej
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

zamawiający sam z siebie rzeczywiście powieli formularz papierowy. Dopiero my możemy pokazać wartość dodaną, jaka może wynikać z formy elektronicznej, wpływając tym samym na wymagania.
Często oznacza to prototypowanie na etapie analizy. Niestety.

i tu nabrałem ostatnio pokory, stąd ten wątek: formularz powielony z papierowego ma ogromną zaletę: użytkownicy go znają (projekt z urzędu, dziesiątki instalacji w kraju), jego używanie opisuje ustawa (jest manual), skoro tak, nie trzeba nikogo niczego nowego uczyć, gdybym im zafundował ekrany inne niż znane im formularze musli by wydąć masę kasy na szkolenia...

Jaką wartość dodaną (w porównaniu z powyższym) niesie zmiana ekranów na inne niż (...) Zobacz więcej
Mikołaj W.

Mikołaj W. Pomagam rozwiązywać
problemy- nie tylko
IT

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Jak dla mnie wartością dodaną jest zwiększenie interakcji i wyłapywania błędów dla użytkownika. Zwiększona spójność danych. Zmniejszenie czasu na wprowadzanie danych.

Na przykład wpisanie numeru NIP na formularzu powoduje uzupełnienie danych lub prośbę o wypełnienie kartoteki kontrahenta. Przykład może niezbyt odkrywczy, ale podający idee.

Tutaj widzę natomiast zupełnie inne zagrożenie - mianowicie nieuważną analizę. Chodzi mi o taką sytuację gdy analiza pokrywa 99% przypadków, natomiast w 1% nie ma zastosowania - bo zarówno analityk jak i klient nie wpadli że mogą się zdarzyć takie przypadki.

W przypadku systemów o dużym obciążeniu taki błąd może negatywnie działać na funkcjonowanie firmy. Stąd generalne założenie że nowe wersje powinny być proste, ale z możliwością "obejścia" przez obsługę (w zakresie uzgodnionym z klientem).

Z trzeciej strony - jeżeli mówimy o systemie na którym pracują setki ludzi, a zmiana powoduje konieczność szkoleń - tutaj bym się zastanowił nad konsultacją projektantów UX.
(...) Zobacz więcej
Katarzyna Korcewicz

Katarzyna Korcewicz Business Systems
Analyst, SII

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

A dla mnie nie istnieją formularze: traktuję ten temin jak słowo użytkowe, ale sama myślę o DIALOGU. W wymaganiau nigdy (prawie) nie napiszę, że system wyświetla formularz - system prezentuje określony dialog (okno dialogowe / zestaw okien dialogowych / interfejs dialogowy). Dany dialog ma określone i wskazane cechy! (np. jest podzielony na sekcje (logicznie odpowiadające jakiemuś ciągowi operacji bądź transakcji loglicznej), czy np spełnia różnego rodzaju wymogi - np. bezpieczeństwa (np. '..ukrywa wpisywany tekst'). Na koniec ktoś (GUI-owiec, projektant czy developer) zrobi z tego formular, bądź inne wcielenie UI. To nie ważne jakie - póki owo coś spełnia podane wymagania. (zatenm , zamiast np. 'checkbox' czy 'radiobutton' - wolę podać :'jednowybór' / 'wielowybór'. GUI-guy wie co z tym zrobić, a ja nie ograniczam go do konkretnych kontrolek i innych elementów.

Z czasem coraz lepiej się kształtują systemy, gdzie praca nad dialogiem została widocznie odrobiona (np. dialogi na urządzenia mobilne, czy np innowacyjne podejścia do jakiegoś zestawu operacji człowiek-okno (wczoraj istniało tylko wpisywanie tekstu, dziś użytkownić chce pacnąć w ekran i dostać wynik).
Dialog odzwierciedlający dokument biznbesowy często nie jest tu wszsytkim: jeśli np. w formularzu jest: "podać miejscowość", to może się to wiązać z eksploracją map, wyborem obszarów w-zależnosi-od, podpowiadaniem docelowego wyboru, etc etc - by gdzieś na samym końcu user w jakimś polu wpisał 'Lądek zdrój'. Formularz jako taki i 'sam z siebie' w wielu przypadkach nie będzie zaspokajał funkcjonalności. Gro czynności zostanie wrzucone na operatora (tzn pozostawione na userze: ten wykona coś 'na boku' i poda do formularza rozwązanie - w którym system nie był łaskaw mu pomóc (choć doskonale umiałby).
A wygląd formularzy (okien UI (nie tych do druku)) - zależy co nazywać wyglądem: bo kolejność i organizacja elementów - to nie jest wygląd.

I co najważniejsze: Użytkownik końcowy jest często przyzywczajony do starych systemów, kompletnie anty-optymalnych, i powiela (niezamierzenie, acz z wielkim przekonaniem ) nieszczególne koncepcje z tych systemów, prznosząc je na nowy system, jak wirus. Gdy starzy userzy projektują nowe jego wcielenie, to jest praktycznie pewnik że tak będzie. (brak systemu także bywa złą sytuacją - gdyż user działał nieoptymalnie (np. właśnie robił operacje na boku, by je podać do formularza), zamiast pracować interaktywnie.

@ Tomasz^2: "systemów, których użytkownicy... nie potrafili go obsługiwać" - w rzeczy samej. A nawet - system, który zanim powstał już wymagał instrukcji obsługi dla endusera (nawet żeby miał go testować - gdzie ma kliknąć jeśli coś, a gdzie jeśli coś. Jeśli to nie wynika z dialogu - no to niezrobiliśmy żadnego systemu, tylko zdigitalizowaliśmy formularze).

Mockupy ekranowe są OK tak długo, jeśli się ich nie bierze zbyt dosłownie (nie jako projekt). W przeciwnym razie każda przypadkowość wkleja się w nasz system, jak śnieg do kuli śniegowej. I nie wiemy kiedy 'nagle' mamy bałwana ;)).
Jednym z rozwiązań na to (rzekłabym że w praktyce najlepszym) jest refaktoring UI (wtedy można robić system z takim UI jakwyszedł z pierwszej 'malowanki') - ale sami przynajcie, czy się w praktyce projektu robi jakikowiek refaktoring.. .

Owszem są sytuacje, gdy faktycznie ten formularz jest dokładnie tym co należy, ni mniej ni więcej. Jednak mnóstwo przypadków takich nie jest (nawet system transakcyjny ebanku: można wypełniać dokładnie formularz przelewu bankowego z poczty, a można przyjmować dane od endusera w inaczej zorganizowanej koncepcji (wg różnych wytycznych specyficznych danego przypadku).
Czasami wystarczy jedynie np. 'poszatkowanie' formularza (jakieś zakładki, odnośniki, etc) - takie proste zabiegi mogą wnieść naprawdę wieeele (choć niektóre uproszczenia/ulepszenia mimo że drobne - nie są takie oczywiste na dzień dobry: mogą robić w efekcie wrażenie banalnych, będąc wynikiem analizy/badań/obeserwacji/obliczeń). Wystarczy spojrzeć ile osób pracuje przy dużych portalach społecznościowych - jakie zabiegi są wymyślane (nie wszystkich zastosowanie jest oczywiste na oko).

Pozdrawiam, dialogowo.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Hm... pytam różnych "nie IT" ludzi o to jak im się z czymś tam pracuje i spotykam się z opiniami:
- system "ebankowy" w którym przelew to jeden formularz ekranowy (niekoniecznie identyczny z papierowym) jest postrzegany jako wygodniejszy od serii ekranów lub zakładkami (klikanie jest irytujace)
- wystawienie faktury w postaci wypełnienia ekrany "wyglądającego jak faktura" jest bardziej intuicyjne

ale:
- wypełnienie rezerwacji na samolot, pociąg lub hotel w postaci krótkiej serii kontekstowych pytań kończących się wyświetleniem "druku rezerwacji" jest łatwiejsze niż potencjalnie mało zrozumialy "druczek rezerwacji"

Wydaje mi się, że to zależy od posiadanej wiedzy wiedzy użytkownika (kim jest aktor?), księgowa będzie się lepiej czuła mając przed oczami "druk faktury
czy "dokumentu WZ. Ale laik zamawiający towar na stronie sklepu zapewne lepiej sie poczuje poprowadzony za rękę pytanie po pytaniu.

Coraz częściej zaczynam podczas analizy dokładnie specyfikować doświadczenie i wiedzę aktora i to nich dostosowywać wymagania, np. duża firma handlowa i jej sklep internetowy:
- aktor: magazynier - ekrany zbliżane do postaci dokumentów wprowadzanych i drukowanych
- aktor : klient - ekrany "scenariuszowe" (prawie jak drzewo decyzyjne) prowadzące za rękę, "druczek" zamówienia i potwierdzenia jest generowany na końcu (papier/pdf) automatycznie z danych "wyklikanych" podczas scenariusza zakupu...

wydaje mi sie, że to aktor (kim on jest) decyduje o tym "co mu rzucić (...) Zobacz więcej
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Jak dla mnie wartością dodaną jest zwiększenie interakcji i wyłapywania błędów dla użytkownika. Zwiększona spójność danych. Zmniejszenie czasu na wprowadzanie danych.

użytkownik nie widzi "spójności danych"... błedy to "validacja", nie wiem czym jest "zwiększenie interakcji"
Na przykład wpisanie numeru NIP na formularzu powoduje uzupełnienie danych lub prośbę o wypełnienie kartoteki kontrahenta. Przykład może niezbyt odkrywczy, ale podający idee.

to fakt, ale ale to nie wynika z kształtu/postaci formularza
Tutaj widzę natomiast zupełnie inne zagrożenie - mianowicie nieuważną analizę. Chodzi mi o taką sytuację gdy analiza pokrywa 99% przypadków, natomiast w 1% nie ma zastosowania - bo zarówno analityk jak i klient nie wpadli że mogą się zdarzyć takie przypadki.

jak rozumiem, analiza na bazie deklaracji użytkownika, ok, ale jak się opisze proces biznesowy cały to nic nie umyka, nie ma czegoś takiego jak "użytkownik na to nie wpadł"..

Z trzeciej strony - jeżeli mówimy o systemie na którym pracują setki ludzi, a zmiana powoduje konieczność szkoleń - tutaj bym się zastanowił nad konsultacją projektantów UX.

wyobraź sobie, że masz przed sobą setki urzędników przeszkolonych już z nowych przepisów, którzy dokładnie wiedzą co i jak należy robić z konkretnymi formularzami, najprościej jest dać im dokładnie takie formularze jakie znają (nie dyskutujemy tu o ułatwieniach w ich wypełnianiu. Po drugie :) to co wydaje się ułatwieniem z perspektywy programisty nie musi nim być z (...) Zobacz więcej

konto usunięte

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Jarek Żeliński:
wydaje mi sie, że to aktor (kim on jest) decyduje o tym "co mu rzucić na ekran"...

Problem pojawia się jednak wtedy gdy aktor robi projekt dla innych. Wszystko zależy od struktury organizacji, a czasami poziomu decyzyjności. Przy ekranach definiujących dobrze znane procesy i często opisywane, doświadczenie jest w stanie wspomóc proces wytwórczy i zrobić to w miarę dobrze. W przypadku projektów nietypowych, przy których wykonawca i analityk nigdy nie pracowali znalezienie odpowiedniego aktora to już niezłe wyzwanie.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Problem pojawia się jednak wtedy gdy aktor robi projekt dla innych.

do tego staram się niedopuszczać :),

Wszystko zależy od struktury organizacji, a czasami poziomu decyzyjności.

staram się "projektować" aktorów czyli kojarzyć ich z kompetencjami a potem rolami w firmie (struktura organizacyjna)
Przy ekranach definiujących dobrze znane procesy i często opisywane, doświadczenie jest w stanie wspomóc proces wytwórczy i zrobić to w miarę dobrze. W przypadku projektów nietypowych, przy których wykonawca i analityk nigdy nie pracowali znalezienie odpowiedniego aktora to już niezłe wyzwanie.

rzetelny model (mapa) procesu biznesowego, wykonana jako pierwszy etap analizy się tu (...) Zobacz więcej
Michał Pawłowski

Michał Pawłowski IT Business/System
Analyst - Consultant

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Jarek Żeliński:
jakie są Wasze doświadczenia z etapu analizy wymagań?

Zależy raczej od projektu. W jednym wystarczy wyspecyfikować dane, które w ramach formularza muszą zostać zebrane, a resztą zajmuje się deweloper, w innym należy precyzyjnie określić położenie konkretnego pola bo np. za taką zmianę płaci klient i tego dokładnie oczekuje i nie ma tu pola na twórczość deweloperską (spotykane jest to raczej w przypadku rozbudowy istniejących systemów, a nie tworzeniu nowych)
Tomasz Miodek

Tomasz Miodek biznes
analityk/analityk IT

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Napiszę rzecz oczywistą - to jaką ostatecznie formę przyjmie formularz zależy zawsze od projektu.

Co może dać zmiana formularza? Weźmy wprowadzanie adresu. Załóżmy, że na formularzu wymagany jest pełny adres. Formularz papierowy ma "standardowy" układ

ulica - numer domu - numer mieszkania
Kod - miasto
Województwo

Załóżmy, że mamy słownik adresów. Zostawiając układ formularza wymuszamy wpisywanie wszystkich danych "z palca" doprowadzając najczęściej do niskiej jakości danych oraz wolnego wprowadzania.

Rozważmy teraz następujące możliwości:

1. Zmieniamy kolejność formularza. Dajemy najpierw województwo (wybieramy z listy), następnie miejscowość (z podpowiedziami z ograniczonej listy dzięki wybranemu wcześniej województwu), później ulica (tak jak poprzednio), wreszcie numery domu (z walidacją według słownika) i mieszkania. Po wprowadzeniu numeru domu automatycznie wypełnia się numer kodu.
Zalety - bazujemy na danych osłownikowanych, dzięki czemu użytkownik wprowadza fragment danych,a potem de facto wybiera z listy. Uzyskujemy wyższą jakość danych oraz krótsze wprowadzanie. Dodatkowo nie musimy wprowadzać kodu - ta informacja uzupełniana jest automatycznie.
Wady - nadal wypełnić musimy wszystkie pola i istnieje ryzyko, że przy początkowym wprowadzaniu się pomylimy, przez co nie będziemy w stanie przypisać właściwych danych ze słownika.
2. Zmieniamy kolejność formularza. Dajemy najpierw kod pocztowy. Po jego wypełnieniu automatycznie wypełnione zostają województwo i (o ile to możliwe) miejscowość. Jeśli miejscowość nie zostanie wypełniona, to wybieramy ją z listy. Podobnie z listy wybieramy ulicę (lista ta będzie ograniczona do niewielu pozycji, możliwość szybkiego przejścia przez wybranie pierwszych kilku liter), na koniec podajemy numer domu (walidacja według słownika) i numer mieszkania.
Zalety - bazujemy na danych osłownikowanych, a do tego po wprowadzeniu jednej informacji (kod) uzyskujemy automatyczne wypełnienie wielu pól. W ten sposób wypełnienie jest o wiele szybsze, a dodatkowo mamy wysoką jakość danych.
Wady - musimy znać kod. Często jednak bazujemy na dokumentach, na których ten kod jest podany.

W obu opisanych scenariuszach wątpię, żeby dla użytkownika był dużym problemem zmieniony formularz. A korzyści uzyskujemy spore.

Podobnie możemy podejść do innych formularzy. Owszem, czasem trzeba zainwestować w szkolenia. Ale czy ta inwestycja nie zwróci się, bo na przykład czas wypełniania będzie krótszy? A może zamiast szkoleń możemy zrobić formularz z odpowiednimi podpowiedziami, tak, żeby rzeczywiście był on intuicyjny.

Nie mówię, że da się tak zrobić z każdym formularzem. Nie twierdzę też, że zawsze jest to faktyczna korzyść. Co zrobimy z takim formularzem zależeć powinno właśnie od analizy. Jeśli użytkownik nie będzie przekonany do rozwiązania, to nie będzie z niego zadowolony. Oczywiście odbije się to negatywnie na odbiorze oprogramowania.

Podsumowując - nie ma jednego rozwiązania. Podtrzymuję to, co napisałem na początku - projekt formularza, jego interakcja z użytkownikiem jest pochodną analizy, z uwzględnieniem ergonomii, ale ostateczna decyzja pozostaje po stronie użytkowników. W tym sensie jest to wymaganie biznesowe. Tym niemniej jako analitycy mamy możliwość i powinniśmy wpływać na kształt (...) Zobacz więcej
Tomasz Tomaszewski

Tomasz Tomaszewski flight controller,
RS

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Katarzyna Korcewicz:
Mockupy ekranowe są OK tak długo, jeśli się ich nie bierze zbyt dosłownie (nie jako projekt). W przeciwnym razie każda przypadkowość wkleja się w nasz system, jak śnieg do kuli śniegowej. I nie wiemy kiedy 'nagle' mamy bałwana ;)).
Jednym z rozwiązań na to (rzekłabym że w praktyce najlepszym) jest refaktoring UI (wtedy można robić system z takim UI jakwyszedł z pierwszej 'malowanki') - ale sami przynajcie, czy się w praktyce projektu robi jakikowiek refaktoring.. .

Katarzyno, mogłabyś trochę rozwinąć wątek? Co rozumiesz przez niebranie mockupów zbyt dosłownie? Dla specjalistów od użyteczność jest to tak samo podstawowe narzędzie, jak dla analityków UML. Ciekawi mnie Twoje spojrzenie na sprawę.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Tomasz Miodek:
Napiszę rzecz oczywistą - to jaką ostatecznie formę przyjmie formularz zależy zawsze od projektu.

Oczywiście, nie napisałem, że "nie tykamy kolejności pól", weźmy np. taki PIT-5L, dane podawane w nim są taki sposób, że następne pola wyliczane korzystają z wartości już wprowadzonych, więc nie ma tu żadnej kolizji z tym co napisałeś. Niska jakość danych? Jakim cudem, klepnięcie OK, wysyła formularza do modelu dziedziny, tam walidacja i zwracane są wszelkie błędy.

Jednak "ekran", który odwzorowuje PIT-5L jest znany i nikogo nie tzreba w urzędzie (biurze księgowym) niczego uczyć.
Podobnie możemy podejść do innych formularzy. Owszem, czasem trzeba zainwestować w szkolenia. Ale czy ta inwestycja nie zwróci się, bo na przykład czas wypełniania będzie krótszy?

Np. 400 urzędów, razy 10 osób w sekretariacie razy trzy dni szkolenia w tym ćwiczenia po 1000zł (bardzo tanie szkolenie) = 400x10x1000= 4.000.000zł Kiedy to się zwróci?????????????

Podsumowując - nie ma jednego rozwiązania. Podtrzymuję to, co napisałem na początku - projekt formularza, jego interakcja z użytkownikiem jest pochodną analizy, z uwzględnieniem ergonomii, ale ostateczna decyzja pozostaje po stronie użytkowników. W tym sensie jest to wymaganie biznesowe. Tym niemniej jako analitycy mamy możliwość i powinniśmy wpływać na kształt tych wymagań.

ale nie wymuszać... i warto nie raz zrozumieć i uznać racje Klienta bo nie raz ma rację..
Hubert Drabczyk

Hubert Drabczyk Analityk Biznesowy
(IT), Polkomtel Sp.
z o.o.

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

W mojej wypowiedzi wrócę do głównego pytania: czy interfejs użytkownika to wymaganie czy projekt? Z mojej praktyki wynika, że to zależy głównie od dwóch czynników.

Pierwszym jest wspomniane już w dyskusji doświadczenie użytkownika - im więcej miał praktyki z wykonywaniem danej czynności "na papierze", albo podobnych czynności w systemach informatycznych, tym bardziej należy podchodzić do jego wizji systemu jak do wymagania.

Drugim czynnikiem jest to, czy wprowadzamy nową aplikację czy rozwijamy istniejącą.
Dla nowych aplikacji rozsądne wydaje się podanie w wymaganiach jakie informacje mają znaleźć się na formularzach, jakie funkcje pod przyciskami/w menu oraz czy informacje maja być pokazywane np. w postaci wykresu albo tabeli. Szczegóły pozostają do opracowania w ramach projektu.
Zmiany w istniejących aplikacjach powinny być dopasowane do jej charakteru, tzn. jeśli dla przykładu standardowym mechanizmem w aplikacji są wieloekranowe kreatory, to nowe funkcje powinny być zaimplementowane w podobny sposób. Rozwijana aplikacja zwykle ma użytkowników, którzy mogą dokładnie wskazać gdzie i jak powinny być (...) Zobacz więcej
Katarzyna Korcewicz

Katarzyna Korcewicz Business Systems
Analyst, SII

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Tomasz Tomaszewski:
Co rozumiesz przez niebranie mockupów zbyt dosłownie? Dla specjalistów od użyteczność jest to tak samo podstawowe narzędzie, jak dla analityków UML.

do bliższego wyjasnienia, przydałoby się określić, o jakim 'wcielieniu' mockupów mowa:
Jeśli robił je analityk (jako część specyfikacji wymagań behavioralnych) - przypuszczalnie (ale tylko przypuszczalnie; )) należy serio traktować ich logikę, a mnej serio ich detaliczny wygląd. Należy takieog mcka przepuscić przez speca od GUI (który nada temu ergonomię (bo wie 'którą rekż zatwierdza się fakturę'), może zaproponuje połączenie/rodzielenie elementów dialogu (np link z logiem 2in1)), etc.
Jeśli jednak mockup zrobił człowiek od algorytmów (tzn na podstawie opisu zachowania i np formularza) przez naniesienie elementów na ekran - no to możliwe, że nie uzyskał optimum, prawda?

Różni specjaliści różne role w teamach pełnią.

Jak widać, nie mamy tu wątpliwści, że kwestia UI nie jest rozłączna z logiką systemu. Nie tylko jednak w zakresie bezpośredniej interakcji (kliknij - wpisz - wybierz - zapisz), ale również np. w organizacji pomiędzy odrębnymi funkcjonalnościami w systemie (jeśli wydzielę dane teleadresowe w formularzu podróżnym, to dokładnie ten fragment formularza/dialogu można użyć w miejscu zmiany danych osoby. (i nawet jeśli korzysta z tego inny user - to są inne powody: np mam jeden kod a nie kilka oraz spójność zmian). Całkiem dobre mockupy można czasem zmienić na lepsze, jeśli tylko ma się pomysł na takowa 'lepszość'. Niektórego rodzaju zmiany 'formularzy' nieststy wymagą zmian w systemie, jeśli robić później. Robienie co/jak przekazał user jest obarczone takim kosztem, bo user nie patrzy na cały system, a my powinniśmy.
Tomasz Tomaszewski

Tomasz Tomaszewski flight controller,
RS

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Katarzyna Korcewicz:

[...]

Czyli mamy jednak podobne punkty widzenia ;)

Do dyskusji dodam tylko jak to u nas w skrócie wygląda:
- Wstępne makiety do projektu robię ja, jako analityk. Nie mają one odzwierciedlać wyglądu systemu, tylko bardziej być jedną z reprezentacji przypadków użycia. Często pomaga to klientowi wyobrazić sobie całą koncepcję systemu (tak jak i osobie tworzącej docelowe makiety). Dużo pracujemy nad "dialogami", jak to Katarzyna napisała - jaki dialog pomiędzy system i użytkownikiem powinien następować.
- Następnie, a tak naprawdę w trakcie tych działań, do pracy przystępuje osoba odpowiedzialna za UX. Na podstawie wstępnych makiet i we współpracy ze mną, klientem i przede wszystkim użytkownikami (aktorami) tworzy już docelowe makiety systemu.

Oczywiście wszystko zależy też od projektu. Jeśli jest to system w którym, tak jak Jarek przedstawia, wypełniamy PIT-5L to tutaj nie ma za dużo co "filozofować". Nie ma sensu czegoś wymuszać - "bo moim fachowym zdaniem, tak będzie lepiej". Nie. W takiej sytuacji nawet dobry specjalista UX powinien takiego analityka (jak i często klienta) powstrzymać. My możemy tylko sugerować stronie klienckiej pewne rozwiązania i przebadać ich skuteczność. Jeśli przeniesienie zwykłego papierowego formularza jest dla użytkownik najlepsze i najłatwiejsze, to po na siłę coś komplikować.

Osobną kwestią jest sprawa innowacji ;) Jeśli zawsze tylko będziemy słuchać użytkowników to o innowację będzie ciężko. Ale to już temat na osobną dyskusję...Tomasz Tomaszewski edytował(a) ten post dnia 03.11.12 o godzinie 15:24
Tomasz Miodek

Tomasz Miodek biznes
analityk/analityk IT

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Jarek Żeliński:

Jednak "ekran", który odwzorowuje PIT-5L jest znany i nikogo nie tzreba w urzędzie (biurze księgowym) niczego uczyć.

No i tu docieramy do sedna problemu - co ma dostarczyć projekt? Jeśli celem jest umożliwienie przepisania danych z formularza (np. PIT-5L), to formularz na ekranie musi być podobny, bo zwyczajnie wprowadzającemu będzie łatwiej. Ale jeśli mówimy o formularzu do faktur/księgowania to sprawa nie jest tak oczywista. Faktury się od siebie mocno różnią i większy wpływ ma odpowiednia kolejność wprowadzania danych (np. wpisując NIP pobieramy dane wystawiającego fakturę, jeśli jest już w naszym systemie).
Podobnie możemy podejść do innych formularzy. Owszem, czasem trzeba zainwestować w szkolenia. Ale czy ta inwestycja nie zwróci się, bo na przykład czas wypełniania będzie krótszy?

Np. 400 urzędów, razy 10 osób w sekretariacie razy trzy dni szkolenia w tym ćwiczenia po 1000zł (bardzo tanie szkolenie) = 400x10x1000= 4.000.000zł Kiedy to się zwróci?????????????

Jeśli zaoszczędzimy 10 minut dziennie na pracownika, to jest to 80 osobodni zaoszczędzonych dziennie. Licząc stawkę 2000 zł miesięcznie (niska pensja) mamy około 100 zł za osobodzień, czyli zwróci się po 2 latach. Powiedzmy 3 uwzględniając dodatkowo koszt oprogramowania. Wcale niezły ROI.
ostateczna decyzja pozostaje po stronie użytkowników.

ale nie wymuszać... i warto nie raz zrozumieć i uznać racje Klienta bo nie raz ma rację..

Cóż, tak naprawdę piszemy to samo.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

ta dyskusja sprowokowała mnie do szybszego ukończenia wpisu na blogu (dobrze, bo od miesiąca nie mogłem się do niego zabrać) :)))

mianowicie moim zdaniem ważny jest kontekst i aktor (zresztą to aktor daje kontekst), wtedy wiemy czy ekran to raczej kopia dokumentu czy może wręcz przepływ ekranów odwzorowujących drzewo decyzyjne, zgadzam się z Kasią: ekrany na etapie analizy wymagań to albo wzór dokumentu albo bardzo ogólne opisy, szczegóły zaprojektuje fachowiec od "dizajnu":

Ukryty link (zaloguj się, żeby zobaczyć)
Tomasz Cudzich

Tomasz Cudzich Prowadzenie
projektów, Analiza
Biznesowa,
Zarządzanie Tes...

Temat: Interfejs użytkownika - wymaganie klienta czy projekt...

Witam,
Przewrotnie na pytanie zawarte w temacie odpowiem na końcu. :)
Z mojego doświadczenia wynika, że w często prototypy ekranów dostarcza klient na etapie analizy wymagań. Jednak doświadczenie nauczyło mnie, żeby wspomniany ekran potwierdzić w kontekście jego ostatecznego kształtu. Wyniki to z tego, że niestety często pytanie prowokuje dyskusję. W efekcie klient odpowiada na własne pytanie "Czy na pewno tak ma wyglądać mój ekran?" i "suma summarum" prowadzi to do pracy (wspólnej) nad ekranem w trakcie analizy wymagań.
Reasumując ja wolę z klientem ekran "prototypować" podczas prowadzonej analizy wymagań. Prototypy są później rozwijane (bądź potwierdzane) na etapie późniejszej analizy szczegółowej. Są dobrą podstawą tak dla Dostawcy jak i klienta do dalszej analizy, nie pozwalają na "pływanie" w wyobraźni każdej ze stron o ekranie.
Czy każdy ekran należy "prototypować", nawet jeśli jest taki sam jak formularz "papierowy"? Uważam, że tak - przyczyna jest prosta - dokładność i jednoznaczność w kontekście wyglądu GUI-a. Brak jednoznaczności (jak w kontekście samego dokumentu analizy) powoduje dużo elementów dyskusyjnych na etapie odbioru projektu.
Odpowiadając na pytanie opierając się na powyższych doświadczeniach - uważam, że interfejs użytkownika jest wymaganiem klienta. Tylko na tyle specyficznym, że w jego wytworzeniu biorą aktywny udział obie strony (klient i analityk) próbujący znaleźć powiązanie wymagań funkcjonalnych, niefunkcjonalnych (sławna "ergonomia") z możliwościami (...) Zobacz więcej

Zarejestruj się, aby zobaczyć więcej dyskusji

Zarejestruj się



Wyślij zaproszenie do