Kiedy pierwszy raz widzisz wireframy, może to być trochę dziwne.. „Miałam robić projekty, które będą zgarniać nagrody, które będą cieszyć oko użytkownika i moje ego. A teraz każecie mi rysować szare kwadraty?!”. Bez obaw, przecież to nie jest finalny efekt pracy, ale nie znaczy to, że należy go pomijać. Więc kiedy widzisz dużo szarości i Comic Sansa, możesz być prawie pewien, że to wireframe. Czyli.. po tym jeszcze coś będzie. Wireframy są ważną częścią etapu ideacji, a jednocześnie zwieńczeniem, moim zdaniem, najważniejszej części procesu, czyli odkrywania i researchu (ang. discovery). To moment, kiedy nadal szukamy idealnego rozwiązania. Wireframe celowo nie jest ładny, kolorowy, wypieszczony – tym sposobem łatwiej jest utrzymać dyskusję na poziomie rozwiązań użytecznościowych. Na rozmowy o kolorach jeszcze przyjedzie czas, bo po wireframach przechodzimy do fazy UI, gdzie tworzony jest finalny interfejs użytkownika.
Ok, to co to jest ten wireframe?
Wireframe to schematyczny, wizualny zapis projektowanej strony czy funkcjonalności. To swego rodzaju szkic, etap przejściowy między problemem, pomysłem i rozwiązaniem. Dzięki wizualnej formie łatwiej dyskutować nad jakimś pomysłem w formie wireframu, niż z jego zapisem słownym. Wireframe nie powinien być traktowany jak coś finalnego, tylko właśnie jak szkic, który ma ułatwiać nam dyskusję nad pomysłem.
Wireframe powinien być brzydki
A dlaczego powinien być brzydki? To oczywiście skrót myślowy, ale chodzi o to, żebyśmy nie przywiązywali się do pierwszych wireframów i dali sobie przyzwolenie na pokazanie czegoś nieskończonego. Często wiąże się to z lekkim dyskomfortem, bo jako projektanci chcielibyśmy pokazywać tylko nasze wymuskane arcydzieła, a nie pięciominutowe bazgroły. Jednak naprawdę warto to robić, bo sami zobaczycie, że im więcej dyskusji odbędziecie na etapie wireframów, tym mniej będzie uwag na późniejszych etapach. A tam pewnie włożycie o wiele więcej serca i cennego czasu.
Dlatego właśnie wireframe bazuje na prostych kształtach i zarysie treści. Zazwyczaj nie używa się w wireframach kolorów, zdjęć czy ilustracji. Dlaczego? Odpowiedź jest prosta i związana bezpośrednio z celem wireframu – ma on prowokować dyskusję na temat fukcjonalności, celów biznesowych, potrzeb użytkownika i wykorzystanych komponentów, a nie na temat kolorów czy kształtu przycisku. Dyskusja na tym etapie powinna być nastawiona na cele i dobrane rozwiązania, a nie wygląd danych komponentów. Na przykład rozmawiamy o tym, czy umieszczenie przycisku w danym miejscu ma sens, a nie o tym, czy przycisk powinien być zielony czy niebieski.
Wireframe to narzędzie do komunikacji pomiędzy designerami, programistami i interesariuszami. Kiedy włączamy wszystkich do projektu już na etapie wireframu, wszyscy wiedzą co robić dalej. Po wypracowaniu finalnej wersji wireframów, designer może zacząć pracować na UI, deweloperzy mogą pracować nad logiką danej części aplikacji, a content writer może przygotowywać treści, ponieważ wszyscy znają cele i ogólną strukturę.
Rodzaje wireframów
Możemy wyróżnić dwa typy wireframów ze względu na ich poziom szczegółowości. Najczęściej spotkacie się z low-fidelity oraz high-fidelity wireframes. Widziałam w różnych materiałach również wireframy mid-fidelity, ale osobiście nie widzę w nich sensu, także pozwólcie, że nie opiszę ich tutaj. Wybaczcie też angielskie nazwy, ale nie spotkałam się z polskimi odpowiednikami. Fidelity to z ang. dokładność, wierność. Ja sobie je w głowie, dla celów własnych, tłumaczę jako wireframy mało szczegółowe i bardziej szczegółowe.
Low-fidelity wireframe
Zawsze zaczynam od odręcznych, mało złożonych low-fidelity wireframów. Możecie spotkać się też ze skróconą nazwą Lo-Fi wireframe. Taki szkicowy, prosty wireframe jest dla mnie jak robienie notatek. Zazwyczaj robię to w ogóle na kartce, korzystając z ołówka lub długopisu. Jak mi się coś nie podoba, to bez wyrzutów sumienia przekreślam albo gniotę kartkę i wyrzucam do kosza. Kiedy szkicuję jedną koncepcję, od razu mam w głowie kolejny wariant, który rysuję obok, coś kreślę, coś robię bardziej wyraźne, czasami robię też małe notatki obok, które są komentarzem lub pytaniem, które muszę zadać programistom albo Product Ownerowi.
Z takimi szkicami zazwyczaj idę na spotkanie z zespołem. Przegadujemy sobie te pomysły, a oni czasami dorzucają swoje trafne uwagi. W trakcie dyskusji wychodzi też, że coś jest technicznie wymagające i lepiej poszukać innego rozwiązania lub kompromisu. Właśnie dlatego doceniam takie szybkie, odręczne wireframy, bo nie mam żadnych skrupułów, żeby niektóre z pomysłów dosłownie wyrzucić do kosza po dyskusji z zespołem.
Oczywiście można już na tym etapie korzystać z digitalowych rozwiązań, odręczne szkice mogą nie być dla każdego. Zdarzało mi się robić wireframy w Balsamiq, Figmie czy Sketchu. Warto tylko pamiętać, żeby nie wchodzić jeszcze za mocno w detale. Na tym etapie stawiałabym bardziej na ilość niż na jakość.
Jak prezentować wireframy?
Ja nie mam problemu z dzieleniem się odręcznymi konceptami, i żaden mój klient też nigdy nie miał z tym problemu. Robię zdjęcie telefonem, czasami podciągam kontrasty i udostępniam. Jeśli chcesz pokazać jakiś flow, możesz wykorzystać narzędzie jak na przykład Invision, które pozwoli z Twoich bazgrołków zrobić interaktywny prototyp. To na pewno bardziej interesujący i zrozumiały sposób pokazywania pomysłów klientowi, niż wysyłanie kilku plików .jpg z długim opisem. Co więcej! Taki prototyp można podać testom z użytkownikami i zamiast mędrkować, które rozwiązane będzie lepsze, przekonać się o tym na żywym organizmie, czyli grupie docelowej albo w testach korytarzowych.
High-fidelity wireframes
Drugi typ wireframów, to Hi-Fi wireframe, czyli taki już bardziej szczegółowy i czytelny. Tego typu wireframy przygotowujemy już raczej w narzędziach cyfrowych – Figma, Sketch czy co tam lubicie. Na tym etapie wchodzimy głębiej w detale, a program pomaga nam trzymać proporcje elementów na ekranie. Wchodząc w szczegóły, zastanawiamy się już konkretnie jakie elementy interfejsu muszą się znaleźć na danym etapie i jak względem siebie rozmieszczone, jaki element powinien grać główną rolę, a które są tylko wsparciem. Przy high-fidelity wireframach nie pomijamy już takich detali jak na przykład helper text przy inputach.
Żeby ułatwić sobie pracę, korzystam często z gotowych komponentów. Jeśli jest w firmie design system, to warto z niego korzystać. Jeśli design systemu nie ma, korzystam z Material Design od Google, albo z komponentów do wireframów pobranych z Figma Community. Jest tego mnóstwo, warto korzystać i ułatwiać sobie pracę. Bardzo polecam korzystanie z bibliotek, bo jest to ogólnie świetny sposób na naukę projektowania aplikacji i stron internetowych. Dzięki rozbudowanym galeriom komponentów, można zobaczyć, jak wiele jest możliwości rozwiązania jednego problemu, które ktoś już wymyślił.
Starannie przygotowane, przemyślane wireframy, to ogromne ułatwienie dla UI Designera, który będzie z nimi pracował przygotowując finalne ekrany do developmentu.
Dobrze radzę, nie pomijaj wireframów
Kiedy termin goni albo mamy do dyspozycji gotowy Design System, to często pojawia się pokusa, żeby od razu wskoczyć w UI, bo po co rysować szare kwadraty, skoro można korzystać z gotowych komponentów, nie? No właśnie nie zostało to wymyślone po to, żeby nam pracę utrudnić, lecz wbrew pozorom ułatwić. Nawet jeśli to miałby być tylko odręczny, lo-fi wireframe, zawsze warto go zrobić i przedyskutować z zespołem oraz product ownerem. Dzięki temu będziesz mieć pewność, że macie takie samo zrozumienie jeśli chodzi o założenia, cele i flow użytkownika.
Nie jestem święta, też zdarzyło mi się pominąć wireframy. I bardzo szybko tego pożałowałam… To była podobna historia do tego, co opisałam powyżej. Byliśmy po kilku sprintach projektu, więc wiele komponentów zostało już stworzone, więc można było kopiować, wklejać, lekko dostosowywać. Założyłam, że w takim razie nie potrzeba już robić wireframów, bo przecież wszystko jest gotowe i kolejne flow w aplikacji złożę „tak po prostu” z klocków…
Oh, jak bardzo ja się myliłam. Kiedy pokazałam efekty mojej pracy klientowi, wywiązała się bardzo intensywna dyskusja, a co najgorsze, mieszały się wszystkie wątki, skakaliśmy od założeń do detali. Nie było wiadomo, czy rozmawiamy o przycisku w kontekście flow użytkownika, czy dyskusja jest o tym jaki tekst jest na przycisku czy o sensie tej funkcjonalności w ogóle. To było baaaardzo chaotyczne i wysysające energię spotkanie, po którym dodatkowo byłam bardzo niepocieszona, że muszę coś zmieniać w projekcie, który przecież był „gotowy”. Prawdopodobnie gdybym miała poprawić coś na wireframie, to nie miałabym takich myśli, bo one z definicji są czymś, co jeszcze może się zmienić.
Kiedy pomijamy wireframy odbieramy sobie często szansę na wysokopoziomową dyskusję zahaczającą o content strategy, hierarchię treści i cele strony generalnie. Kiedy my w projekcie schodzimy do detali, dyskusja również tam wędruje. Także jeśli chcesz mieć pewność, że projektujesz dobre doświadczenia użytkownika, to proszę, nie pomijaj wireframów.
Jak używam wireframów do lepszej komunikacji w zespole
Najlepszym przykładem dobrego wykorzystania wireframów będzie zespół marketingowy, w którym pracowałam jako Product Designer. Byliśmy odpowiedzialni między innymi za rozwój firmowej strony internetowej, która była jednym z narzędzi sprzedażowych firmy. Zmienialiśmy dużo i szybko, więc aby ułatwić naszą pracę, a jednocześnie nie pomijać ważnych etapów procesu, wypracowaliśmy własny framework.
Zawsze zaczynaliśmy od tablicy lub dokumentu, w którym spisywaliśmy cel biznesowy zmiany, którą wprowadzamy oraz potrzebę użytkownika, która się z tym wiąże. To wszystko wiązała w całość hipoteza, którą probowaliśmy zwalidować. Skąd się brały cele? Wynikały najczęściej z różnego rodzaju danych – analitycznych, researchu konkurencji, badań z użytkownikami lub obserwacji ich zachowania. Podczas całego procesu mieliśmy to przed sobą i odwoływaliśmy się do spisanych założeń w momencie jakiegokolwiek zawahania lub rozjazdu. Bazując na spisanych założeniach mogliśmy zacząć ideację – co musimy umieścić na wdrażanej stronie, aby zrealizować postawione cele. Pomysły zaczynają nam się to układać w jakąś narrację, którą łatwo przedstawić za pomocą wireframu. Tworzymy go wspólnie, narzędzie nie ma znaczenia – może być Miro, Mural, Figma, a czasem robimy to nawet w Google Docs. Takie wireframy tworzone z zespołem podczas warsztatów są często mniej wizualne, a bardziej tekstowe, zawierają wiele komentarzy i notatek, które uwzględniam w kolejnych, już bardziej dopracowanych wizualnych.
Wireframe jest dla nas w tym przypadku taką wspólną notatką, którą wszyscy wynosimy ze spotkania, mając poczucie, że każdy wniósł do tego coś od siebie. Staram się, aby w takich warsztatach uczestniczył cały, multidyscyplinarny zespół projektowy, dzięki czemu po warsztacie wszyscy możemy zaczynać pracę. Po takich około 1- czy 2- godzinnych warsztatach (w zależności od skomplikowania projektu) ja jako projektant zaczynam przygotowywać odrobinę bardziej detaliczne wireframy z różnymi sugestiami i wariantami w podejściach, programista może już zacząć myśleć nad warstwą logiczną, bo generalny zarys ustaliśmy na warsztacie, a content writer może zbierać materiał pod teksty na stronę. Dzięki temu oszczędzamy wiele czasu, który musielibyśmy spędzać na późniejszych wyrównaniach, a dodatkowo bardzo przyśpieszamy start projektu, dzięki temu, że pracujemy równolegle i nie musimy czekać na siebie nawzajem.
Podsumowanie
Wireframy są ważnym i często niedocenianym elementem procesu UX. Celem wireframu jest poszukiwanie najlepszego możliwego rozwiązania na postawiony problem, zanim jeszcze przejdziemy do dyskusji o kolorach i typografii. Kiedy tylko to możliwe, powinniśmy już na tym etapie angażować cały zespół, co pozwoli na lepsze efekty i natychmiastowe wyrównanie zespołu.
