Jeśli uważasz, że dobry projekt jest drogi, powinieneś przyjrzeć się kosztom złego projektu.
Dr Ralf Speth, dyrektor generalny Jaguar Land Rover
W ciągu ostatniej dekady doświadczenie użytkownika stało się prawdziwym czynnikiem odróżniającym dobre aplikacje od świetnych.
Techniczna strona tworzenia oprogramowania jest w pewnym stopniu rozwiązanym problemem. Prawdziwe możliwości osiągnięcia ponadprzeciętnego sukcesu dzięki produktom programistycznym tkwią w UX. Kolejna przełomowa aplikacja będzie mieć interfejs, z którego będzie można korzystać natychmiast. Doprowadziło to do opartego na badaniach, skoncentrowanego na UX podejścia do tworzenia produktów.
Rezultaty tego skupienia mówią same za siebie.
Na przykład każdy dolar zainwestowany w UX generuje 100 dolarów zwrotu, zgodnie z raportem Forrester Research. Ponadto badanie pokazuje, że w okresie 10 lat wyniki finansowe firm kierujących się projektowaniem przewyższają wyniki indeksu S&P o 219%.
Istnieje również legendarna historia o tym, jak samo zmienienie tekstu na jednym przycisku przyniosło firmie e-commerce 300 milionów dolarów dodatkowej sprzedaży w ciągu jednego roku!
Jednak pomimo całego tego rozgłosu i zamieszania na każdą aplikację oferującą świetne doświadczenie użytkownika przypada kilka takich, którym pod tym względem wiele brakuje lub które są pod tym względem bardzo słabe. Te najgorsze łatwo rozpoznać — sprawiają, że masz ochotę wybić dziurę w ekranie laptopa albo wyrzucić urządzenie mobilne przez okno. Darwin zajmuje się takimi aplikacjami.
Prawdziwym wyzwaniem są aplikacje z całkiem niezłym UX. To właśnie te doświadczenia będące przysłowiową „zadrą w umyśle”, w przypadku których za nic nie możesz zrozumieć, dlaczego ich nie lubisz!
Słyszę, jak mówisz: „Wszystko to wiemy; czytam przecież The QA Lead, więc co to ma wspólnego ze mną?” Już do tego zmierzam.
Znaczenie UX
Na początku mojej pracy przy zarządzaniu zespołami inżynieryjnymi pracowaliśmy nad dużym projektem rozwiązania programistycznego dla jednego z naszych klientów. Była to część większej strategii transformacji cyfrowej wdrażanej u tego klienta. Był to typowy zespół inżynieryjny, składający się głównie z programistów i inżynierów QA, pracujący w Scrumie w ramach 2-tygodniowych sprintów.
Istniał niewielki zespół UX, ale w większości był współdzielony między projektami. Zazwyczaj osoby zajmujące się UX dołączały do codziennych spotkań zespołu na początkowych etapach projektu, ale gdy klient zatwierdził projekt wizualny, przekazywały wszystkie szablony projektu wizualnego oraz przepływy, a następnie przechodziły do pracy nad innymi projektami.
Podczas pierwszego pokazu sprintu klient wydawał się przede wszystkim zaniepokojony tym, że projekt wizualny i interfejs użytkownika nie odpowiadały dokładnie szablonom projektu. Występowała również rozbieżność między zaproponowaną funkcjonalnością a tym, co faktycznie zaimplementowano.
Rozbieżność nie była duża, ale niezależnie od tego, jak bardzo próbowaliśmy zapewnić klienta, że elementy UX zostaną dopracowane podczas jednego z późniejszych sprintów, jego mowa ciała pokazywała, że nie był z tego zadowolony.
Na szczęście lider QA w naszym zespole zabrał głos, powiedział, że była to anomalia i że to się więcej nie powtórzy. A potem zrobiła coś niezwykłego. Pozwólcie, że to tutaj przedstawię:
- Wzięła na siebie odświeżenie wiedzy na temat UX poprzez intensywną lekturę.
- Następnie sama przeprowadziła podstawowy heurystyczny przegląd UX dostarczonej funkcjonalności, porozmawiała z zespołem UX i w razie potrzeby uzyskała jego pomoc.
- Utworzyła nowe zadania w JIRA, aby z perspektywy UX naprawić rozbieżność między tym, co obiecano, a tym, co dostarczono.
- Umówiła rozmowę z naszym dyrektorem UX i uzyskała jego zgodę na wprowadzenie nowego procesu, w ramach którego aspekty wizualne aplikacji byłyby poprawiane podczas każdego sprintu, a nie dopiero na końcu.
- Na koniec zadbała również o to, aby nasi specjaliści QA poznali podstawy UX, dzięki czemu mogli wychwytywać rażące problemy i pomagać zespołowi rozwiązywać je na wczesnym etapie.
Wisienka na torcie? Podczas kolejnego pokazu sprintu właściciel produktu/klient był cały w uśmiechach, a po kilku miesiącach nasza liderka QA awansowała na stanowisko kierownika QA! 😉
Romantyczne a klasyczne spojrzenie na rzeczywistość
Cały ten epizod skłonił mnie do refleksji nad ogromną różnicą między tym, jak my, inżynierowie, postrzegamy aplikację, a tym, jak postrzegają ją klienci i użytkownicy. Robert Pirsig w swojej przełomowej książce Zen i sztuka konserwacji motocykla mówi o dwóch sposobach postrzegania rzeczywistości: klasycznym i romantycznym.
Według Pirsiga osoby, których dominująca perspektywa jest romantyczna, postrzegają rzeczy i oceniają je na podstawie tego, jak wyglądają. Interesuje je przede wszystkim to, jakie rzeczy są, i nie obchodzi ich, jak działają — ukryty za nimi porządek. To artystyczna połowa podziału na sztukę i naukę.
Z drugiej strony my, inżynierowie & naukowcy, wyznajemy pogląd klasyczny, zgodnie z którym piękno tkwi w mechanizmach leżących u podstaw zewnętrznej formy. Inżynierowie potrafią dostrzec piękno w kodzie Pythona lub pod maską samochodu, co osobom reprezentującym stronę romantyczną wydaje się brzydkie.
Jak wszystko inne, również to oczywiście nie jest klasyfikacją binarną, lecz kontinuum, przy czym większość z nas zdecydowanie preferuje jedną z perspektyw.
Ten sposób klasyfikowania świata ma kilka interesujących konsekwencji:
1. Dominująca perspektywa większości osób jest domyślnie albo klasyczna, albo romantyczna, a nie jednocześnie obie.
2. Osoby — pomyśl o klientach, wewnętrznych lub zewnętrznych — o perspektywie romantycznej zdecydowanie przewyższają liczebnie osoby o perspektywie klasycznej. Jeśli kiedykolwiek musiałeś pełnić rolę wsparcia technicznego dla rodziny i znajomych, wiesz, o czym mówię!
3. Bardzo niewiele osób potrafi przełączać się między tymi trybami, a nawet dla nich jest to czynność wymagająca wysiłku.
4. Rzeczywistość = klasyczne + romantyczne. Te perspektywy wzajemnie się nie wykluczają. Obie są niezbędnymi aspektami całości. Piękno jest funkcjonalne. Funkcja może być piękna.
Weźmy na przykład kwiaty. Mają tak wspaniałe wzory, że wydają się pozbawione jakiejkolwiek funkcji. Jednak piękno, które dostrzegamy w kwiatach, ma strukturę opartą na matematyce: ciąg Fibonacciego rządzi strukturą i wzorami, które widzimy w kwiatach. Struktura i eteryczne piękno idą w naturze ze sobą w parze.
I nie chodzi tylko o piękno. Układ nasion w słoneczniku jest zgodny z ciągiem Fibonacciego i złotym podziałem, dzięki czemu w kwiatostanie mieści się maksymalna możliwa liczba nasion. Te same zasady dotyczą inżynierii i doświadczeń użytkownika.
To wreszcie prowadzi nas do sedna tego artykułu: osoby zajmujące się inżynierią jakości są idealnie przygotowane do wykorzystania obu tych pozornie konkurujących ze sobą perspektyw.
Have an account? Log In
Rola zapewnienia jakości oprogramowania w UX / użyteczności
Jako specjalista ds. testowania masz znacznie większe doświadczenie z interfejsami niż przeciętny programista lub użytkownik.
Rygorystycznie i wielokrotnie (aż do znudzenia!) testowałeś tak wiele aplikacji, że być może osiągnąłeś poziom myślenia wyższego rzędu, czyli myślenia 4D, jeśli chodzi o UX — jak ten przysłowiowy arcymistrz szachowy, który myśli pozycjami, w przeciwieństwie do mnie, który z trudem ustala, którą figurę przesunąć jako następną! ;-)
Dlatego pomimo ogromnego zwrotu w kierunku automatyzacji — bez wątpienia świetnego kierunku — można znaleźć argumenty za pewną ilością testów manualnych. W końcu jeśli z aplikacji mają korzystać ludzie, warto uwzględnić ludzką perspektywę w testowaniu.
Jak przeprowadzić przegląd UX / użyteczności jako inżynier testów
Jeśli zapewnienie jakości ma uwzględniać UX, musi rozpocząć się równolegle z etapem projektowania, czyli na początku cyklu życia. Oto kroki, które możesz wykonać, aby uwzględnić przegląd UX w testach i stać się polimatą QA!
Heurystyki użyteczności w projektowaniu interfejsu użytkownika
Zapoznaj się z 10 ogólnymi zasadami projektowania interakcji autorstwa Jakoba Nielsena. Ten zestaw wytycznych stanowi wiarygodny punkt odniesienia dla każdego przeglądu użyteczności. Uwzględnij te zasady w rozmowach z zespołem UX, a także w planie testów. Możesz również sprawdzić dowolną liczbę podstawowych kursów dotyczących użyteczności i projektowania UX.
Poznaj zasady dostępności
Być może w przeszłości testowanie dostępności było częścią Twojego planu testów, ale zrozumienie zasad dostępności — postrzegalności, funkcjonalności, zrozumiałości i solidności — wyposaży Cię w umiejętność dostrzegania tego, co inni mogą przeoczyć.
Zespół UX to Twoje nowe miejsce
Nie bądź obcy: poznaj zespół UX pracujący nad projektem. Współpracuj z nim. Udostępnij mu swój plan testów i poproś o opinię na temat tego, co możesz uwzględnić z perspektywy UX.
Korzyści z tej interakcji są obustronne, ponieważ Twój plan testów zapewni zespołowi projektowemu wgląd w wykonalność proponowanych przez niego funkcji. Jako lider QA musisz utrzymywać z zespołem UX równie bliską współpracę jak z programistami.
Uwzględnij analitykę w swoim planie testów
Analityka użytkowników produktu, który testujesz, to kopalnia informacji dla testerów. Analityka może pomóc Ci zidentyfikować obszary ryzyka i zachowania użytkowników. To z kolei może pomóc Ci jak najwcześniej w cyklu życia produktu zidentyfikować i ustalić priorytety poprawek.
Przesuwaj testowanie w lewo, dopóki się da
Produkt, który testujesz, przypomina dziecko. Musisz zadbać o to, aby otrzymał potrzebną pomoc już od momentu jego powstania. Zacznij od samego początku.
Przed rozpoczęciem prac programistycznych
Testuj na etapie projektowania, gdy tylko będzie gotowy prototyp. Wykorzystaj swoje doświadczenie z aplikacjami oraz wiedzę na temat zasad użyteczności i wytycznych dotyczących dostępności, aby sprawdzić, czy należy wprowadzić jakieś zmiany, ZANIM produkt przejdzie do etapu programowania.
Jeśli QA nie jest jeszcze częścią fazy projektowania, w miarę możliwości doprowadź do jego włączenia.
More Articles
Ukierunkowane testy ręczne
W ramach testów ręcznych przejdź przez całe doświadczenie korzystania z produktu — od początku do końca. Skup się na zadawaniu właściwych pytań, myśląc zarówno jak użytkownik, jak i inżynier QA.
Zacznij od spojrzenia z dystansu i przyjrzenia się produktowi z szerszej perspektywy. Czy korzystanie z niego sprawia Ci przyjemność?
Następnie przyjrzyj mu się dokładniej. Czy łatwo się z niego korzysta? Czy przepływy są oczywiste i intuicyjne? Czy są uciążliwe i powolne? Czy występują nakładanie się lub powielanie działań, które mogą irytować użytkownika? Czy projekt jest użyteczny na ekranach o różnych rozmiarach?
Na koniec
Przyszłość pracy należy do osób posiadających wiele uzupełniających się zestawów umiejętności, które są niemal niemożliwe do przejęcia przez maszyny (ale zajrzyj do mojego artykułu o AI w automatyzacji testów, aby przekonać się, co potrafią).
Stanie się wszechstronnym specjalistą QA posiadającym umiejętności UX może być świetnym sposobem na wykorzystanie swoich naturalnych zdolności i doświadczenia, dodanie dużej wartości bez wkładania zbyt dużego wysiłku ani zbytniego oddalania się od głównego obszaru działania.
Czy to coś, co Cię ekscytuje? A może uważasz, że UX jest tylko pośrednio związany z tą dziedziną? Daj mi znać w komentarzach poniżej.
Jeśli chcesz dowiedzieć się więcej, tutaj znajdziesz podcast, którego możesz przeczytać/posłuchać: JAK OPROGRAMOWANIE OPEN SOURCE UPRASZCZA INTEGRACJĘ W INŻYNIERII AUTOMATYZACJI (Z JAMESEM WALKEREM I SANJAYEM KUMAREM)