Wprowadzenie

W marcu 2021 w artykule Struktury formularzy jako forma wyrażania wymagań skupiłem się na detalach treści formularzy ekranowych, jako elementach specyfikowania przypadków użycia. Artykuł ten sprowokował pytania o związki między formularzami, ich przepływy oraz niekończące się pytania o cel stosowania związków extend i include używane często niepoprawnie w celu pokazania “przepływu ekranów”. Dlatego napisałem post będący rodzajem kontynuacji tego tekstu.

W toku analizy biznesowej, a potem projektowania oprogramowania, powstają różne produkty: modele procesów biznesowych, modele architektury systemów, scenariusze integracji, definicje interfejsów, i inne. Większość ich jest niezrozumiała dla przeciętnego uczestnika takiego projektu, który generalnie czeka na oprogramowanie zaspokajające jego potrzeby. Jak z nimi rozmawiać?

Proces biznesowy zobrazowany jako schemat blokowy na ustalonym poziomie szczegółowości, jest zrozumiały dla większości, po ewentualnym krótkim przeszkoleniu. Jednak czytanie modeli wnętrza systemów informatycznych, wykonanych z użyciem UML, niestety już nie jest proste i wymaga znacznie większych kompetencji. Tu już adresatem jest przyszły wykonawca (developer). Co więc pokazać Zamawiającemu? Makietę!

Interfejs użytkownika to jedyne co widzi użytkownik, dlatego bardzo często jest to – makiety interfejsu użytkownika – podstawowa metoda komunikowania przyszłemu użytkownikowi (zamawiającemu analizę i projekt) efektów pracy projektanta oraz sposób na konsultowanie tego z Zamawiającym. To co jest “pod maską” samochodu to domena projektanta, który musi zapewnić realizację (mechanizm działania) tego co powinien zobaczyć kierowca na tablicy rozdzielczej. Jednak nie oczekujemy, że przeciętny użytkownik samochodu ma kompetencje konstruktora samochodów i ze zrozumieniem czyta jego dokumentację techniczną, albo co gorsza, zaproponuje jakieś “dobre rozwiązanie”.

Opis

Praca analityka projektanta to obietnica, że zaprojektowany mechanizm, realizujący to co pokazują makiety ekranów, jest poprawny (zadziała). Weryfikatorem tej obietnicy jest etap implementacji.

Wizja czyli LOFI

Makiety LOFI (ang.: Low Fidelity, niska jakość graficzna) robimy na wczesnym etapie projektowania. Ich prostota i ogólność pozwala skupić się na projekcie i koncepcjach. Na tym etapie poświęcamy czas na ideę systemu. Skupiając się na istocie problemu możemy, niemalże w czasie rzeczywistym, zbierać opinie zamawiającego na temat szkicowanego prototypu. Na podstawie tych opinii można szybko, minimalnym nakładem pracy, przerobić makietę w ciągu zaledwie kilku minut.

Często początkiem jest wizja scenariusza pracy z aplikacją w określonym kontekście:

Kolejny etap to uzgodnienie treści każdego ekranu ale nadal na poziomie LOFI:

Idziemy do celu

Makieta HIFI (ang. High Fidelity, makieta wysokiej jakości) to generalnie projekt na etapie implementacji, ewentualnie może być potrzebny w końcowym etapie projektowania, szczególnie gdy rozwijamy istniejącą aplikację i mamy do dyspozycji “prawdziwe ekrany”. Wtedy możemy tworzyć makiety HIFI na bazie zrzutów ekranów istniejącej aplikacji i edytować je na poziomie HIFI:

Kluczowym celem prototypowania HIFI jest uzgodnienie ostatecznej wersji ekranów, zanim zacznie się ich implementacja (ostateczną wersję i tak przedstawi developer).

Cały czas pamiętamy, że kodowanie jest najdroższym elementem projektu i należy go minimalizować na rzecz projektowania.

Prezentacja makiet HIFI pozwala też na uzyskanie ostatecznych szczegółowych informacji zwrotnych na temat określonych elementów projektu, co nie byłoby możliwe przy użyciu makiet LOFI. Jeżeli mamy możliwość pokazania animacji, to klient ma możliwość zapoznania sie z tym co dostanie i zgłosić swoje uwagi dot. np. ergonomii.

Korzyści z prototypowania GUI

Opracowywanie makiet to tak zwany “rapid prototyping”, czyli szybkie prototypowanie. W fazie projektowania, znacznie efektywniejsze niż dostarczanie kolejnych działających wersji aplikacji na etapie implementacji. To większa możliwość prezentacji efektów dla interesariuszy: klienci otrzymają jasne wyobrażenie o tym, jak produkt będzie wyglądał i działał, zanim jeszcze zacznie powstawać. Na tym etapie można też ustalić jasne oczekiwania z deweloperami na wczesnych etapach ich pracy, w tym ile czasu będzie potrzebne do zbudowania prototypu i posiadania gotowego produktu.

Korzyści z narzędzi wbudowanych do CASE

Sam prototyp to tylko połowa sukcesu. W końcu te ekrany są konsekwencją (lub początkiem) projektu architektury wykonanego z jakimś narzędziu CASE z użyciem notacji UML. Dlatego bardzo ważne jest połączenie treści tych makiet ze słownikami, modelami danych oraz oczywiście z przypadkami użycia i ich scenariuszami.

Dzięki temu jesteśmy w stanie utrzymać spójność całego projektu, a także wygenerować pełną dokumentację, bez potrzeby zbierania efektów pracy z kilku różnych aplikacji, co niestety bywa ogromną pracą, także przy każdej aktualizacji.

Podsumowanie

Praca z prototypami ekranów aplikacji (wireframes) to nie tylko ich treść ale przede wszystkim ergonomia i efektywność, a ideałem jest prototypowanie w czasie rzeczywistym, czyli praktycznie równolegle ze słownym opisywaniem potrzeb w rozmowie. To co prawda najrzadsza forma pracy, ale na etapie szybkiego szkicowania scenariuszy nie taka rzadka.

Warto wiedzieć, że w praktyce narzędzia do prototypowania doskonale się sprawdzają w roli szybkiego tworzenia/dokumentowania formularzy w modelach procesów biznesowych (obiekty DataObject w notacji BPMN). Zamiast przygotowywać szablony dokumentów z pomocą standardowych edytorów tekstów, arkuszy kalkulacyjnych czy narzędzi do przygotowywania prezentacji, znacznie efektywniejsze jest tworzenie w narzędziu CASE makiet tych dokumentów i logiczne ich łączenie z elementami na modelach BPMN i UML.

Prezentacja

W tym momencie przerwę pisanie a zaprezentuję narzędzie którego od lat sam używam.

Więcej na stronie: UX Design and Wireframe Tools