Projektowanie usług, czyli przyszłość UX — Neil Collman, service designer

Projektowanie usług, czyli przyszłość UX — Neil Collman, service designer

Neil Collman pracuje jako Principal Experience Designer w jednej z najlepszych agencji service design na brytyjskim rynku — Nile. Od lat zajmuje się zagadnieniami związanymi z projektowaniem usług cyfrowych. Po studiach na kierunku matematyki na uniwersytecie w Bristolu pracował jako projektant UX w IBM. Przeszedł przez etap rozkręcenia własnego start-upu, a także działał jako freelancer. Dzisiaj prowadzi projekty dla dużych instytucji finansowych.

Pracowałem z Neilem przez kilka lat. Był nawet moim szefem (o czym pewnie chce zapomnieć). Nauczyłem się od niego bardzo dużo. Zrealizowaliśmy kilka dobrych projektów dla takich marek jak RBS, Hiscox i Scottish Widows. Spotykamy się często, żeby nad piwkiem i hamburgerem porozmawiać o pracy i muzyce. Ponieważ ostatnio w oko wpadła mi prezentacja Neila z UX London, postanowiłem porozmawiać z moim przyjacielem o service design. Co to jest? Dokąd zmierza? Jaka jest przyszłość UX? Jakie cechy posiada dobry projektant service design?

Panie i Panowie, Neil Collman.

Wojtek: Neil, czy możesz pokrótce opisać jak doszło do tego, że zająłeś się service design?

Neil: Jasne. Moja podróż zaczęła się tak, jak dla wielu innych: z nadejściem iPhone’a i iPada. Wiele dużych firm zorientowało się wtedy, że rynek zmienił się diametralnie w ciągu paru miesięcy. Stało się tak dlatego, że organizacje straciły całkowitą kontrolę nad zachowaniem klientów. Zamiast używać komputerów w domu, użytkownicy zaczęli korzystać z internetu w biegu, z poziomu sofy, w autobusie; w różnych, nietypowych do tej pory, sytuacjach. Zmienił się kontekst. Na przykład, do tej pory niewyobrażalne było zaoferowanie zakupu biletów na samolot kiedy znajdowaliśmy się poza domem (chyba, że ktoś chciał robić to przez telefon). I tu zaczęły się dla wielu firm schody: nowe podejście do korzystania z technologii oznaczało, że jako projektanci nie mogliśmy przejmować się tylko interfejsem, ale także tym, co dzieje się poza nim. Nagle musieliśmy naprawdę zainteresować się resztą doświadczenia. Wyjść za ekran aby projektować produkty w pełni funkcjonalne. Być może użytkownik jest spóźniony, albo musi pokonać jakąś barierę, a może musi rozmawiać, aby pokonać kolejny etap podróży, a my powinniśmy umożliwić mu dialog? Tak więc, jak tylko tego rodzaju myślenie zawitało pod korporacyjną strzechą — my zorientowaliśmy się, że typowy toolbox naprawdę musi się zmienić.

W: I zaczęliśmy upychać kamery nagrywające to, co widać na ekranie na iPhone’ach, mocując je na rzepy, klejem i taśmą, ha ha. Nikt nie może powiedzieć, że nie próbowaliśmy…

N: Dokładnie. Ale to tylko jedna strona medalu; praktyka i metody. Klienci natomiast połapali się w tym, że potrzebują zupełnie odmiennego podejścia do tematu. Musieliśmy pomóc im w rozważaniach na temat strategii: jak podejść do projektowania na tablet? Albo smartfon? Jaką strategię obrać w podejściu multichannel? To właśnie od tego dla wielu projektantów zaczęła się rozmowa o service design (SD — będę od tej pory używał tego właśnie skrótu — przyp. tłum.).

Praca nad moim pierwszym projektem zorientowanym na szerszy SD zaczęła się od tego, że klient szukał sposobu, w jaki jego grupa docelowa mogłaby sama przeprowadzać większość podstawowych interakcji z organizacją — czyli pracować w modelu self-service. To magiczne słowo przyciągnęło klienta, nie metody czy jakaś wyższa świadomość. Self-service oznacza w końcu dla firmy spore oszczędności.

W: Myślisz, że na tym etapie wiedzieli już, że brną w SD?

N: Myślę, że zdawali sobie sprawę, że jeżeli o rozwiązanie problemu poproszą typowego UXa to nie otrzymają właściwej pomocy. Nie wiedzieli do końca, co chcieli zrobić, ale podświadomie czuli, że chodzi o coś więcej, niż przyciski i linki. Wiadomo było, że trzeba zaprojektować platformę obsługi finansowej dla klienta końcowego, a nie tylko wyspecjalizowany interfejs. Oczywiście zaprojektowaliśmy fantastyczny prototyp, bazując na rozumieniu zidentyfikowanych potrzeb klientów i organizacji. Byłem z niego naprawdę dumny. Najciekawsze jednak było to, że kiedy zapytaliśmy naszego zleceniodawcę o to, co stanowiło o sile projektu, usłyszeliśmy, iż najważniejszy z punktu widzenia klienta był proces, który zmienił myślenie ze zorientowanego na produkt na takie, w którym można było skupić się na usłudze. To otworzyło nam oczy. Zrozumieliśmy, że dotychczas stosowane przez nas metodologie miały taki sam efekt, ale niejako przy okazji — tymczasem myślenie o usłudze od początku wymaga odmiennego podejścia. Jeżeli, na przykład, założymy, iż od początku tworzymy rozwiązanie w systemie co-design, to znaczy, jeżeli klient i końcowi użytkownicy rozwiązują problem razem, to działa to nieporównywalnie lepiej niż jeżeli projektanci zamkną się w swoim pokoju po dokonaniu badań i po tygodniu prac wypłyną z prototypem. Oczywiście, teraz jest to rzecz oczywista, ale dla wielu projektantów i firm wcale taką nie była w 2007 roku. Dla niejednej firmy jest to wciąż nowość… Ale tu właśnie możemy pomóc jako projektanci. Tym właśnie się zajmuję — zamiast projektować cyfrowe interfejsy, jestem moderatorem, enablerem (piwko komuś, kto mi to przetłumaczy — przyp. tłum.), który pracuje z klientem w sposób, dzięki któremu adresuje się dużo szersze założenia całościowego funkcjonowania usługi. To nie oznacza, że znany i lubiany przez nas UX nie ma już sensu, ale oznacza to, że po drodze po prostu wydarza się dużo więcej.

W: Czy nie sądzisz, że tego rodzaju podejście sprawdza się, kiedy pracujemy z klientami dojrzałymi i rozwiniętymi? WIelu z nich nie jest w stanie wspiąć się na ten poziom rozumienia.

N: Niestety, sądzę, że masz rację. W mojej prezentacji na UX London próbowałem zwrócić uwagę na parę rzeczy, które możemy zrobić, aby wyjść poza ramy typowego projektu UX — po to, aby spojrzeć na to, co dzieje się poza ekranem. Na to, jak ludzie przepływają przez cały system usługowy. Wystarczy spojrzeń na to, co dzieje się przed i po nawiązaniu kontaktu z usługą. Ilustrację oferują start-upy; być może mogą przekonać użytkownika do skorzystania ze swojego produktu, ale czy myślą o tym, co będzie się działo za, powiedzmy, sześć miesięcy? Jak będzie wyglądała cała usługa po tym czasie? Co stanie się z klientem? Być może framework, który jest potrzebny by się temu przyjrzeć nie istnieje? Myślę, że każdy service designer powinien zadawać sobie te pytania. Jednak nawet jako projektant UX wiesz zapewne, że nie ważne, jak dobry jest twój produkt — po jakimś czasie ludzie, którzy z niego skorzystali zaczną go opuszczać. Co zrobisz, żeby ich zatrzymać? Jaka będzie twoja strategia na podtrzymanie zainteresowania nie tylko na początku, ale i później?

To jest coś, o czym można zacząć myśleć w dowolnym momencie. To głównie podejście, a nie pojedyncza metoda czy umiejętność. Po prostu, trzeba wybiegać daleko do przodu, czyli rozumieć, że stworzenie dobrego doświadczenia końcowego nie zaczyna się i kończy, kiedy nasz produkt jest gotowy i ląduje w App Store.

W: Dużo tu o strategii. Z własnego doświadczenia wiem, że dokumenty digital strategy, które mają wyznaczać standardy pracy nad usługami, często lądują w szufladzie po to, by nikt na nie nie patrzył. Czy myślisz, że to podejście się zmienia i, zamiast dokumentów, szefowie firm naprawdę oczekują wprowadzania digital strategies w praktyce?

N: Jest różnie. Wielkie firmy często pracują w silosach, dzieląc obowiązki projektowe pomiędzy nieskończoną ilość nieskoordynowanych zespołów. Czy to, co dzieje się pomiędzy użytkownikiem a organizacją w internecie jest wciąż traktowane po macoszemu? Czy istnieje w oddzieleniu od podstawy funkcjonowania firmy? Tak, często tak. Nie raz spotykałem się z ogromnymi podziałami i “głuchym telefonem” pomiędzy, na przykład, zespołami definiującymi value proposition a zespołem projektantów UX czy developerów.

W: Dlaczego tak się dzieje? Myślisz, że chodzi o brak zrozumienia tematu? Czy to coś innego?

N: Firmy często nie radzą sobie z konstruowaniem zespołów, które mają rozwiązywać problemy. Zdarza się również, że zespoły te nie mają narzędzi (umiejętności i technologii — przyp. tłum.), które pozwalają skupić się na wydajnej pracy. Jednym z podstawowych problemów service design jest to, że jeżeli nie uda ci się, jako projektantowi, spowodować, żeby konwersacje i akcje podejmowane w zespole były widoczne na zewnątrz — to poległeś. A do tego potrzeba teamu, który potrafi komunikować się pomiędzy sobą, podczas gdy tych umiejętności nierzadko brakuje. I chodzi o proste rzeczy, na przykład: czy osoba, która próbuje coś przekazać potrafi wyjaśnić to prostym rysunkiem albo diagramem? To brzmi trywialnie, ale widziałem już sytuacje, w której część zespołu odpowiada “tak, wiemy o co tu chodzi”, nie mając tak naprawdę pojęcia, o czym mowa — i zawalając tym samym współpracę. Kolejny problem to to, że sukces często mierzy się różnie pomiędzy zespołami. Na przykład zespół odpowiedzialny za marketing mierzy, jak przebiega sprzedaż, ale zespoły zajmujące się projektowaniem już nie. Tymczasem jedynym sensownym rozwiązaniem jest badanie i ocena tych samych wskaźników dla całej organizacji. W końcu wszyscy kontrybuują do tej samej wizji i sukcesu…

W: Czy podejście do tworzenia produktu zorientowane na technologię, buzzwords i ślepe podążanie za trendami nie jest odpowiedzialne za ten stan? Decyzje projektowe często dokonywane są tylko na podstawie tego, jakie narzędzia lub platformy software’owe są dostępne, a nie w oparciu o potrzeby użytkownika i organizacji, które miałyby dyktować wybory technologiczne. Czy też to zauważasz?

N: Pamiętasz, kiedy pracowaliśmy dla klienta, który przyszedł do nas i powiedział: “Teraz wszyscy mają aplikacje mobilne, chcę aplikacji mobilnej dla mojej firmy!” — a my szybko zorientowaliśmy się, że to nie aplikacji potrzeba, a zmiany w podejściu do całościowej obsługi końcowego użytkownika? Na szczęście tych klientów jest coraz mniej. Ale pojawiają się inne problemy, jak np. niezrozumienie tego, jak patrzeć na dane liczbowe. “Chcemy zarabiać na danych” (Oryginalnie: We want to capitalise on data” — przyp. tłum.). Kiedy tylko Google lub Apple zrobią coś fajnego, inni chcą za nimi podażąć. Tak, organizacje wciąż tworzą i kupują ustandaryzowane produkty nie próbując nawet zrozumieć, czego potrzebuje użytkownik, a potem wypuszczają je na rynek, grubo się przy tym rozczarowując. Jednak nie jest tak do końca źle, bo słyszę i uczestniczę w coraz większej ilości dyskusji na temat tego, jak mierzyć wydajność produktów od razu po wypuszczeniu na rynek i jak poprawiać ją na bieżąco. Start-upy są w tym całkiem niezłe. A więc nie tylko testują pomysły, ale tworzą produkty, które zwracają prawdziwe dane, na podstawie których poprawiana jest jakość usługi.

Nowe technologie takie jak machine learning czy AI pukają do naszych drzwi, ale jako projektanci musimy być sprytni, żeby używać ich dobrze.

W: Zmieniając nieco temat… Co, według ciebie, odróżnia projektanta usług (service designera) od kogoś, kto projektuje głównie interfejsy?

N: I jedni, i drudzy są potrzebi, ale service designer ma pewną specjalną umiejętność: potrafi zebrać ludzi w grupie i stymulować sposób kolektywnego myślenia, który popycha projekt do przodu. To kluczowa różnica; projektant interfejsów głównie wprowadza gotowe pomysły w czyn. Dobry service designer to enabler. Jednak nie da się dobrze praktykować SD bez rozumienia wielu aspektów projektowych i biznesowych. Pomyśl o architekcie; kiedy myśli o nowym budynku, musi wiedzieć, jakich materiałów użyje, a nie tylko o tym, jak ten budynek będzie wyglądał. Architekt musi też zrozumieć ludzi, którzy będą używali obiektu. Service designer potrzebuje zrozumieć, jak działa organizacja, z którą przyjdzie mu pracować. Jak współpracują ze sobą zespoły i ich poszczególni członkowie? Często okazuje się, na przykład, że wszystko obraca się w atmosferze niezdrowej konkurencji albo, że pojedyncze osoby a nawet całe zespoły traktują swoją pracę bardzo protekcjonistycznie. To może oznaczać, że komunikacja pomiędzy grupami nie działa. Dobry projektant SD rozpozna taki problem i obejdzie te ograniczenia, ucząc ludzi efektywnej pracy. Tylko w ten sposób uda się stworzyć dobry produkt.

Dla odmiany “typowy” projektant UX popatrzy na zagadnienie z dużo węższej perspektywy, skupiając się na interakcji końcowego użytkownika z produktem tylko w sferze cyfrowej. To jest oczywiście niezwykle ważne, ale nie rozwiąże problemu organizacji, która nie potrafi pracować wydajnie, bo jej wewnętrzna struktura bądź przekonania tworzą bariery na drodze do opracowania dobrego produktu….

W: Czy zgodzisz się ze mną, że sprostanie takim wyzwaniom często oznacza ogromny wysiłek dla organizacji?

N: Jasne. Popatrz chociażby na wiele start-upów; ich pomysły są naprawdę świetne, zwłaszcza w początkowych etapach projektowania. Ale często, kiedy ktoś pyta: “I co dalej?” sprawa rozjeżdza się całkowicie. Co robimy? Co teraz? Jak rozszerzyć funkcjonalność w sensowny sposób? Może więcej opcji? Co jeszcze można sprzedać? Rzadko kiedy spotykam się wtedy ze skoordynowaną wizją na temat produktu. Okazuje się, że niejednokrotnie nie wiadomo też, jak wykorzystać badania kolektywnie i zaprzęgając do pracy całe zespoły, a nie tylko wyizolowanych projektantów UX. Tu powinniśmy do akcji wejść my, zajmujący się SD, wykorzystując narzędzia, które omawiałem po to, by rozwiązywać prawdziwe problemy użytkowników a nie tylko rekomendować rozbudowywanie produktu o kolejne opcje, których nikt nie użyje albo takie, które nie przyniosą zysku obu stronom: organizacji i jej klientom.

W: Start-upy i podobne im, niewielkie organizacje są dobrymi poligonami do eksperymentowania z projektowaniem usług. Co mógłbyś powiedzieć komuś, kto jest początkującym projektantem UX ale chciałby spróbować swoich sił w SD, pchając pomysły do przodu i budując coś więcej, niż ładne strony internetowe i aplikacje?

N: Chyba najlepiej będzie, jeśli taki ktoś skupi się na patrzeniu na produkt ze świeżej perspektywy. Warto skupić się na tym, że w każdym procesie istnieje cała rzesza interesariuszy. Popatrz na Ubera: produkt funkcjonuje w ekosystemie, w którym są kierowcy, sama aplikacja, pasażer i organizacja, widoczna na każdym etapie podróży. Czy zastanawiałeś się, jak usługa wygląda z tych czterech punktów widzenia? Czy gromadzisz dane, które mogłyby wzbogacić doświadczenie dla wszystkich końcowych użytkowników? Pierwszy krok to zrozumienie, że usługa jest skomplikowana i istnieje wiele grup docelowych, którym służy. I, że na niektóre zjawiska nie będziemy mieć wpływu. Wtedy okaże się, że istnieje masa rzeczy, o których nie pomyśleliśmy, na przykład: jeżeli taksówką jedzie więcej, niż jeden pasażer, to czy mogą oni podzielić koszt? Może to funkcjonalność, o którą warto rozwinąć aplikację? Jaki byłby efekt tego dla każdego z interesariuszy? A może jest tutaj coś, co uda się wykorzystać wewnętrznie? Czy zespół analizujący dane powinien przyjrzeć się mozliwości, jaką stwarza fakt, że wiemy, iż czekając na samochód pasażer znajduje się blisko specyficznych obiektów, które mogą zaoferować np. sprzedaż innej usługi czy jakąś formę interakcji dla zabicia czasu? Zazwyczaj w każdej firmie, małej i dużej, można trafić na niesamowite informacje i kupę pomysłów, zupełnie się tego nie spodziewając.

Całość sprowadza się do umiejętności patrzenia na usługę pod różnymi kątami. A to wymaga od projektanta ciekawości i zainteresowania się rozmową z innymi.

W: Dobra, hamburgery zjedzone, piwo się skończyło; zanim zamówię następne, podsumujmy temat. Co dalej? Czy nie da się uciec przed zmianą prostego UX w service design? Czy trzeba będzie się przekwalifikować?

N: Myślę, że na rynku wciąż będzie miejsce dla specjalistów, którzy dopieszczać będą końcowe doświadczenia użytkownika, ale także, że coraz większe organizacje będą wprowadzać w życie coraz to mądrzejsze metody kolaboracji. I, że zaczną patrzeć na całościowe usługi z większą dozą zainteresowania i zrozumienia. Poprawnie interpretowane dane, oczywiście, zagrają tu kluczową rolę i będą częściej wyznaczać kierunek rozwoju produktów i usług. Ostatnio widziałem na przykład prezentację termostatu Hive od British Gas, w której powiedziano o tym, że organizacja jest obecnie w stanie przewidzieć wyciek gazu zanim dowie się o tym końcowy użytkownik. W ten sposób można proaktywnie zaoferować nową usługę. Tak, dane będą używane coraz częściej, mam nadzieję, że w poprawny sposób.

W: Dziękuję, Neil. Jeżeli masz ochotę dodać coś dla czytelników mojego bloga, to wal śmiało.

N: Jest bardzo łatwo znaleźć się w sytuacji, w której poświęcamy detalom rozwiązania końcowego zbyt dużo uwagi, ale z mojego doświadczenia wynika, że nadanie pędu projektowi poprzez zbudowanie prawidłowych relacji między zaangażowanymi zespołami przynosi dużo lepsze rezultaty. Tak więc: bądź ciekawą wszystkiego osobą i nie daj się zasadzić w bańce, w której projektowane będą tylko kolejne ekrany aplikacji. Wychodź myślą poza to; rozmawiaj z końcowymi użytkownikami. Tymi prawdziwymi, kimś, kto używa zaprojektowanego przez ciebie produktu. Naprawdę warto. Lepiej nie można zacząć.

P.S. Neil jest na Twitterze. Polecam.


Uwaga, uwaga, rozbieram się do naga

Tak naprawdę, to wcale nie. Ale mam coś ciekawego do zaproponowania!

24 listopada poprowadzę w Gdańsku warsztaty „UX w praktyce”, które poprzednio odbyły się w Warszawie. Więcej informacji na stronie poświęconej wydarzeniu. Zapraszam serdecznie tych z Was, którzy chcą dowiedzieć się, jak zaplanować wydajne i efektywne procesy UX. Do 31 października cena jest niższa i, śmiem twierdzić, konkurencyjna. Warsztaty trwają cały dzień i składają się z porannej części teoretycznej i popołudniowej, na której wałkujemy projekty.

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


Komentarze

Dodaj komentarz

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