Ux jest bolesne: jak nauczyliśmy się projektowac dla korporacji

Każda porażka prowadzi do ulepszen: opowiedzieliśmy, jak zwiększyliśmy zespoł projektowy z 5 do 25 osob i dostosowaliśmy procesy do obsługi dużych projektow.

Kiedy masz w zespole pięc osob i realizujesz małe projekty, nie ma problemow z procesami: wszyscy są widoczni, wszyscy siedzą przy tym samym stole i można pamiętac o zadaniach.

Ale w jednej chwili zmieniliśmy koncepcję: połączyliśmy dwie firmy w jedną, zrezygnowaliśmy z developmentu, zaczęliśmy zajmowac się tylko projektowaniem i badaniami UX, rozrośliśmy się drastycznie do 25 pracownikow. A kiedy podjęliśmy się realizacji dużych projektow, zarowno my, jak i klient zaczęliśmy popełniac błędy. Okazuje się, że aby pracowac jako duży zespoł nad zadaniami na dużą skalę, trzeba stale ewoluowac i usprawniac swoje procesy.

Ten tekst jest oparty na naszych doświadczeniach i błędach, ktore doprowadziły do ulepszen. W rezultacie, w Angry nauczyliśmy się szybko godzic pomysły, udowadniac klientowi nasze rozwiązania i unikac przechodzenia przez dziewięc kręgow piekła, jak to ma miejsce, gdy jest się outsourcerem i pracuje się przy dużych projektach.

Dzielenie się wnioskami: są one przydatne dla osob zajmujących się projektowaniem UX, pracujących z dużymi firmami, szukających pracy z nami lub dla nas.

Jak zmieniliśmy procesy, aby pracowac z korporacjami

W każdej dziedzinie projektant to nie tylko osoba, ktora rysuje lub sprawia, że rzeczy są piękne, szczegolnie w usługach finansowych. Przemyślimy wszystkie szczegoły interakcji z produktem, od logiki i procesow biznesowych po teksty, ktore wchodzą w interakcję z produktem (SMS, push, email). I w pełni odpowiedzialny za wynik koncowy.

Aby było to opłacalne, trzeba manewrowac pomiędzy ograniczeniami technicznymi, potrzebami użytkownikow i wymaganiami biznesowymi. Po to właśnie są jasne zasady.

Nie zatrudniaj ludzi bez analitycznego umysłu

W projektowaniu UX nie sprawdza się podejście "bez wnikania": "Jestem menedżerem, nie obchodzi mnie, czym zarządzam" lub "Jestem sprzedawcą: mogę prowadzic garaż lub rakietę". Mieliśmy nieszczęście doświadczyc tego podczas naszej ekspansji: zatrudnialiśmy obiecujących, ale niedoświadczonych ludzi, ktorzy co 20 minut przychodzili z pytaniami i wykonywali zadania zbyt długo lub zbyt powierzchownie. W rezultacie nasza firma straciła 7 milionow rubli i cztery miesiące na rekrutację.

Przekonaliśmy się na własnej skorze, że aby człowiek mogł zacząc rozumiec to, co projektuje (a mamy tu fintech i banki), musi miec analityczny umysł i prog wejścia wynoszący od czterech do sześciu miesięcy. Wierzymy, że ta zasada sprawdza się w każdym złożonym obszarze.

Tworzenie puli pytan na początek

Ważne jest, aby od razu uzgodnic z klientem, kto jest odpowiedzialny za co, w celu stworzenia przejrzystego i efektywnego procesu. Na brzegu projektu ciągle coś wymyślamy:

  • Czy istnieją jakieś wymagania techniczne, ktore muszą byc ściśle przestrzegane?? Ważne jest, aby przemyślec logikę działania usługi: w niektorych bankach robimy projekty od podstaw i jest pełna dowolnośc (ograniczona jedynie postępem technicznym w danej dziedzinie), a inne banki nie planują zmian w systemach zaplecza i musimy to wziąc pod uwagę.
  • Kim jest docelowa publicznośc? Projektujemy banki i usługi finansowe, ale każdy z nich ma swoją własną strategię i grupę odbiorcow: niektore stawiają bardziej na digital, a inne kierują się w stronę wąskiego segmentu i tworzą produkt dla niezaawansowanych użytkownikow. Budujemy koncepcję w oparciu o grupę docelową: myślimy o wizualizacjach, UX i ilustracjach, aby dopasowac je do odbiorcow i ich percepcji.
  • Czy istnieje zestaw do projektowania? Dowiedz się, czy musisz się do niego sztywno stosowac, czy możesz stworzyc swoj własny styl i własny kotek do projektu.

Doświadczenie, ktore nauczyło nas.

Jeden z naszych największych projektow może nie wyjśc w oryginalnej koncepcji projektowej, ponieważ wyjęliśmy czcionkę z księgi marki. Broniliśmy i zatwierdzaliśmy wszystko na początku, trzy razy odpierając koncepcję i pokonując bariery klientow, a za czwartym razem wewnętrzny zespoł produktowy zdecydował się nie walczyc z zespołem marki.

Pięc miesięcy pracy, mnostwo polityki i rozmow, kilka obron, a na koniec klient jest już po prostu zmęczony wewnętrznym naciąganiem tego rozwiązania – teraz projekt może wyjśc z natywną czcionką z brandbooka, co czyni rozwiązanie projektowe kompletnym dnem.

Wielkie firmy – wielka polityka

Pracując z korporacjami, musisz wiedziec, z kim rozmawiac, jak przekonywac i jakich danych używac w komunikacji z każdym uczestnikiem. Na przykład, w przypadku prawnikow i ochrony, ważne jest, aby wiedziec więcej niż oni – nie tylko co robi praktyka i konkurencja, ale jakie jest prawo i jak jest ono napisane. Dlatego w zespole musi byc doświadczona osoba, ktora wie, jak rozmawiac i budowac relacje z klientem: taką rolę pełni nasz PM.

Uzgadnianie od razu, kto ma ostatnie słowo

Klient lubi mowic: "Ja to robię, ale tego nie rozumiem" – ale to jest klasyczny błąd "projektowania dla siebie". Cały zespoł projektowy (zarowno klient jak i my) jest zanurzony w terenie, nasze postrzeganie jest drastycznie rożne od doświadczenia użytkownika.

Więc teraz, zanim zaczniemy, od razu zaznaczamy, że UX jest obszarem, na ktorym można całkowicie polegac, ale częśc wizualna jest dyskusyjna. I zamiast spierac się o gusta, przeprowadzamy test użyteczności, ktory sprawdza wszystkie rozwiązania dla CA.

Wyznacz ostateczne terminy edycji

Początkowo pracowaliśmy w sprintach – w środy pokazywaliśmy status wszystkich zadan i otrzymywaliśmy uwagi od klienta. To prawda, że nie było żadnego terminu na zmiany: pozostawiono je włączone przez cały czas.

Dodawano ludzi i zespoły – edycje przychodziły wciąż na nowo. Mogły się one powtarzac, byc sprzeczne lub wykluczac się, a czasami były dodawane po wykonaniu zadania.

Kiedyś mieliśmy trzy tygodnie z rzędu edycji tego samego zadania: 5 projektantow 12 razy w tygodniu zmieniających rożne drobne rzeczy. To było jak chinska tortura: woda spływała po wierzchu więźnia, kropla po kropli. Wyczerpujący.

Im większa firma klienta, tym większy niekontrolowany chaos. Wymyśliliśmy więc system: pokazujemy projekt w środę, a w piątek rano zajmujemy się jego edycją. Klient ma dwa dni na zebranie wszystkiego i znalezienie wspolnego rozwiązania. Terminy są zdyscyplinowane, a strona klienta jest odpowiedzialna za uwagi od wszystkich zespołow. W ten sposob praca przebiega szybciej, a ludzie nie wypalają się na projekcie.

Stosowanie list kontrolnych do zadan wewnętrznych

Mamy listy kontrolne z zasadami pracy – pomagają one projektantom poruszac się w dobrym tempie. Zapisaliśmy je w czterech blokach:

  • Tekst: jak pisac i korektę w interfejsach – dzięki Ilyahov za udostępnienie treści.
  • Typografia – najważniejsze szczegoły dotyczące symboli, łącznikow, skrotow itp.
  • Projektowanie – praca z zestawami atomowymi, komponentami, ogranicznikami.
  • Projektowanie – lista kontrolna jak powinien wyglądac prototyp i czego w nim nie zgubic.

To są podstawy – trzeba je spisac, żeby liderzy projektu nie tracili czasu, a chłopaki w zespole mogli się nawzajem sprawdzac.

Walidacja rozwiązan przez zespoł projektowy

Aby szybciej znajdowac błędy, wykonujemy trzyetapowy przegląd z zespołem projektowym, aby sprawdzic, czy wszystko jest w porządku – schemat danych, logika, projekt, komunikacja.

Do tej koncepcji doszliśmy rownież przez błędy – duże zadanie może trwac tydzien lub dwa, a jeśli projektant początkowo pojdzie złą drogą, straci czas i będzie musiał zaczynac wszystko od nowa.

Tak więc, każde zadanie (epopeja) przechodzi przez trzy etapy przeglądu:

  • Opracowanie schematu infoschematu lub procesu biznesowego – projektując proces projektant musi rozumiec jego logikę i pełny zestaw danych: np. KPP ma dziewięc cyfr, a adresy są pobierane z katalogu CLADR. Wszystkie szczegoły i ograniczenia zapisujemy wcześniej, więc nie musimy się o nie martwic podczas projektowania logiki.
  • Rysowanie podstawowych ekranow. Projektant przygotowuje podstawowe screeny i broni pomysłu przed zespołem. Już widzisz logikę i możesz ją szybko naprawic bez konieczności przekopywania się przez 70 innych ekranow.

  • Sprawdź wszystkie stany wszystkich elementow: zaprojektuj i sprawdź skrypty od logowania do wylogowania: tak jakby bardzo skrupulatny użytkownik postanowił skonfigurowac i wypełnic wszystko, do czego może dotrzec. Nazywamy tę metaforę "user-asshole". Pomaga oswoic się z postacią i szczegołowo sprawdzic logikę, scenariusze i teksty.

Przegląd ten oszczędza czas i pomaga skorygowac opoźnienie, jeśli tak się stanie. Zwiększa to rownież odpowiedzialnośc i utrzymuje zespoł razem.

Piszemy schemat komunikacji dla produktu

Prawidłowy tekst to połowa sukcesu – nadaje ton produktowi. Piszemy teksty dla wszystkich kanałow interakcji z produktem (push, SMS, mail, chat), ponieważ wiemy, że 70% wszystkich błędow w testach użyteczności wynika z niejednoznacznych sformułowan.

I znow na ratunek przychodzi Illyakhov i badania: mamy system tekstowej nauki w interfejsach z wykładami i zadaniami domowymi, a dzięki dużej bazie wiedzy z badan UX wiemy, jakim językiem posługują się użytkownicy, co i w jakim momencie jest dla nich ważne.

Tekst jest Twoim językiem komunikacji, decyduje o tym, jak użytkownik będzie postrzegał firmę i produkt.

Jeśli powiesz: "Hej, człowieku, uczyn swoje konto bezpieczniejszym", a następnie podasz błąd: "Uwierzytelnianie nie powiodło się", użytkownik dozna dysonansu poznawczego.

Tak się dzieje, gdy projektant nie przemyśli wszystkich stanow – alternatyw, negatywow, wszystkich błędow i tekstow w produkcie. A deweloper sam zamyka te dziury.

Opisac funkcjonalnośc

To, czego nie można pokazac w projekcie lub animacji, należy opisac. W komentarzach do poszczegolnych ekranow mowimy więc: co tu się stało, skąd pochodzą dane (zewnętrzne katalogi), jak działa sortowanie czy filtrowanie. Czasami używamy liczb i doświadczen użytkownikow, aby argumentowac, dlaczego zrobiliśmy to, co zrobiliśmy, jeśli rozwiązanie jest nietypowe dla danej dziedziny.

W efekcie w dwa tygodnie po uruchomieniu projektu oddajemy Panstwu prototypy, ktore pomagają analitykom technicznym zacząc pisac TOR do rozwoju, a programistom tworzyc procesy back-endowe.

Pozwala to na rozpoczęcie prac już w trzecim lub czwartym tygodniu projektu, zamiast czekac trzy lub cztery miesiące na jego ukonczenie.

Włączenie badan do projektu

Kiedyś sprzedawaliśmy ankiety jako dodatkową usługę do projektu, ale potem zaczęliśmy włączac do projektu po prostu test użyteczności lub pełne badanie. Nie zrobię tego bez nich.

Test użyteczności projektu trwa miesiąc, ale w pełni uzasadnia jego czas: nawet z naszym doświadczeniem są rzeczy krytyczne.

Badanie zapotrzebowania na nową usługę rownież trwa miesiąc, ale całkowicie eliminuje pytanie, czy użytkownik potrzebuje takiego produktu.

Nasz ulubiony przykład dotyczy kontrastu kolorow i tekstow: użytkownicy często nie widzą subtelnej szarej czcionki, ktorą tak kochają projektanci. Zawsze jest problem, że ludzie nie rozumieją niektorych tekstow – nie jest to krytyczne, ale można to poprawic i uprościc.

Po testach użyteczności wprowadzamy zmiany i pokazujemy klientowi, co znaleźliśmy i zmieniliśmy, jakie praktyki okazały się skuteczne i jak użytkownicy postrzegają produkt. W ten sposob praca jest poparta liczbami, faktami, argumentami i nie tracimy czasu na kłotnie. Projektanci, ktorzy zaprojektowali produkt, są obecni podczas testow i otrzymują bezpośrednie informacje zwrotne na temat swojej pracy.

Gromadząc wiedzę i dane na temat doświadczen użytkownikow, edukujemy siebie i edukujemy klientow.

Sammari: o czym należy pamiętac, pracując z dużymi klientami

  • Wielkie firmy – wielka polityka. Zespoł powinien miec doświadczoną osobę, ktora wie, z kim rozmawiac, jak przekonywac i jakich danych używac w komunikacji z każdym uczestnikiem. Bez tych umiejętności nie jest możliwa wspołpraca z korporacjami.
  • Uzgodnienia na lądzie – co do procesow i obowiązkow po każdej ze stron, obszarow odpowiedzialności i podejmowania decyzji. Na początek przygotuj pulę pytan, aby nie pominąc ważnych szczegołow.
  • Sporządzanie list kontrolnych jakości – aby zespoł mogł się wzajemnie sprawdzac i nie tracic czasu głownego projektanta na naprawianie typowych błędow.
  • Naucz się uzasadniac, nie naginaj decyzji – najpierw zwrocą się do Ciebie z prośbą o dobrą obsługę, a potem powiedzą "to nie tak pracuję". Jeśli zgodzisz się wykonac usługę dla klienta, a nie dla użytkownika, otrzymasz niewygodny produkt. A więc argumentuj: liczby, wiedza i badania użyteczności pomogą.
  • Pamiętaj, że jesteś w tej samej drużynie – to nie tylko Twoja odpowiedzialnośc, to także odpowiedzialnośc klienta. A linia czasu jest tak samo dla ciebie, jak i dla niego. Aby więc nie tracic czasu na gusta i opinie, należy ustalic czas na poprawki i ustalic prawo ostateczności.

#użytecznośc

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *