Prototyping - do you need it?

21 october 2021
Jakub Rojek Jakub Rojek
Photo by picjumbo.com from Pexels
Categories: Methodologies, Graphics

"Prototypowanie" to termin, który jest używany w wielu branżach, w związku z czym jest raczej powszechnie zmiany. Wszędzie jest rozumiany jako przygotowywanie prototypu (lub prototypów), czyli rzeczy, które małym kosztem imitują docelowy kształt projektu w celu zobaczenia, czy to rzeczywiście to jest to, o co chodzi klientowi. W przypadku software house'ów najczęściej mówimy o makietach interfejsu, dzięki czemu już na wczesnym etapie, stosunkowo szybko można ustalić, czy wszystkie osoby uczestniczące w projekcie mają wspólną wizję oraz czy już w tym momencie nie widać jakichś oczywistych problemów z poruszaniem się po systemie.

Sprawa wydaje się zatem prosta - jest to coś, co nam pomaga, więc warto korzystać z tej koncepcji. Natomiast, jak zawsze, można tutaj dopatrzeć się paru rzeczy, które warto wyjaśnić i zaznaczyć różnice w używanej terminologii.

UI kontra UX

Zanim przejdziemy do samego makietowania, warto wyjaśnić terminy, które często przewijają się podczas rozmów i równie często są mylone.

W trakcie prac koncepcyjnych nad interfejsem pojawiają się dwa określenia, które niektórzy stosują zamiennie, a to błąd. UI to skrót od User Interface i jest zagadnieniem związanym z atrakcyjnością wizualną interfejsu. Zatem to UI-owiec (w praktyce - często nazywany grafikiem) odpowiada za dobór kolorów, fontów, rozmiarów, położenia elementów itd. Robi zatem to, czego oczekuje większość klientów chcących poznać i ocenić wizję aplikacji. Natomiast zdarza się, że zleceniodawca oczekuje również podpowiedzi dotyczących wygodnego poruszania się po oprogramowaniu i zmaksymalizowania zainteresowania użytkownika różnymi częściami systemu, realizacją procesów biznesowych itd. W takim wypadku UI-owiec nie wystarczy (choć tego tematu często trochę dotyka) - tutaj wchodzi działka zwana UX (ang. User eXperience), a więc projektowanie doświadczenia użytkownika. Często myli się te dwie role i oczekuje, że grafik nie tylko zaproponuje przyciągający uwagę wygląd, ale także zaprojektuje całą "podróż" użytkownika po systemie od A do Z. Warto pamiętać, że to drugie jest domeną UX-owca, na którego można sobie pozwolić zwykle tylko przy większych projektach.

Zatem nie należy mylić tych dwóch pojęć i nie zżymać się na grafika zbyt mocno, gdy ten sam poprosi np. o propozycję pozycji w menu. Nieocenione jest przedyskutowanie wcześniej wzajemnych oczekiwań i możliwości, aby uniknąć niemiłych sytuacji na późniejszym etapie.

Makiety kontra prototypy

W tym przypadku to "kontra" zostało użyte trochę na wyrost, gdyż drugie wynika często z pierwszego. Choć trzeba przyznać, że nie zawsze stosuje się obie formy w każdym projekcie, a zwykle tylko jedną z nich. Są to też terminy używane zamiennie i tutaj nie ma co z tym walczyć, gdyż taka jest siła przyzwyczajenia - poniższe przypistanie potraktujcie zatem jako jedną z propozycji.

Przykładowa makieta interfejsu

Makiety to tzw. prototypy o niskiej wierności (ang. low fidelity). Są to proste, często czarno-białe szkice przedstawiające proponowany wygląd interfejsu, ale na bardzo dużym poziomie ogólności. W tej kategorii chodzi głównie o pokazanie rozmieszczenia elementów, głównej idei stojącej za poszczególnymi obszarami (np. breadcrumby, menu, stopka), a zdecydowanie nie o kolory, font, dokładny rozmiar tekstu itd. Bardzo często stosowany jest tutaj wręcz Comic Sans, aby pokazać rysunkowość i "niepoważność" makiety. Po co się zatem ją stosuje, podczas gdy można by było od razu zaprezentować także pełną grafikę? Ze względu na czas i koszt - makiety robi się bardzo szybko, nie musi jej tworzyć grafik, a pozwala prędko ustalić wspólną wizję i nawet zacząć już prace implementacyjne w oczekiwaniu na "prawdziwe" prototypy. W dodatku zmuszają wręcz do skupienia sie na rzeczach ważnych na bardzo wczesnym etapie projektu, a nie ozdobnikach graficznych. Mogą powstawać w programach typu Mockingbird, Lumzy, Pencil, Axure, a właściwie nawet... w czymkolwiek.

Przykładowy prototyp stworzony w Adobe XD dla Feedybacky'ego (niewykorzystany)

Same prototypy to z kolei wizje o wysokiej wierności (ang. high fidelity) i te potrafią już przykuć wzrok oraz cieszyć oko. Powstają często na bazie makiet (jeśli te istnieją) i zawierają już realne propozycje graficzne, odpowiednie kolory, wypielęgnowany tekst itd. Wymagają dość sporo pracy i umiejętności, dlatego są zazwyczaj tworzone przez grafików, którzy przywiązują uwagę do każdego detalu. Realizowane są już w konkretnych programach graficznych - Photoshop, Adobe Illustrator, Adobe XD i innych.

O przydatności makiet/prototypów niech świadczą powyżej wklejone przykłady. Pierwszy faktycznie posłużył do ustalenia wraz z klientem jednego stanowiska i dzięki niemu dowiedzieliśmy się, że serwisant rzeczywiście może być tylko jeden (coś, co nas zastanowiło podczas prac i pomogło poprawić aplikację), a część pól jest niepotrzebna (co z kolei pozwoliło uniknąć zbędnej implementacji). Z kolei drugi obrazek przedstawia jedną z propozycji ekranu listy projektów w Feedybacky - powstały dwie koncepcje i na ich podstawie dyskutowaliśmy w zespole, która jest lepsza. Ostatecznie wygrała ta, którą użytkownicy znają z systemu, ale decyzja nie byłaby taka prosta, gdybyśmy podejmowali ją bez wizualizacji.

Warto też wspomnieć o tym, że czasami pod słowem "prototyp" można rozumieć bardzo prosty produkt, który ma imitować ten właściwy, ale już w pełni klikalny (nawet, jeśli według z góry ustalonego scenariusza). Częściej taką koncepcję można spotkać w innych, bardziej "fizycznych" branżach technologicznych, ale w IT też się zdarza.

Kto przygotowuje makiety i prototypy?

O ile w przypadku prototypów nie ma przebacz i ich wykonawca musi mieć odpowiednie umiejętności oraz wyczucie graficzne (stąd zazwyczaj zajmuje się tym grafik), o tyle w przypadku makiet nie jest to takie oczywiste. Bardzo często, jeśli jest potrzeba ich przygotowania, dzieje się na to bardzo wczesnym etapie, kiedy budżet jest bardzo ograniczony, gdyż czasami nawet nie wiadomo, czy projekt będzie kontynuowany. W dodatku, dużo ważniejsza przy nich jest wiedza o wymaganiach biznesowych niż wyczucie estetyczne i z tego powodu makiety często przygotowuje ktokolwiek z zespołu realizującego - zazwyczaj analityk, ale czasami to programista ma wątpliwości, w którą stronę skierować się z choćby wstępnym kształtem interfejsu i sam decyduje się naszkicować parę makiet w celu skonsultowania ich z klientem.

Czy warto to robić?

Odpowiedź na to pytanie pewnie jest już jasna i pozytywna, natomiast warto wspomnieć o powodach, przez które prototypy niekiedy nie powstają.

Oczywiście, większe prace związane z przygotowywaniem takich "protez" nie są potrzebne, gdy w grę wchodzi niewielka aplikacja lub będzie ona wykorzystywana wyłącznie w wąskim gronie czy przez krótki czas. Dodatkowo, makiety nie są zwykle potrzebne, gdy w perspektywie jest dość szybkie przygotowanie pełnych prorotypów. Nie ma też zwykle sensu makietować wszystkiego, każdego ekranu, chyba że interfejs jest na tyle skomplikowany i zróżnicowany, że taka operacja może przynieść korzyści lub zapobiec błędom.

Na przeszkodzie często stoi też budżet, jednak należy się dobrze zastanowić, czy istotnie makiety lub (w mniejszym stopniu) prototypy nie mogą... naprawić tego budżetu. Bardzo wiele godzin jest "przepalanych" na poprawki i modyfikacje, które wynikają z innej wizji klienta dotyczącej szczegółów niż ta, którą miał wykonawca. Można tego częściowo uniknąć choćby stosując właśnie przybliżone makiety. Ich przygotowywaniu towarzyszy jeszcze jedna, ważna kwestia - podczas samego procesu projektowania człowiek uświadamia sobie wiele rzeczy, lepiej układa projekt w głowie oraz zaczyna widzieć obszary wymagające doprecyzowania. Dlatego przy dobrym narzędziu, tworzenie makiet nie musi być wcale bardzo czasochłonne, a wręcz może zaoszczędzić nam wiele godzin. Zyskuje też na tym dokumentacja w kontekście ewentualnych sporów pod koniec prac.

Mam nadzieję, że teraz temat makiet i prototypów ma dla Was nieco więcej głębi niż wcześniej. Jeśli chcesz podyskutować o tym temacie, gdyż masz np. inne zdanie lub swoje spostrzeżenia - zapraszam do kontaktu za pomocą linków podanych poniżej.

Pozdrawiam i dziękuję - Jakub Rojek.

We can do quite a bit and what is more, our skills and resources are at your disposal. Take a peek at what we can offer you.

About author

Jakub Rojek

Lead programmer and co-owner of Wilda Software, with many years of experience in software creation and development, but also in writing texts for various blogs. A trained analyst and IT systems architect. At the same time he is a graduate of Poznan University of Technology and teaches at this university. In his free time, he enjoys playing video games (mainly card games), reading books, watching american football and e-sport, discovering heavier music, and pointing out other people's language mistakes.

Jakub Rojek