Moc design thinking w projektowaniu dla IT
Projektuję interfejsy dla użytkowników w oparciu od design thinking już ponad 10 lat. Widziałem wielkie idee, które pomimo olbrzymich budżetów, zaangażowania zespołu i teoretycznie dobrego produktu nie osiągały sukcesów. Zastanawiałem się, z czego to wynikało i obiecałem sobie, że kiedy ja będę miał większą siłę sprawczą nie dopuszczę do porażki. Zacząłem analizować produkty, które upadły lub nie zostały nawet wprowadzone na rynek, gdyż pierwsze opinie użytkowników wskazywały, że produkt nie rozwiązuje żadnych problemów, z którymi się oni borykają. Często były one czymś "fancy", ale w zasadzie nie zmieniały doświadczeń klientów w znaczny sposób. Innym razem opierały się na jakimś niemal dogmacie- nasz klient wszystko przyjmie i niezależnie od tego jak "fikuśny" proces wymyślimy to on i tak z pokorą będzie przez niego przechodził. Oczywiście na końcu następowała weryfikacja i zderzenie się z rzeczywistością.
Analiza produktów
Co łączyło te wszystkie produkty, które odniosły porażkę? Miały one jeden, wspólny mianownik- realizowały jedynie cele biznesowe, bez zaangażowania użytkownika w proces. To na pewno. Kolejne cechy wyróżniające produkty niezyskujące poklasku to skupienie się w fazie analizy jedynie na funkcjonalnościach, które dostarczył klient. Często odbywa się to w ten sposób, że klient dostarcza dokument opisujący produkt, który chce stworzyć. Następnie zespół developerów wycenia "zakodowanie" tychże funkcjonalności, określany jest czas, gdzieś tam powstają makiety i… zaczyna się. Nagle okazuje się, że funkcjonalności opisane w zapytaniu nie zawierały niektórych aspektów, które pojawiły się kiedy projektant zaczął rysować makiety i z empatią pomyślał o użytkowniku końcowym lub niektórych funkcjonalności brakowało, aby w ogóle z powodzeniem móc przejść przez cały proces jako użytkownik.
Co to powoduje? Ma to kosmiczne konsekwencje- dlatego, że zmienia się czas projektu, zmienia się też cena projektu i zaczynamy tracić kontrolę nad finalną formą produktu. W dodatku nigdy nie mamy pewności, że wszyscy rozumieją produkt w ten sam sposób oraz to jaki jest główny cel tego przedsięwzięcia. I finalnie- czy w ogóle nasz cel jest właściwy? Aby odpowiedzieć na to pytanie- wystarczy w fazie analizy/discovery znaleźć przestrzeń dla warsztatów w metodologii design thinking. Ale o co w tym wszystkim naprawdę chodzi?
O co chodzi z design thinking?
Design thinking opiera się w pierwszej kolejności na empatii. Empatia to najważniejsza cecha, która pomaga zrozumieć potrzeby innych. Chcemy zrozumieć użytkownika końcowego- to dla niego tworzymy produkt. Staramy się zmapować potrzeby użytkownika oraz cele biznesowe i połączyć je ze sobą w harmonii.
Aby zrozumieć użytkownika korzystamy z map empatii. To prosta mapa skupiająca się na kilku aspektach. Tym, co użytkownik myśli, słyszy, mówi i robi. Wypełnienie tej planszy pozwala umiejscowić użytkownika oraz produkt w konkretnym kontekście- sytuacji, w której musimy się poruszać jako dostawcy. Ma to jeden ważny aspekt- jesteśmy pewni co do tego, iż zarówno klient jak i zespół projektowy postrzega użytkownika w ten sam sposób. Wyobraź sobie zespół piłkarski, gdzie obrona i atak analizują zespół przeciwnika osobno- w dwóch różnych pokojach. Ciężko w takiej sytuacji o zrozumienie podczas meczu. To, co udaje się zniwelować podczas warsztatów design thinking to różnica w wieży pomiędzy klientem a dostawcą. Tworzymy jeden zespół grający do jednej bramki.
Cel produktu wg design thinking
Kiedy rozumiemy użytkownika, mamy wypełnione mapy empatii powoli zaczynamy definiować cel produktu. Żeby określić cel należy zdefiniować wszystkie problemy, z jakimi boryka się użytkownik oraz biznes. Metod na określenie tych bolączek jest kilka- dobierane są one adekwatnie do grupy obecnej na warsztatach. Możemy korzystać z prostej burzy mózgów, metody "róż, cierni i pączków" czy szeregu innych metodologii, które opiszę w kolejnym artykule. Konsekwencją tego etapu jest mapa czy też tablica wszystkich bolączek, jakie chcemy zniwelować.
Na problemy trzeba patrzeć szeroko. Zastanowić się nad każdym kontaktem użytkownika z marką i zmapować wszystkie bolączki. Następnie wybieramy te, które chcemy rozwiązać w pierwszej kolejności- z największą korzyścią dla naszego biznesu oraz użytkownika.
Etap trzeci to etap najprzyjemniejszy, gdyż tutaj zaczynamy skupiać się na rozwiązaniach wcześniej wyszczególnionych problemów. To tutaj zaczyna się rysować obraz naszego produktu. Wielokrotnie w projektach zapomina się o etapach pierwszym i drugim, rozpoczynając od razu od pomysłów. Klienci możliwe, że przeprowadzają wewnętrznie analizę problemów oraz klientów, lecz bez uczestnictwa dostawców jest dysonans poznawczy. Dostawca nie rozumie, po co tworzy produkt- co prowadzi do częstych nieporozumień. Mając jednak pomysły rozwiązujące problemy, możemy określić cel. Kiedy wszyscy rozumieją cel, możemy przejść do kolejnego etapu- Makiet i prototypu.
Makieta i prototyp
O ile każdy rozumie czym są makiety oraz prototypy to nie każdy docenia ich przygotowanie w ramach analizy czy fazy discovery. Często makiety pojawiają się już po analizie funkcjonalności i estymacji kosztów. Podejście to generuje kilka problemów, o których wspominałem we wstępie tego artykułu. Nie jesteśmy w stanie określić dokładnie wszystkich funkcjonalności bez makiet oraz finalnego kosztu developmentu, kiedy nie widzimy jak wygląda produkt. Jeśli chcesz zapanować dokładnie nad kosztami oraz czasem to powinieneś poprosić dostawcę, aby przygotował makiety (mogą być wireframe głównych funkcjonalności i ścieżek) w ramach analizy. Poza możliwością określenia kosztu- widzisz zarys swojego produktu oraz to czy odpowiada on na wcześniej zdefiniowane potrzeby. Największym skarbem jednak jaki stanowią makiety jest możliwość przeprowadzenia kolejnego etapu- testów.
Etap testów makiet czy prototypu umożliwia ocenę rozwiązania przez grupę fokusową- a więc realnych użytkowników. To tutaj wykorzystując np. Maze lub inne narzędzia masz możliwość sprawdzenia całej koncepcji, lub głównych nurtów i ścieżek jeszcze przed uwolnieniem budżetu na development. To tutaj dowiesz się, czy Twój produkt spełnia oczekiwania biznesowe oraz oczekiwania użytkowników. To dobry moment, aby wycofać się z niepotrzebnych funkcjonalności lub dodać to co może stanowić o sukcesie. Otrzymujesz raport, dane, liczby i na tej podstawie możesz decydować o finalnym kształcie produktu.
Implementacja metody
Wiesz już czym jest design thinking i jak może pomóc podczas planowania budżetu oraz określania finalnej formy produktu. Jak natomiast zaimplementować tę metodologię w taki sposób, aby móc stosować w projektach agile? To stosunkowo proste. Wiele zespołów, z którymi miałem okazję pracować postępuje w ten sposób:
Analityk definiuje problem -> Zadanie trafia do backlog -> tworzone są makiety -> development -> testy rozwiązania
proponowany przeze mnie proces w duchu design thinking:
Analityk definiuje problem -> tworzone są makiety -> testy rozwiązania -> zadanie trafia do backlog -> development.
Różnica jest widoczna. Do backlog trafiają już przetestowane rozwiązania na etapie makiet. Oczywiście rekomendowane jest przeprowadzenie analizy po go-live, lecz zmniejszamy ryzyko do wprowadzenia na rynek nieadekwatnego produktu do minimum. Zmniejszamy też ilość iteracji i zmian w kodzie do minimum. I wreszcie ostatni punkt- możemy wprowadzać na rynek absolutne minimum, rozwiązujące największe bolączki, a nie podchodzić do produktu w sposób niemal "waterfall" - wszystkie funkcjonalności naraz. O ile trafiliśmy z potrzebami użytkowników to podejście "waterfall" nie jest złe. Gorzej jeśli spędziliśmy rok czy więcej na tworzeniu rozwiązania, które nie adresuje potrzeb rynku, a przez brak testów na etapie makiet nie zauważyliśmy tego problemu.
Podsumowanie
Podejście design thinking pomaga nie tylko dostarczać produkty pięknie i użyteczne, ale również umożliwia optymalizację budżetu. Jeżeli jesteś zainteresowany implementacją design thinking w Twojej organizacji lub w proces tworzenia Twojego produktu- skontaktuj się ze mną w ramach bezpłatnej i niezobowiązującej konsultacji: