Oszczędzanie produktu X – studium przypadku myślenia projektowego

Czym jest myślenie projektowe?

Wyobraź sobie, że masz pomysł. Tworzysz genialną aplikację, która Twoim zdaniem rozwiąże Twoje problemy biznesowe. Obecnie na rynku nie ma identycznych rozwiązań, a to, które jest najbardziej podobne, nie działa tak, jak oczekują tego klienci.

Kiedy twoja wizja jest wciąż świeża, zaczynasz myśleć o pierwszym podstawowym pytaniu, które przychodzi ci do głowy: „Ile czasu zajmie wykonanie tego?”

A ponieważ rzadko mamy nieograniczony budżet i czas, szybko pojawia się drugie pytanie: „Ile będzie mnie to kosztowało?”

Oba te pytania są fundamentalnymi i kluczowymi pytaniami przy tworzeniu produktu, ale często są to właśnie błędne pytania na początek.

Zamiast tego najważniejszym pytaniem, które należy najpierw zadać, jest: „Jaką wartość mogę stworzyć dla moich użytkowników?”

Aby lepiej zrozumieć zakres projektu, wymagania i harmonogram, możemy zastosować metodologię o nazwie „Myślenie projektowe”, która pomaga nam podczas „Fazy odkrywania” produktu. To jest właśnie ten czas, kiedy musimy zrozumieć nie tylko, z czego będzie świetny produkt, ale także jak i czy powinniśmy to zrobić. To kreatywne i eksperymentalne podejście pomaga nam lepiej zrozumieć, jak tworzyć rzeczy, które są nie tylko użyteczne, ale przede wszystkim użyteczne.

Proces Design Thinking jest szczególnie przydatny, ponieważ generuje unikalny i konkretny wynik: wiedzę.

Ta metodologia ma szerszy zakres zastosowania, ale na potrzeby tego studium przypadku Design Thinking skupimy się tylko na jednej konkretnej dziedzinie - rozwoju oprogramowania.

Teoria myślenia projektowego

Zanim zagłębimy się w praktyczne zastosowania Design Thinking i moje doświadczenie w jego stosowaniu, przyjrzyjmy się bliżej procesowi Design Thinking.

Design Thinking to metodologia, która zapewnia podejście do rozwiązywania problemów oparte na rozwiązaniach. Koncentruje się na zrozumieniu perspektywy użytkownika, z punktu widzenia skoncentrowanego na człowieku. Siłą tej metodologii jest możliwość szybkiego przetestowania, czy pomysł, rozwiązanie lub ulepszenie może przynieść naszym klientom realne rezultaty. Integrując różne metodologie, narzędzia i techniki pochodzące z różnych dziedzin (marketing, psychologia, design, biznes), celem Design Thinking jest umieszczenie użytkownika w samym centrum problemu, który musimy rozwiązać.

Celem metodologii jest „odnalezienie samego użytkownika i zdefiniowanie jego potrzeb” i poprzez znalezienie tych potrzeb stworzenie rozwiązania lub produktu, który może być naprawdę użyteczny. Aby osiągnąć ten cel, całą koncepcję podzielono na sześć faz myślenia projektowego.

1. Empatyzacja: Celem tej fazy jest zrozumienie klienta poprzez wyszukiwanie i gromadzenie informacji o jego firmie. W tej fazie możemy korzystać z kilku różnych narzędzi, takich jak wywiady, grupy fokusowe, obserwacje i ankiety.
2. Zdefiniuj: w tej fazie zbieramy i kategoryzujemy informacje z fazy Empathize. To tutaj definiujemy User Persony i User Journeys.
3. Ideate: Korzystając z powyższych informacji, zespół tworzy pomysły rozwiązań. Nie ma głupich lub złych pomysłów! Wszystko musi być wyrażone i udokumentowane.
4. Prototyp: W tej fazie powstaje coś namacalnego, co pozwoli Ci zweryfikować swój pomysł w prawdziwym życiu. Nie komplikuj zbytnio i stwórz ten MVP tak szybko, jak to możliwe.
5. Test: Zweryfikuj swój pomysł w prawdziwym życiu z rzeczywistymi użytkownikami. Otrzymać odpowiedź. Zadawaj pytania, jak to ulepszyć.
6. Implementacja: jest to faza, w której cała zebrana wiedza zostaje przełożona na produkt końcowy.

Jeśli po przeczytaniu tego możesz pomyśleć: „Wspaniale, ale w jaki sposób pomoże to szybko urzeczywistnić moją aplikację”. Aby uczynić to bardziej namacalnym, omówię studium przypadku z mojego osobistego doświadczenia, które skorzystało na procesie myślenia projektowego.

Zastosowane myślenie projektowe — studium przypadku z życia

Wprowadzenie: Projekt X

Jakiś czas temu znalazłem się na spotkaniu z przedsiębiorcą, kilkoma menedżerami i wieloma pomysłami latającymi po pokoju. Ich bezpośredni konkurent wydał niedawno nową aplikację i napięcie było namacalne. Firma chciała wyjść z czymś nowym na rynku, aby nie stracić pola z konkurentem.

Przygotowali dokument z wymaganiami, niejasnym wyobrażeniem o tym, jak produkt powinien wyglądać i ile powinien kosztować.

„Musimy podążać za tym, co zrobili inni, z niższą ceną” – powiedział dyrektor marketingu. „Musimy stworzyć bardziej użyteczny system, który uprości podróż użytkownika” – dodał inny menedżer. „Musimy zmienić sposób, w jaki zbieramy informacje, uprościć je i zintegrować nasze procesy ze stronami trzecimi” – powiedział inny. „Zajmie nam to miesiące”, potrząsnął głową kierownik techniczny, który w myślach przetłumaczył wszystkie te żądania na setki godzin kodu do zaimplementowania.

Chociaż nie mogę ujawnić wszystkich szczegółów projektu, mogę ujawnić, że produkt był oprogramowaniem komunikacyjnym koncentratora. To oprogramowanie zarządzało różnymi kanałami (e-mail do SMS, faks do VoIP) i zostało stworzone dla platform internetowych i mobilnych. Produkt powstał kilka lat wcześniej, ale jego użyteczność była słaba. W momencie premiery konkurent znacznie wyprzedzał pod względem doświadczenia użytkownika. Ponadto mieli świetną aplikację mobilną, która zdobywała popularność w sklepie z aplikacjami mobilnymi.

Firma X była firmą opartą na tradycyjnych procesach, znającą tradycyjne projekty. W przeszłości prowadził kilka projektów Agile, ale pomysł stworzenia MVP i przetestowania go na rynku był nowością. Co więcej, bali się nieznanego. Co by było, gdyby nowy MVP miał niepożądany lub nieprzewidywalny wpływ na bazę klientów? Ten brak kontroli nie budził zaufania.

Opisane powyżej i kolejne spotkania nie doprowadziły do ​​jasnego określenia, czym właściwie był produkt do osiągnięcia. Wiedzieliśmy tylko, że musimy jak najszybciej trafić w cel.

Jednak wraz z postępem projektu i wzrostem popularności konkurenta, zgoda firmy się umacniała. Większość zgodziła się z koncepcją, że: „Nie stać nas na wprowadzenie na rynek półproduktu, potrzebujemy produktu, który działa od samego początku”.

Pomimo początkowego zakłopotania i strachu, była to okazja, aby dowiedzieć się, co przyniesie prawdziwą wartość dla ich bazy użytkowników i potencjalnie przyciągnie więcej użytkowników poprzez stworzenie usprawnionego, lekkiego produktu.

To skłoniło firmę do poszukiwania podejść, których wcześniej nie próbowała, aby mieć kompletny produkt zbudowany na czas, nawet jeśli w momencie wprowadzenia na rynek będzie miał tylko podstawowe funkcje. Postanowiliśmy wykorzystać proces Design Thinking i skupić się na rzeczach, które naprawdę przyniosą wartość użytkownikowi końcowemu, a tym samym pokonamy konkurencję, dostarczając klientowi tylko to, co niezbędne.

Etap 1 - Empatyzacja

Faza empatii: Celem tej fazy jest zrozumienie klienta poprzez wyszukiwanie i zbieranie informacji o jego działalności. W tej fazie możemy korzystać z kilku różnych narzędzi, takich jak wywiady, grupy fokusowe, obserwacje i ankiety.

W najbardziej dosłownym sensie empatia to zdolność rozumienia i dzielenia się emocjami innych. W myśleniu projektowym empatia to „głębokie zrozumienie problemów i rzeczywistości ludzi, dla których projektujesz”.

Naszym pierwszym krokiem było upewnienie się, że Opinia Najwyższego Płatnika (znana również jako HiPPO) nie rządzi opinią wszystkich innych. Dlatego wspólnie z menedżerami i założycielem opracowaliśmy listę potencjalnych interesariuszy, którzy mogą być zaangażowani w proces decyzyjny.

Podczas całodniowego spotkania opracowaliśmy pierwszą listę 30 nazwisk (między pracownikami, kierownikami funkcjonalnymi i klientami), z którymi można było skontaktować się bezpośrednio, a następnie wybraliśmy grupę docelową 4000 klientów (około 10% ich powracających użytkowników będących klientami). baza).

Staraliśmy się „znormalizować” naszą bazę docelowych klientów tak bardzo, jak to możliwe, poprzez uwzględnienie różnorodności pod względem dystrybucji płci, branży i innych punktów danych. Aby dodać dodatkowy poziom złożoności, fizyczna lokalizacja próbki, z którą przeprowadzono wywiad, została podzielona na różne miasta, aw niektórych przypadkach kraje. Mieliśmy teraz punkty kontaktowe do przeprowadzania wywiadów i kwestionariuszy.

Grupa została zorganizowana tak, aby przeprowadzać wywiady zdalnie, posługując się zapisanym zestawem pytań i kilkoma podstawowymi zasadami:

• Podczas rozmowy postaraj się zastosować technikę „5 Whys”.
• Spróbuj zrozumieć główne „Co, jak, dlaczego” stojące za każdym zachowaniem.
• Upewnij się, że rozmówca używał kamery internetowej i że odległość od kamery była wystarczająca, aby móc przynajmniej częściowo uwzględnić mowę ciała.
• Nagrywaj wszystkie wywiady, na wypadek, gdyby trzeba było je zobaczyć w przyszłości.

Pytania do wywiadu przygotowaliśmy z zamiarem zrozumienia, które główne funkcje należy ulepszyć lub wyeliminować, abyśmy mogli szybko zbudować nową wersję odpowiadającą na potrzeby naszych użytkowników.

Dla drugiej grupy użytkowników przygotowaliśmy serię pytań w formularzu Google. Zdecydowaliśmy się na pytania wielokrotnego wyboru, z niektórymi sformułowanymi pytaniami otwartymi, aby ułatwić użytkownikom większą interakcję, w tym pytaniem wymagającym od użytkownika wypróbowania nowej wersji produktu dostępnej właśnie w zamkniętej wersji beta.

Aby zorganizować cały proces zbierania informacji, wykorzystaliśmy narzędzia zdalne, które pozwoliły zespołowi na łatwiejsze zbieranie informacji, w tym Skype, Zoom, Formularze Google i cyfrową tablicę Kanban, na której umieszczaliśmy wszystkie nasze działania i śledziliśmy ich status.

Pierwsze wyniki wywiadów były zachęcające, ponieważ respondenci byli otwarci na przekazywanie informacji zwrotnych na temat słabych i mocnych stron systemu.

Jednak pierwsza partia odpowiedzi na pytania kwestionariusza była znacznie mniej ekscytująca: na 300 wysłanych e-maili tylko 5 osób wypełniło kwestionariusze.

Rozczarowani tym wynikiem byliśmy gotowi wypróbować nowe sposoby zaangażowania użytkowników, gdy jeden z kierowników sprzedaży przyszedł do nas z pomysłem:

„Nie sądzę, że odpowiedzą na żadne e-maile, nie są przyzwyczajeni do interakcji z nami. Ale jeśli skontaktujemy się ze wszystkimi, którzy mają wygasające odnowienie i damy im małą zachętę, jestem pewien, że pomogą nam”.

Pomysł był prosty, ale wyjątkowy. W ciągu kilku godzin otrzymaliśmy nową listę użytkowników (3800), która utrzymała ten sam podział na mainstream i ekstrema. Jednak ci użytkownicy byliby „zmuszeni” do interakcji z systemem, ze względu na bliskość ich odnowienia.

Tym razem poproszono ich o udzielenie odpowiedzi na serię pytań, wzięcie udziału w becie i otrzymanie w zamian zniżki na odnowienie. Adhezja była całkowita i przy pierwszej dostawie tego nowego modelu ponad 70% użytkowników odpowiedziało i wypełniło kwestionariusz.

Po iteracji i zmianie niektórych pytań oraz dzięki niektórym użytkownikom, którzy chcieli przeprowadzać wywiady więcej niż jeden raz, byliśmy gotowi do jaśniejszego zdefiniowania naszej bazy użytkowników.

Etap 2 — Zdefiniuj

Etap definiowania: W tej fazie zbieramy i kategoryzujemy informacje z etapu Empathize. To tutaj definiujemy User Persony i User Journeys.

Słownikowe znaczenie definicji polega na określeniu tożsamości i istotnych cech pojęcia . W naszym przypadku chcieliśmy zdefiniować:

• nasi idealni klienci
• ich problemy
• rozwiązania ich problemów
• potrzeby i obawy naszych klientów, którymi musieliśmy się zająć

W kategoriach myślenia projektowego faza definiowania polega na przeanalizowaniu swoich obserwacji i zsyntetyzowaniu ich w podstawowe problemy, które zidentyfikowałeś.

Mieliśmy wystarczającą bazę danych, aby zrozumieć, jakie były prawdziwe problemy. Oprócz informacji zwrotnych otrzymanych w fazie Empathize zawierał on punkty, które zostały podkreślone przez pracowników Firmy X, ale nigdy nie zostały wskazane kierownictwu, a także mocne i słabe strony oraz inne problemy, które nigdy nie zostały wzięte pod uwagę.

Kolejnym działaniem było stworzenie naszych User Personów. Podczas tej fazy burzy mózgów zaangażowaliśmy cały rozszerzony zespół. Faza burzy mózgów była zawsze przeprowadzana zdalnie, przy użyciu systemów wideokonferencyjnych i narzędzi do śledzenia person i ich tworzenia w czasie rzeczywistym.

W przypadku każdej Persony określiliśmy ich biografię, podejście do technologii, korzystanie z mediów społecznościowych, preferowane marki, ich potrzeby i pomysły oraz spekulowaliśmy, jaka byłaby ich Podróż Klienta.

Następnie wybraliśmy wspólnego klienta User Persony i otrzymaliśmy gotowy zestaw danych pochodzących z wywiadów i ankiet. To był właściwy czas, aby ubrudzić sobie ręce.

W fazie definiowania próbowaliśmy przekształcić ogólną definicję problemu, taką jak „Potrzebujemy produktu, który zwiększy naszą sprzedaż o 10%” w bardziej szczegółowe rozwiązanie, takie jak: „Mężczyźni i dorosłe kobiety w wieku od 35 do 45 lat osoby pracujące w biurze muszą otrzymywać wiadomości, które mają moc prawną, aby mieć pewność, że nadawca jest rzeczywiście tym, za kogo się podaje”.

Na tym etapie procesu projektowego przeprowadziliśmy burze mózgów wokół naszych użytkowników, postawiliśmy hipotezy dotyczące rozwiązań i zachowaliśmy otwarty umysł na każdą możliwą innowację. „Jedynym głupim pomysłem jest ten, którego nigdy nie wyrażono” brzmiała mantra.

W krótkim czasie, pamiętając o tym, kim byli nasi badani, uzyskaliśmy jasny obraz tego, co jest przydatne dla naszych użytkowników, a także jakie potrzeby i obawy powinniśmy uwzględnić na ścieżce klienta.

Następnie zaangażowaliśmy się w zbudowanie „Mapy historii użytkownika”, która pozwoliła nam kategoryzować proces użytkowników, przypisując je do tematów. Dla każdej z person zdefiniowaliśmy zestaw czynności, historii i zadań, które założyliśmy, że muszą wykonać podczas podróży. W ten sposób mogliśmy szybko przetestować nasz pomysł i zrozumieć, czy spełnia on podstawowe potrzeby. Gdyby tak było, moglibyśmy wprowadzić go na rynek szybciej niż wszyscy inni, co było niezbędne, ponieważ nasz konkurent z każdym dniem odnosił coraz większe sukcesy.

Etap 3 - Pomysł

Faza pomysłów: Korzystając z powyższych informacji, zespół tworzy pomysły rozwiązań. Nie ma głupich lub złych pomysłów! Wszystko musi być wyrażone i udokumentowane.

O krok dalej od definicji jest faza Ideacji, w której kluczem jest tworzenie prawdziwych pojęć i rozwiązań, a nie tylko abstrakcyjnych definicji.

W kategoriach myślenia projektowego ideacja to „proces, w którym generujesz pomysły i rozwiązania poprzez sesje takie jak szkicowanie, prototypowanie, burza mózgów, pisanie mózgów, najgorszy możliwy pomysł i bogactwo innych technik ideacji”.

Nasz zespół był całkowicie zdalny, więc zdecydowaliśmy się przystąpić do pracy w sposób Lean przy produkcji materiałów i ich przeglądaniu. Na przykład projektanci i inni członkowie zespołu zgodzili się, że aby działać jak najszybciej, najlepszym rozwiązaniem byłoby rozpoczęcie od rysunków na papierze i udostępnienie ich zdjęć w grupie. Dopiero wtedy wykonalibyśmy najciekawsze wzory w Balsamiq lub Axure.

Dla każdego wykonanego szkicu zbieraliśmy informacje od użytkowników, definiowaliśmy zestaw rozwiązań i wracaliśmy do tych użytkowników (kiedy było to możliwe i tak często, jak to było możliwe) aby przetestować z nimi proces i wynik.

Etap 4 - Prototyp

Faza prototypowania: _ Podczas tej fazy powstaje coś namacalnego, co pozwoli Ci zweryfikować Twój pomysł w prawdziwym życiu. Nie komplikuj zbytnio i stwórz ten MVP tak szybko, jak to możliwe. _

W fazie prototypu w końcu nadszedł czas, aby wprowadzić w życie nasze definicje i pomysły. Prototyp jest pierwszym, oryginalnym modelem proponowanego produktu i właśnie to postanowiliśmy zbudować. Zgodnie ze standardami myślenia projektowego etap prototypu polega na tworzeniu niedrogich, pomniejszonych wersji rzeczywistego produktu w celu zbadania rozwiązań z poprzednich etapów.

Po prawie 10 dniach od początku naszej podróży dotarliśmy do kluczowego momentu, spotkania z zespołem deweloperskim, gdzie mieliśmy okazję sprawdzić nasze założenia i szacunki. Po sesji konsultacji i definicji z zespołem programistów zważyliśmy historie i zrozumieliśmy, że główny wysiłek związany z pracami programistycznymi będzie dotyczył rozwoju systemu zaplecza i połączenia z istniejącymi obecnie starszymi systemami. Oprócz tego zdaliśmy sobie również sprawę, że tworzenie systemów front-end będzie znacznie krótszym ćwiczeniem. Dlatego postanowiliśmy stworzyć prototyp front-endu z komponentów, które już istniały w systemie, aby zaoszczędzić czas.

Mieliśmy 3 dni na przygotowanie pierwszej wersji prototypu. Ten prototyp miał jak najbardziej odzwierciedlać produkt i zachować niezbędną funkcjonalność.

Po 3 dniach mieliśmy już gotową pierwszą wersję prototypu. Zawierał „fałszywe” dane, które odzwierciedlały zachowanie oprogramowania, które zamierzaliśmy stworzyć. Brakowało niektórych elementów dodatkowych, ale oprogramowanie w tym stanie wizualnie stanowiło dobry procent całej planowanej zawartości.

Po dwóch tygodniach pracy mieliśmy oprogramowanie, które mogliśmy wypróbować i przetestować na rzeczywistych użytkownikach. Wykorzystaliśmy oprogramowanie do monitorowania doświadczeń użytkowników, aby przeanalizować mapy cieplne i uwagę użytkowników, podczas gdy oni poruszali się po naszym prototypie.

Etap 5 - Test

Faza testowania — zweryfikuj swój pomysł w prawdziwym życiu z rzeczywistymi użytkownikami. Otrzymać odpowiedź. Zadawaj pytania, jak to ulepszyć.

Po fazach definicji, pomysłu i prototypu nadszedł wreszcie czas, aby sprawdzić, czy nasz produkt rzeczywiście działa w prawdziwym życiu. W kategoriach myślenia projektowego testowanie oznacza testowanie całego produktu z wykorzystaniem najlepszych rozwiązań powstałych w fazie prototypowania.

W naszym przypadku faza testów nie tylko odbywała się na końcu, ale była to ciągła pętla sprzężenia zwrotnego i iteracji, kiedy tylko było to możliwe. Pod koniec każdego wykonanego kroku staraliśmy się uzyskać informacje zwrotne od użytkowników lub klientów, zanim przekonaliśmy się do przejścia do następnej fazy.

Po ukończeniu prototypu nadszedł czas, aby przetestować go z jak najszerszym gronem odbiorców i sprawdzić z nimi, jak skutecznie spełnia ich potrzeby, rozumie ich percepcję i czy spełnił ich cele.

Faza testowania obejmowała w szczególności prototyp przejścia, w którym użytkownicy mogli zobaczyć nowy przepływ pracy i wykonywać działania, a także kilka sesji, podczas których zespół bezpośrednio obserwował użytkowników, śledząc ich odpowiedzi. Do zebrania współczynników konwersji dla określonych funkcji platformy użyto prostego kwestionariusza, w którym użytkownicy zostali poproszeni o ocenę procesu od 1 do 10.

Faza testowania została później rozszerzona na cały zespół, a nawet na niektóre osoby spoza organizacji (klienci i użytkownicy), które podczas wcześniejszych sesji dobrowolnie zgodziły się wyrazić swoją opinię na temat wdrożenia systemu.

Wyniki tych testów były zachęcające. Interesariusze Firmy X mogli nie tylko zobaczyć makiety, ale po raz pierwszy wypróbować i „dotknąć” produkt. Poszerzony zespół miał okazję w ciągu dwóch tygodni przetestować i zweryfikować swoje założenia oraz skorygować je w czasie.

Teraz czekał ostatni test: otwarcie go dla użytkowników i zrozumienie, co będzie dalej.

Etap 6 - Implementacja

Faza wdrożenia: jest to faza, w której cała zebrana wiedza zostaje przełożona na produkt końcowy.

Mieliśmy dane, pomysły, persony i nasz pierwszy namacalny prototyp. Pora zakasać rękawy i zacząć się rozwijać. Na wdrożenie naszego nowego systemu mieliśmy półtora miesiąca.

Zdefiniowaliśmy zestaw reguł, aby nasz MVP został wdrożony w krótkim czasie:

• Zbudujemy tylko to, co zdefiniowaliśmy, bez dodawania nowych funkcji.
• Będziemy skupiać się na głównym celu biznesowym.
• Będziemy wykorzystywać metodyki zwinne w zespołach do zarządzania obciążeniem pracą.

Aby ukończyć projekt na czas, sprowadziliśmy kilku nowych członków zespołu, którzy nie byli zaangażowani w projekt od bardzo wczesnych etapów fazy odkrywania.

Dodaliśmy programistów frontend, programistów backendów i projektantów. Nowi członkowie zespołu pracowali zdalnie i nie było możliwe zebranie ich wszystkich w jednym pomieszczeniu na czas trwania projektu, dlatego zadbaliśmy o odpowiednie narzędzia do utrzymania komunikacji.

Proces wprowadzony do zarządzania pracą był procesem Agile. Pozostały czas podzieliliśmy na kilka krótkich sprintów, ze zdalnymi spotkaniami każdego dnia i aktualizacjami przez Slacka w ciągu dnia, aby wymieniać się pomysłami i pomagać sobie nawzajem w rozwiązywaniu problemów.

Nie mieliśmy gdzieś pełnej dokumentacji, ale mentalnie wszyscy mieliśmy obszerny zestaw działań, wspólną wizję i cele w zespole. Wszyscy zaczęliśmy postrzegać User Persony jako prawdziwego użytkownika, z własnymi potrzebami i problemami. Gdy nasz zespół zaczął mieć spójną wizję, przeszliśmy do określania, co należy zrobić i kiedy, aby zakończyć projekt na czas.

Działania zostały nakreślone w ramach User Story Map, aby zachować oryginalne dowody osobowości i przepływu, jaki chcemy nadać produktowi.

Mapy User Story zostały utworzone za pomocą trzech wyraźnych kroków: identyfikacji działań, identyfikacji kroków wymaganych do ukończenia działania oraz listy historii/zadań powiązanych z każdym z nich. Posortowaliśmy historie według priorytetu (Must, Should, Could), który dyktował, jakie komponenty znalazły się w produkcie.

Zespół był w stanie działać w szybkim tempie od samego początku wdrożenia, dzięki jasnej wizji, którą podzielił zespół i zastosowanej przez nas metodzie, która pozwoliła zespołowi pozostać na dobrej drodze bez bezpośredniego sterowania przez kierownictwo powyżej. Wszyscy pracujący w projekcie mieli na uwadze pytania z etapów Design Thinking:

• Jakie działanie powinien wykonać każdy użytkownik na naszej platformie i co starał się osiągnąć?
• Jakie kroki powinni podjąć ci użytkownicy, aby osiągnąć ostateczny cel?
• Jakie problemy mieli wcześniej i jak ich unikać?

Pozwoliło to naszemu zespołowi na podejmowanie własnych mikrodecyzji i nakierowanie produktu na ostateczny cel.

Dokonaliśmy dwóch przeglądów pracy w toku na koniec każdego sprintu i jednego końcowego przeglądu wydania na końcu ścieżki, zanim produkt został ostatecznie wprowadzony do produkcji. Ostatni sprint wykorzystaliśmy do przygotowania infrastruktury potrzebnej do uruchomienia i uruchomienia produktu.

Wreszcie użytkownicy, którzy korzystali z naszego starego produktu, zostali ponownie zaproszeni do wypróbowania nowej wersji. Nasz produkt został wprowadzony do produkcji dwa miesiące po spotkaniu, na którym wyrażono pomysł na jego wykonanie. Produkt zadziałał, użytkownicy zaczęli z niego korzystać, a my stopniowo wysyłaliśmy coraz więcej nowych użytkowników do tego narzędzia zamiast do starego. Testy A/B pokazały nam, że preferują nowy produkt, a projekt został przyjęty w firmie jako duży sukces.

Co ważniejsze, ostatecznie zaakceptowano metodologię Design Thinking. Wierzymy, że będzie to miało dobry i długotrwały wpływ i pozwoli im budować lepsze produkty w przyszłości.

Wniosek

W tym studium przypadku pokazaliśmy, w jaki sposób metodologię Design Thinking można zastosować do rzeczywistego problemu przy ograniczonym czasie i budżecie.

Zamiast używać bardziej tradycyjnych podejść i tworzyć rzeczy w sekwencyjnych krokach, zdecydowaliśmy się przejść przez sześć etapów myślenia projektowego. Okaż empatię. Definiować. Pomysł. Prototyp. Test. Wprowadzić w życie. Stało się to naszą mantrą i pozwoliło nam wyprodukować bardzo dobrze przyjęty produkt.

Korzystanie z Design Thinking doprowadziło do zaoszczędzenia czasu, a co za tym idzie do obniżenia kosztów związanych z projektem. Nie pracowaliśmy nad milionami różnych funkcji, a jedynie nad kilkoma, dobrze przemyślanymi akcjami, które były jasne dla wszystkich w zespole. Co najważniejsze, byliśmy w stanie dostarczyć produkt i wartość, której potrzebowali użytkownicy.

Wykorzystanie procesu Design Thinking pomogło nam w wielu różnych obszarach:

• Z perspektywy zarządzania projektami pozwoliło nam to jasno określić zakres projektu i zapobiec jego pełzaniu.
• Z biznesowego punktu widzenia pozwoliło nam to na dobranie cech, które wnoszą do biznesu rzeczywistą wartość.
• Z perspektywy rozwoju pomogło nam to dostrzec jasny cel tego, co musimy zbudować, zanim jeszcze zaczęliśmy go budować.
• Z perspektywy zespołu angażował wszystkich członków zespołu i pozwalał im na efektywną współpracę i wysłuchanie ich opinii na każdym etapie procesu.

Kiedy rozpoczęliśmy proces Design Thinking, klient spotkał się ze sceptycyzmem, ale kiedy skończyliśmy i otrzymaliśmy informację zwrotną od naszych klientów, od razu stało się jasne, że przedstawione przez nas kroki pomogły nam osiągnąć coś, co byłoby bardzo trudne lub inaczej niemożliwe. Zostało to docenione przez klienta i stało się jego wewnętrznym sztandarowym projektem dla przyszłych wyzwań.