Potrzeby napędzają zmianę w Autodesku. Case study o tym, jak wielka korporacja słucha swoich klientów i dla nich dokonuje zmian w swoim produkcie.
Autodesk to amerykańska międzynarodowa korporacja o wartości 2,5 miliarda dolarów, zajmująca się produkcją oprogramowania dla architektury, inżynierii, budownictwa, produkcji, mediów, edukacji i rozrywki. Firma ta operuje na 7 kontynentach, zatrudniając prawie 8 tys. pracowników.
W case study firmy opisanym przez UXPin poznajemy Uri Ashano – Senior UX Menedżera i jego zespół pracujący w Tel Awiwie nad mobilną aplikacją flagowego projektu AutoCAD 360. Projektowy team składa się z UX Designerów, Visual Designerów i Researchera, którzy ściśle współpracują z siedzibą główną w San Francisco, dbając o to, aby w ich produktach wybrzmiewała idea projektowania skoncentrowanego na użytkowniku.
Jak wyjaśnia Uri, firma widzi siebie jako magazyn wiedzy, a nie tylko jako dostawcę oprogramowania. Za każdym razem gdy zespół otrzymuje nowe zapytania dotyczące stworzenia kolejnej funkcjonalności, powtarza on ten sam proces, który podkreśla moc wspólnego projektowania, szczególnie na etapie researchu. […] Prace w zespole zaczynają się, gdy dostanie on informacje o potrzebie stworzenia nowej funkcjonalności od głównego teamu pracującego nad AutoCAD’em 360.
I właśnie tu na pierwszy plan wychodzi potrzeba. Zespół nie tworzy nowej funkcjonalności, aby uatrakcyjnić aplikację czy spełnić fantazję inwestorów. To użytkownik komunikuje swoja potrzebę, chociażby przez dział obsługi klienta, dając znać, że czegoś mu brakuje. Prawidłowe rozpoznanie potrzeby jest szalenie ważne, gdyż pomaga nam ono zrozumieć naszych użytkowników- ich oczekiwania i obawy, ale także nawyki i zachowania, co w późniejszych etapach przekłada się na lepsze dopasowanie do nich produktu, z którego będą chętniej korzystać.
Zazwyczaj scenariusz wygląda tak: ‘Architekt potrzebuje rysunku z AUTOCAD w ramach swojej pracy. Zabiera więc ze sobą iPad’a, by móc przeglądać swoje rysunki, modyfikować je i komentować, a następnie udostępnić zaktualizowane pliki współpracownikom. ” Zespół projektowy otwiera więc nowy projekt w Slacku, aby rozpocząć badać problem, który przyszła funkcja ma rozwiązać. Wstępne badanie polega na przeprowadzaniu wywiadów z lokalnymi firmami architektonicznymi i przeglądaniu zebranych danych w MixPanel. Zespół konsultuje również dane pozyskane z większych badań Autodesku, głównie skoncentrowanych wokół wieloplatformowego korzystania z AutoCAD i powiązanych z nim user flows.
To właśnie potrzeba napędza całą machinę zmian. Oczywiście samo jej zasygnalizowanie nie jest wystarczające do zaangażowania w pracę nad nową funkcjonalnością całego zespołu. Etap projektowy jest poprzedzony badaniami, które determinują późniejsze postępowanie zespołu. Prowadzenie rozmów z potencjalnymi użytkownikami programu pozwala badaczom stwierdzić czy dana potrzeba jest uzasadniona — a jeśli tak, to co się z nią wiąże. Ten kluczowy, a tak często pomijany etap badań, determinuje późniejszy wygląd funkcji i jej zachowanie. Jeśli potrzeby zostaną niewłaściwie zdefiniowane i przełożone tym samym na źle dobrane rozwiązanie, to nie tylko nie pomoże one użytkownikowi w osiągnięciu celu, ale wprawi go wręcz w konsternacje i zagubienie. Później może to skutkować negatywnym nastawieniem użytkownika w dalszym korzystaniu z produktu.
„Zawsze analizujemy przychodzące zapytania z pozycji zorientowanej na użytkowniku”- wyjaśnia Uri. „Wyciągamy nisko wiszące owoce, a następnie skupiamy się na bardziej ryzykownych elementach, które możemy usprawnić. Historie użytkowników są zawsze naszym punktem wyjścia do projektowania.”
Kluczem do sukcesu jest tu projektowanie z myślą o użytkowniku. Analizowanie ścieżki jaką przechodzi w aplikacji, czynności jakie musi dokonać, aby zaspokoić swoją potrzebę. A także upewnienie się, że cały proces jest ‘user friendly’. Nie tylko wpłynie to pozytywnie na relacje z naszymi użytkownikami, ale także pozwoli ograniczyć nam ryzyko związane z wypuszczaniem nowego produktu na rynek. Prototypy poprzedzone badaniami często pozwalają redukować koszty związane z późniejszymi poprawkami związanymi ze złym zdefiniowaniem potrzeb na pierwszym miejscu.
Gdy pojawi się już wizja funkcji, zespół szybko wkracza w fazę discovery, która jest jedną z najbardziej intensywnych i skupia się na współpracy’ – jak mówi Uri – „Nie chcemy stracić ani jednego kreatywnego umysłu w tym procesie ”. Zamiast wysyłać projektantów do pracy nad konkretnymi projektami, Uri angażuje wszystkich członków zespołu do badania nowych pomysłów. Dzięki temu podczas całodniowych warsztatów grupa wspólnie decyduje, które pomysły są wartościowe i należy je dalej rozwijać, by później przekuć je w user stories. „Pracując razem możemy uzyskać dwadzieścia świetnych pomysłów w ciągu dwudziestu minut” – komentuje Uri: „Nasza wspólna burza mózgów jest dużo bardziej skuteczna niż samodzielna praca poszczególnych designerów.”
Zespół projektowy Uri’ego przykłada również ogromną wagę do kolektywnego wytwarzania wiedzy i generowania pomysłów. Na początkowych etapach jest to nieoceniony sposób drążenia problemów i znajdowania najlepszych rozwiązań. Nie zawsze pierwsze rozwiązania są najlepsze, więc w tym przypadku, im jest ich więcej, tym lepiej. Po zakończeniu mapowania potrzeb użytkowników i ustaleniu priorytetów, w końcowym etapie burzy mózgów, odbywa się także głosowanie nad zebranymi pomysłami. Najczęściej gromadzone są one w formie karteczek samoprzylepnych na tablicy. Te warte uwagi, są później dalej rozwijane.
Uri zauważył, że im wcześniej można zaangażować programistów i produkt menedżerów w projekt, a tym samym w podejmowanie decyzji, tym lepiej. To właśnie dlatego ich zespoły są również fizycznie położone blisko siebie, aby dzieląc miejsca spotkań mogli spędzać ze sobą wiele czasu i wymieniać się koncepcjami.
Gdy potrzeby są zdefiniowane i mają już swoje potencjalne rozwiązania, a podstawowe funkcjonalności zostały uzgodnione w zespole, przychodzi czas na zastąpienie burzy mózgów konkretnymi działaniami. W tym etapie uczestniczą jedynie osoby niezbędne do dowiezienia produktu.
Gdy poszczególne zadania zostaną rozdzielone między członków zespołu, designerzy zaczynają wspólne projektować wstępne wireframey i user flowy do każdego scenariusza użytkownika. Zaczynają oni również planować ich flow, a developerzy podsumowują wymagania techniczne. Podczas gdy designerzy zaczynają planować flow, programiści dobierają stack technologiczny. Aby zebrać wszystkie pozyskane informacje w jednym miejscu, zespół AutoCAD 360 tworzy PRD (z ang. product requirement document), który koncentruje się na gromadzeniu wytycznych.
W przypadku znacznej części projektów zespół AutoCAD 360 iteruje większość modeli szkieletowych do statycznych, zaawansowanych makiet, a następnie bezpośrednio do kodu. Ze względu na ograniczenia czasowe, tworzą oni jedynie prototypy dla nowych modeli interakcji lub potencjalnie problematycznych flow (np. z wieloma przejściami). Szczegółowość prototypu zależy również od tego, jaki problem ma on rozwiązać. Przykładowo, zespół Uri’ego tworzy prototypy typu low-fidelity gdy testuje nowe interakcje, a high-fidelity gdy testują branding czy kolorystykę.
Końcowym etapem są testy użyteczności, podczas których wychodzi na jaw, czy dana potrzeba została zaspokojona i czy nowa funkcjonalność spełnia oczekiwania użytkowników. Badania te przeprowadzane są zazwyczaj na 5-10 osobach. Nawet po pozytywnych wynikach testów, zespół badawczy nie jest w stanie powiedzieć, że jego praca nad danych produktem dobiegła końca. W miarę upływu czasu nowe potrzeby zostaną zidentyfikowane i będzie on potrzebował nowych iteracji, gdyż proces projektowania w przypadku produktów cyfrowych nigdy się nie kończy. Koło projektowe zamyka, a zarazem otwiera kolejna potrzeba, która znów za jakiś czas zostanie rozpoznana i będzie wymagała zaspokojenia.
