Prototypowanie z prawdziwym tekstem, czy Lorem Ipsum?

Dwójka interesariuszy przerażona Lorem Ipsum
Interesariusze patrzą na twój prototyp z brakiem podziwu. Lorem Ipsum!

Znasz to na pamięć: “Lorem ipsum dolor sit amet, consectetur adipiscing elit. Vestibulum tempus enim eget orci accumsan pellentesque. Suspendisse eget ex vel felis euismod congue aeros.”. I podobne. Wciskane, gdzie wlezie. Pamiętam, jak szczęśliwy byłem kiedy odkryłem automatyczne generatory Lorem Ipsum gdzieś tak w okolicach 2004 roku. Och, jakże ułatwiało mi to życie!

Jak dobrze nauczyło mnie to produkować prototypy, które… ni cholery nie trzymały się kupy i, których nie dawałem rady przetestować tak dobrze, jak bym chciał.

Dzisiaj o szatanie wychylającym z każdej makiety, czyli o tym, dlaczego im wcześniej zaczniesz współpracę z content writerem, tym lepiej.

Pozorna wygoda

Ja to rozumiem. Kiedy stawia się na deskach Axure kwadraciki, kółeczka i calls to action, to trzeba coś na nich napisać, czymś je wypełnić, żeby nie było smutno. Tak samo jest w każdej możliwej opcji prototypowania — zawartość strony czy aplikacji nie wygeneruje się sama. Jednak z wstawianiem Lorem Ipsum w makiety, prototypy i w interfejsy ogółem jest pewien problem. A raczej, kilka problemów.

Kłopoty z tzw. mockup copy

  1. Wstrzelenie pseudo-łaciny w nasze prototypy ogranicza nasze pole widzenia i przytępia nasz projektancki “węch”. Przestajemy zastanawiać się nad konsekwencjami tego, co czyta użytkownik i co komunikuje interfejs, po prostu odsłaniając kolejne pokłady nic nie znaczącego tekstu.
  2. Lorem Ipsum i podobne brązowe lisy skaczące przez leniwe psy uniemożliwiają zrozumienie podróży użytkownika w całej krasie, powodując nie tylko to, że testy prototypu stają się trudne ale i to, że interesariusze, którzy płacą nasze rachunki sami nie wiedzieć będą, o co loto. Nie zobaczą swojego projektu-dziecka nakreślonego z dokładnością, na jaką liczyli, kiedy polecono im tego “speca od UX”. A to, oczywiście, może odbić się negatywnym echem na odbiorze naszej pracy końcowej.
  3. Placeholder copy wypełnia przestrzeń w sposób zunifikowany i równy. Prawdziwy tekst, wbrew pozorom, płynie zupełnie inaczej od Lorem Ipsum. Można nieźle się na tym przejechać zwłaszcza, jeśli nasz projekt opiera się na silnym aspekcie wizualnym (np. makieta jest stosunkowo hi-fi.)
  4. Oko ignoruje bzdury, których nie rozumie. Często ważne kawałki interfejsu mogą zagubić się w gąszczu pseudo-łaciny.
  5. Wielu klientów nie spotkało się nigdy z czymś takim jak Lorem Ipsum i, zwłaszcza, jeśli prezentujemy prototyp zdalnie (np. dzieląc się linkiem) to, w zetknięciu z prostą estetyką naszego projektu (w końcu to makieta) mogą się trochę zszokować.
  6. Na etapie, na którym szkicujemy i projektujemy interfejs porządny tekst może już istnieć w jakimś pliku Worda lub nieznanym repozytorium git — a my możemy zwyczajnie o tym nie wiedzieć. Warto spytać, czy tak nie jest. Może ktoś już toto napisał? A jeśli nie?

Co zrobić?

Magik poszukiwany

W porządnych organizacjach pisaniem treści (contentu) zajmują się content writerzy. Są to ludzie, których zadaniem jest zrozumienie, co trzeba zakomunikować użytkownikowi i jak to zrobić w zgodzie z tonem, jaki przyjmuje organizacja. Uwielbiam z nimi pracować, bo najczęściej są doskonale zaznajomieni nie tylko z wymaganiami projektu (a jeśli nie są, to do nas należy zaznajomienie ich) ale i ze strategią marketingową firmy. W pracy z content writerem łatwo jest ustalić zakres obowiązków; przeprowadzając go przez proces projektowy i uwzględniając na etapach definiowania założeń wstępnych, a także w czasie prototypowania możemy znacząco poprawić jakość prototypów, których potem użyjemy do testów i do prezentacji przed interesariuszami.

Ale co zrobić, kiedy pod ręką nie ma nikogo odpowiedzialnego za treść serwisu? Albo, kiedy — nie daj Boże — szef stwierdza, że “pani Ula od marketingu (albo i pani sekretarka) może napisać to wszystko, to przecież nie jest trudne…”?

Odpowiedź, jak zwykle, jest prosta.

Napisać to, co trzeba, czyli zrobić wszystko samemu.

Ja jestem projektantem, nie pisarzem!

Powie niejeden projektant i niejedna projektantka. Uczyliśmy się pisać w szkole i wielu z nas nienawidziło szczerze czasów, w których trzeba było przelewać na kartki brulionów wykaligrafowane i umęczone strofy, które zmieniały kolor z czarnego na czerwony po tym, jak dobrał się do nich belfer. Proszę się uspokoić, tu nikt epistoł pisał nie będzie. Chodzi tylko o to, że w sytuacji, w której na etapie prototypowania nie mamy dostępu do ekspertyzy kogoś wykwalifikowanego do pracy z tekstem powinniśmy skupić się, i:

  1. Sięgnąć do dobrze udokumentowanej listy potrzeb użytkownika i organizacji (user i business needs — jeśli tych nie mamy pod ręką, to warto poszukać nocnika, zanim zrobi się niemiło),
  2. Upewnić, że znamy założenia projektu i, że jasnym jest dla nas, jak przebiegają user journeys,
  3. Zasiąść do projektowania kolejnych ekranów naszej strony internetowej lub aplikacji i, najlepiej jak umiemy, zacząć wypełniać luki w tekście, który komunikuje użytkownikowi wszystkie najważniejsze założenia i elementy interakcji.

Dobry projektant UX powinien posługiwać się słowem chociażby w stopniu umożliwiającym mu proste opisywanie tego, co się dzieje. Ponadto, pracując z jakąkolwiek organizacją powinniśmy być w stanie wczuć się nieco w jej naturę i powić teksty, które będą odzwierciedlać charakter produktu. Chociaż troszeczkę.

Oczywiście, to da się zrobić tylko, jeśli sami wiemy, jakie założenia ma realizować produkt i kim są jego użytkownicy. Jeśli tak nie jest, to myślę, że problemy związane z treścią możemy zepchnąć na dalszy plan… Ups.

Spójrzcie na przykładowy mini-prototyp.

Który ekran komunikuje więcej? Przygotowanie tego, który działa lepiej zajęło mi tylko chwilę dłużej. Warto to zrobić.

Makieta rewolucyjnej aplikacji Kiszon Deluxe pokazująca, czym różni się prototyp wypełniony właściwym tekstem od takiego bez tekstu.
Który prototyp Kiszona Deluxe byłoby łatwiej przetestować?

Co uzyskamy używając “prawdziwego” contentu?

  1. Każdy, kto zobaczy nasz projekt będzie w stanie zrozumieć chociaż trochę — i poprzez to odnieść się jakoś do tego, co dzieje się na poszczególnych etapach podróży.
  2. Interesariusze zrozumieją, że dbamy o ich produkt i, że warto zainwestować w napisanie poprawnej treści (bo nasza zapewne polegnie w testach, jednakże o wiele mniej, niźli padłoby na twarz Lorem Ipsum).
  3. Skoncentrujemy się bardziej na prototypowaniu i pewne logiczne zależności pomiędzy krokami, które podejmuje użytkownik ukażą się nam wyraźniej. Może nawet wpadniemy na jakiś nowy pomysł, albo zobaczymy coś, czego wcześniej nie widzieliśmy?
  4. Nasze koleżanki i koledzy z zespołu lepiej zrozumieją, o co nam chodzi.

Nie da się ukryć, że zastanowienie się i produkcja prototypu z „właściwym” tekstem zajmą nam więcej czasu — ale warto się poświęcić.

Przyłóżmy się!

Pseudo-łacina jest spoko, ale tylko na bardzo, bardzo wstępnych szkicach. Im szybciej zapomnimy o tym wytworze ery projektowania graficznego prasy lat 60-tych, tym lepiej. Coraz więcej zresztą pojawia się na rynku pracy content writerów, którzy podkreślają swój związek z domeną UX. I coraz trudniej zdobywać się na wymówki związane z nieumiejętnością komunikacji za pomocą tekstu. Użytkownicy (i partycypanci testów, a także interesariusze) nie lubią zastanawiać się bez potrzeby. I nie powinni.

Z perspektywy kogoś, kto zatrudniał ludzi do pracy w UX mogę też powiedzieć, że porządne, pełne choćby w miarę sensownego tekstu prototypy zawsze działały na moją wyobraźnię lepiej, niż te z placeholder copy. Warto się nad tym zastanowić, jeśli kompletujesz portfolio.

Jak włączać copy writerów do projektów UX?

O tym (i o innych sztuczkach związanych z planowaniem procesów projektowych UX) opowiem 24 listopada w Gdańsku. Odwiedź stronę UX w praktyce, gdzie dowiesz się więcej na ten temat. Bilety będą tańsze do 31 października. Warsztaty trwają cały dzień i składają się z porannej części teoretycznej i popołudniowej, na której będziemy pracować w grupach.

Przeczytaj o tym, jak było w Warszawie. I do zobaczenia w Gdańsku!