Pięć przepisów na szybkie poprawki w UX
Ponieważ dzisiaj wyszedł podcast, w którym ugościł mnie Maciek Aniserowicz z Devstyle, pomyślałem, że pomogę trochę braciom i siostrom w digitalu – programistom i programistkom – i skrobnę dla nich artykuł, który pozwoli im wprowadzić do swojej praktyki małe działania, poprawiające jakość doświadczenia użytkowników software’u, który piszą na co dzień.
W podcaście opowiadam o tym, że każdy jest w pewien sposób odpowiedzialny za część doświadczenia użytkownika. Dotyczy to także programistów, czyli osób zajmujących się szeroko pojętym kodem. I tych od back, i tych od front-endu. Kiedy jednak staje się na przeciwko tak rozległej domeny jak UX, można się w tym wszystkim nieźle pogubić. Gdzie spojrzeć? Za co się wziąć?
I stąd właśnie pomysł na ten krótki artykuł dla naszych kolegów i koleżanek po „drugiej stronie barykady” (tak naprawdę pracujących dokładnie po tej samej stronie).
Dlaczego warto?
W skrócie, zadowolony użytkownik końcowy (czasem: klient), to:
- Więcej spokoju sumienia i mniej bugów do naprawiania.
- Większe zadowolenie z dobrze wykonanej pracy.
- Większe pole do popisu. Zadowolony klient z przyjemnością łyknie mądrze przeprowadzone eksperymenty.
- Więcej kasiorki w kasie organizacji. Czytaj: prezes/owa w ekstazie i bonusy świąteczne.
- Mniej marudzące i bardziej zadowolone drużyny UX, a co za tym idzie, mniejszy ból głowy i weselsza kolaboracja.
- Renoma – być odpowiedzialnym za doskonałe wdrożenie (np. startupie, który podbija rynek) to niezłe wyróżnienie.
A zatem:
Pięć rzeczy, które może zrobić (prawie) każdy programista, by szybko ułatwić życie użytkownika końcowego
1: Wprowadzenie poprawnej obsługi błędów w formularzach
Internet to informacje, formularze i kotki. I w sumie niewiele więcej. No, jeszcze filmy z gołymi ludźmi w dziwnych konfiguracjach, ale o tym na blogu nie będzie. Formularze to trzon interakcji pomiędzy użytkownikami komputerów a maszynami spiętym w internet. Dobra obsługa błędów w formularzu to taka, która:
- Jasno identyfikuje, które dane wymagają poprawy. Nie tylko za pomocą koloru pól (np. zmianie tego koloru na czerwony), ale także z pomocą komunikatu obecnego w obrębie tagu <label>.
- Pozwala zrozumieć, ile błędów jest do poprawienia – i gdzie. Fajną metodą jest wylistowanie błędów nad formularzem, jasno i przejrzyście. W numerowanej liście.
- Pozwala edytować dane po wysłaniu.
- Jest oznaczona rozszerzeniem standardu ARIA (jeśli następuje dynamicznie) po to, by informować czytniki ekranowe i inne technologie dostępu o tym, co dzieje się poza obszarem załadowanego od początku DOM.
Aby dowiedzieć się więcej o obsłudze dostępnych i wygodnych formularzy, polecam sięgnąć po materiały związane z semantycznym HTML.
2: Unikanie żargonu
Nie wszyscy użytkownicy internetu i komputerów operują żargonem programistycznym. Nie oznacza to, że są głupi – tylko po prostu mają inne rzeczy na głowie. Nie każdy zrozumie, o co nam chodzi, jeśli będziemy mówić do niego na przykład takie rzeczy, raportując błędy:
„An unnamed file contained an unexpected object” (Autodesk)
„There is no value for the required value state” (Dex)
“Network error: the operation could not be completed. (WDGeneralNetworkError error 500)” (zdaje się, Western Digital).
Czasem wystarczy poprosić o pomoc kolegę albo koleżankę z działu copywritingu. Ewentualnie napisać coś, co zrozumie osoba bez wykształcenia w IT. Na przykład:
„Natrafiłeś na problem, którego nie zauważyliśmy. Przepraszamy. Sprawdzimy, co się dzieje i naprawimy to jak najszybciej. Obiecujemy!” – bądźmy ludźmi. To zawsze działa.
A, że pod spodem sypiemy sobie do skrzynek kolegów liniami z jakiegoś loga, to spoko. Byle na głowę z tym użytkownikowi nie wchodzić.
Unikajmy opowiadania o bazach danych, API, tokenach, sesjach i tym podobnych rzeczac – używajmy terminów, które można zrozumieć bez wykształcenia w IT. Oczywiście komunikując się z użytkownikami końcowymi, a nie z kolegami i koleżankami w dziale. Prosta reguła:
Ma wyjść do ludzi – musi brzmieć po ludzku.
3: Upewnienie się, że systemu można używać z klawiatury
W ten sposób zadbasz o podstawy dostępności. Pro-tip: większość fajnych usprawnień, które możesz wprowadzić do swojej praktyki by ucieszyć klientów i użytkowników będzie dotyczyć właśnie dostępności i podstawowej użyteczności. Coraz więcej osób używających ułatwień dostępu korzysta z owoców naszej pracy. Nie trzeba od razu być niewidomym albo nie mieć nogi – technologie dostępu to także klawiatura albo mysz. Wielu programistów bardzo szybko śmiga po klawiaturze, a więc upewnienie się o tym, że przez stronę czy aplikację można przejść za pomocą klawisza TAB (na komputerze, oczywiście) zaowocuje dużym zadowoleniem wielu ludzi. Ludzie = klienci. Klienci zadowoleni to… Wiadomo. Warto. Zbyt wiele w internecie rozwiązań, do których wciąż potrzebna jest mysz. Jeśli Chcesz upewnić się, że to, co zrobiłeś (lub zrobiłaś) działa, jak należy, przeskocz szybko po elementach na stronie za pomocą TAB. I już. Poczytaj też o htmlowym „tab order”. To dość proste i logiczne, a zmiana może czynić cuda.
4: Zadbanie o przejrzyste zasady bezpieczeństwa
Bezpieczeństwo w sieci jest bardzo ważne – i, choć mamy coraz bardziej wyrafinowane metody upewniania się, że wszystko działa tak bezpiecznie, jak należy – to często odbywa się to kosztem potwornego obciążenia umysłów użytkowników końcowych. Czyli klientów, którzy płacą za nasze pączki. Co dzieje się po stronie serwera to jedna rzecz, ale to, jakiej złożoności haseł wymagamy, czy też ile razy bezdusznie każemy klikać we „wszystkie rowery na zdjęciu” to sprawa niezwykle ważna. „Do the hard work to make it simple” – warto się zmęczyć po to, żeby człowiek na końcu kija nie musiał zapamiętywać „&7`111_frgHX” i mógł zadowolić się „jedzie-ci0tka-na-r0w3rze!”. Albo mógł po prostu wprowadzić kod z smsa. Ty Jesteś specem – zrób tak, żeby było prosto, a solidnie, a na pewno nie ominie Cię nagroda.
Jeśli masz problem z przełknięciem tej guli goryczy, pomyśl o swojej mamie, używającej komputera. Weź pod uwagę, że żyjemy w starzejącym się społeczeństwie. Musimy zacząć myśleć o zmniejszaniu ciśnienia na banię.
5: Wykazanie chęci do współpracy z działami UX
Dlaczego warto?
- UXi wiedzą, albo przynajmniej powinni, jakie prawdziwe problemy mają użytkownicy produktu czy usługi – i są w stanie pomóc Ci w dobraniu najlepszego rozwiązania. Ty pomożesz od strony technologicznej, oni – behawioralnej – i spotkacie się w środku. Miód!
- UXi chcą nauczyć się podstaw Twojego technicznego języka. Mów do nich spokojnie. Słuchaj ich pytań i zachęcaj do ich zadawania. Zyskasz sobie potężnych sojuszników w walce o święty spokój. Im bardziej zadowoleni użytkownicy, tym spokój większy. Sprawdzone. Poza tym, dowiesz się, że oni też wiedzą o ciekawych rzeczach. Obiecuję!
- UXi pokażą Ci, jak to, co robisz, jest używane na co dzień. Da Ci to masę świetnych pomysłów i pokaże, w co nie ma sensu inwestować czasu. Będzie go więcej na robienie fajnych rzeczy.
- UXi znają się na dostępności i potrafią pomóc Ci w miejscach, które przez przypadek – i bez wysiłku – możesz obsadzić potwornymi minami godzącymi w tych, którzy mają inne potrzeby, niż Ty i ja. A przecież chodzi o to, żebyśmy tak globalnie, planetarnie, byli coraz milsi dla siebie, a nie coraz bardziej kutafońscy, no nie?
6: Bonus — posłuchaj podcastu!
Opowiadam w nim o tym, czym UX jest i nie jest, o tym, dlaczego jest to zagadnienie ważne dla programistów i o paru innych ciekawych rzeczach. A Maciej zadaje mądre pytania. Polecam! Posłuchaj nagrania na Devstyle.pl.
Te pięć rzeczy możesz zrobić już teraz.
Internet pełen jest informacji o tym, jak to zrobić. Ostatnio wyszła na przykład nowa książka Heydona Pickeringa, który pisze o dostępności dla developerów. Bardzo spoczko. Można też poczytać o tych wszystkich wygibasach na Smashing Magazine, albo sprawdzić linki, które podałem w maciejowym podcaście.
Programiści – jesteście motorem napędowym Internetu. W Was drzemie ta prawdziwa, sprawcza moc. Z Waszą pomocą możemy zrobić tak, żeby wszystkim żyło się lepiej.
To już czas! Nie czekaj, zacznij od dziś. Yeah!
Dodaj komentarz