Case Studies

Nowa architektura aplikacji webowej w 2 tygodnie?

Stworzenie intuicyjnej platformy do tworzenia i przeprowadzania testów. Jak połączyć funkcje znajdujące się obecnie na 3 różnych platformach w jedno rozwiązanie? O tym, jak pomogliśmy klientowi stworzyć rozwiązanie skrojone na miarę, przeczytacie w poniższym  case study z tworzenia architektury aplikacji webowej dla klienta z branży edukacyjnej.

Klient
BSCS Science Learning (organizacja non-profit zajmująca się transformacją edukacji naukowej poprzez innowacje oparte na badaniach)
Cel
Stworzenie nowej architektury informacji
Okres współpracy
styczeń 2020
Liczba sprintów
2
Liczba osób w projekcie
2

Kontekst projektu

W grudniu 2019 roku zgłosił się do nas klient – BSCS Science Learning, amerykańska organizacja non-profit zajmująca się transformacją edukacji naukowej poprzez innowacje oparte na badaniach. Prowadzone przez nią badania opierają się między innymi na wykonywaniu testów wielokrotnego wyboru na dużej próbie studentów, a używane w nich pytania są przygotowywane przez specjalny zespół badaczy, dbających o jak najwyższą jakość przekazywanych informacji. 

Projekt nietypowy – działający na zasadzie NGO, z planem niekomercyjnego produktu do wewnętrznego użytku. Działając obecnie na 3 różnych platformach i nie mogąc znaleźć odpowiedniego narzędzia zawierającego wszystkie z niezbędnych dla nich funkcji, postanowili stworzyć własną, wewnętrzną aplikację.  

Proces pracy nad stworzeniem architektury aplikacji webowej podzieliliśmy na 2 sprinty (2 tygodnie) przy zaangażowaniu dwóch osób do projektu. Opracowane przez nas informacje miały być wstępem do dalszej, wspólnej pracy nad witryną – tworzeniem makiet UX i UI aplikacji. 

Sprint 1 – Poznajemy produkt oraz potrzeby użytkowników

Poznanie realnych potrzeb użytkowych

Naszą pracę rozpoczęliśmy od poznania samego klienta – podczas naszej pierwszej rozmowy wprowadzającej wykorzystaliśmy dwa narzędzia: Team Canvas oraz Lean Canvas. Ze względu na ograniczoną formę kontaktu (video-rozmowa), zmodyfikowaliśmy tradycyjną formę warsztatów do pogłębionego wywiadu. Pytania zawierające się w Team Canvas pozwoliły nam odkryć zarówno potrzeby stojące chęcią wprowadzenia zmian w projekcie, personalne cele klienta, jak i również formę wzajemnej współpracy (co w wypadku tego projektu okazało się kluczowe). Lean Canvas wzbogacił nas o wiedzę o samym projekcie – pozwolił poznać organizację od środka, jej sposób działania oraz pozostałych interesariuszy projektu. Zwłaszcza w wypadku firmy działającej w innej strefie kulturowej, poznanie ich podejścia oraz sposobu pracy, ułatwia zbudowanie holistycznego wglądu w cały projekt.

Dzięki temu, że klient jest jednocześnie jednym z głównych odbiorców produktu (badacz), mogliśmy wspólnie przejść przez proces tworzenia materiałów w aplikacji, poznając jego perspektywę oraz metodykę pracy. Pomimo dzielących nas ponad 8 tysięcy kilometrów, bezpośrednie obserwowanie jego akcji na udostępnionym ekranie monitora pozwoliło na zbudowanie ścieżki użytkownika, poznanie wszystkich funkcji oraz problemów obecnego rozwiązania.

User Stories i ich weryfikacja

Po wstępnym zapoznaniu, dalsze prace nad analizą zaczęliśmy od samodzielnego poznania narzędzia. Dzięki dostępowi do każdej z platform, mogliśmy przejrzeć każdą podstronę, zarysowując user stories dla wyróżnionych przez klienta person. Udostępnione nam wstępnie zarysowane User Stories (krótki opis akcji które użytkownik chce móc wykonywać) przez współpracujący z nami zespół developerski Bejamas, połączone z samodzielnym okrywaniem rozwiązania i obserwacją badaczy, pozwoliło na zarysowanie obszernego spisu funkcjonalności dla każdej z istniejących obecnie platform. O ile przy odkrywaniu projektu niezbędne było dla nas spisanie wszystkich możliwych akcji, tak wiedzieliśmy, że nie jesteśmy w stanie przenieść ich całościowo do nowego rozwiązania. W tej sytuacji jako narzędzie walidacyjne posłużyła nam metoda MoSCoW.

Metoda MoSCoW jest techniką priorytetyzacji, wykorzystywaną w celu ustalenia jaką wartość ma dostarczenie każdego z analizowanych elementów. Wyodrębniane są 4 kategorie, zgodnie z majuskułą w nazwie: Must (M), Should (S), Could (C), Won’t (W). Najważniejsze dla każdego projektu są dwie z nich: pierwsza i ostatnia. Must oznacza kategorie, które koniecznie muszą znaleźć się w projekcie aby spełniał swoje podstawowe funkcje i oczekiwania użytkownika. Won’t są akcjami których nie powinniśmy uwzględniać w rozwiązaniu, gdyż nie wnoszą dodatniej wartości dla użytkownika lub wręcz mu przeszkadzają. Dzięki prostemu oznaczeniu każdego przypadku w opisanych User stories, oraz walidacji naszych wyborów z klientem, udało się nam bardzo szybko wyeliminować dużą część zbędnych opcji oraz wyróżnić niezbędne elementy do sprawnego funkcjonowania całego procesu badawczego

Persony użytkowników

Odkrywane przez nas user stories oparte były na 3 głównych personach (pokrywających się z istniejącymi 3 platformami) – badaczu, nauczycielu oraz studencie. Zagłębiając się jednak w produkt, opracowaliśmy na koniec 5 person – dodatkową personę nauczyciela oraz użytkowania publicznego. 

Przy tak dużej ilości różnorodnych użytkowników, konieczne było wydzielenie poziomów dostępu: publicznego, dla użytkowników z kontem ogólnym, studentów oraz dla badaczy. Zwiększenie ilości person spowodowane było zauważeniem odmiennych celów oraz zachowań osób które do tej pory uważane były za jedną personę.

Sprint 2 – Architektura aplikacji webowej, czyli złączmy wnioski w całość

Organizacja informacji

Kończąc pierwszy sprint mieliśmy do dyspozycji szczegółowy raport, persony, godziny spędzone na rozmowach z klientem oraz ogromne ilości notatek. Pojawiło się pytanie – jak połączyć tak ogromną ilość informacji w jedną, intuicyjną platformę, bez pominięcia najmniejszego szczegółu wartościowego dla odbiorcy? Zaczęliśmy więc klasycznie – od ogółu.

Zebrane i przygotowane wcześniej materiały zgromadziliśmy ponownie w postaci tabel, gdzie za pomocą kolorów grupowaliśmy poszczególne user stories. Podzieliliśmy je na 4 główne grupy, które miały być trzonem na którym dalej rozwinie się architektura aplikacji webowej.

Kolejnym krokiem było uszczegółowienie dostępu zgodnie z personą. Śledząc poszczególne ścieżki użytkowników zadawaliśmy sobie masę pytań – jaki dostęp do tego samego podglądu pytania będą miały osoby publiczne, a jaki badacze? Czy studenci powinni mieć również dostęp do publicznej platformy? W jaki sposób będą dodawane nowe projekty? Nasze myślenie odpowiadało nie tylko za uporządkowanie zgromadzonych informacji w czytelną architekturę – niezbędne było myślenie już o rozwiązaniach projektowych, aby mieć pewność, że architektura jest nie tylko czytelna ale również funkcjonalna pod każdym kątem.

Warsztaty walidacyjne

Mając już pełen zestaw informacji, przystąpiliśmy do pracy jak na prawdziwych miłośników warsztatów przystało – na warsztatach walidacyjnych – pracując za pomocą karteczek samoprzylepnych. Działanie w ten sposób nie tylko lepiej pobudza kreatywne myślenie niż praca przed komputerem, ale pozwala również na szybkie wprowadzanie zmian i nowych ścieżek w architekturze – przechodząc ścieżką konkretnego użytkownika, mogliśmy łatwo sprawdzić, czy proponowana architektura aplikacji webowej jest czytelna i intuicyjna. 

Karteczki zostały podzielone kolorystycznie zgodnie z dostępem użytkowników – każdy kolejny kolor miał większy zakres dostępu niż poprzedni. Pozwoliło nam zastosowanie jednej karteczki do konkretnej sekcji, nawet jeśli korzystały z niej 2 osoby na różnych poziomach dostępu. W wypadku architektury, gdzie do jednego elementu występowało tak wiele dostępów z różnymi ograniczeniami, ułatwiło to czytelne zobrazowanie całej architektury bez niepotrzebnego dublowania podstron.

Opracowana przez nas architektura trafia do klienta w zdigitalizowanej wersji jeszcze tego samego dnia, wraz z legendą oraz krótkim podsumowaniem. Na podstawie ogólnego zarysu architektury aplikacji webowej, przygotowaliśmy również szczegółowe opracowanie dla każdej z podstron w postaci pliku excel, gdzie umieściliśmy wszystkie niezbędne informacje o znajdujących się na nich informacjach, funkcjonalnościach, poziomach dostępu oraz ewentualnych wytycznych

Podsumowanie naszej pracy – w liczbach i nie tylko

5

Person

163

Pozycje w exelu

35

Stron raportu

Co dalej z aplikacją? W obecnym momencie nasz zespół wdraża opracowane przez nas materiały w życie, projektując wygląd całej aplikacji. Mamy nadzieję, że już w niedługim czasie rozwiązanie będzie mogło służyć badaczom, ułatwiając im pracę nad doskonaleniem technik nauczania dla kolejnych pokoleń.

Narzędzia wykorzystane w projekcie

  • Team Canvas
  • Lean Canvas
  • Persony
  • Metoda MOSCoW

Case study to za mało?

Chcesz poznać cały proces i dowiedzieć się, jak mógłby wyglądać w Twojej organizacji?

Umów się na bezpłatną konsultację

Zespół projektowy, czyli kto za co odpowiadał

Autor Case Study

Agnieszka Zygmunt Lean UX Researcher, Industrial Design & Service Designer
Agnieszka dokonuje analiz, przeprowadza badania oraz eksperymenty. Specjalizuje się w badaniach z zakresu Product Discovery i pomaga tworzyć rozwiązania skoncentrowane na realnych potrzebach użytkownika.

Holistycznie patrzy na proces projektowania, biorąc pod uwagę wszystkie czynniki mogące wpływać na ostateczne doświadczenie użytkownika. Łączy w swojej pracy zdolności analityczne z wysokim poziomem empatii oraz miłością do nauki.

Współtwórczyni audycji Proste Rozmowy, prywatnie zaangażowana w projekty non-profit wspomagające najbardziej potrzebujących odbiorców.

Pozostali członkowie zespołu

Tomasz Osowski Lean UX & Service Designer w Project: People
Pomaga firmom stworzyć doskonałe doświadczenie użytkownika zapewniając jednocześnie odpowiednią rentowność biznesu. Jego zadanie to stworzyć produkty i usługi, które są potrzebne i przynoszą satysfakcję zarówno odbiorcom jak i właścicielom biznesu.

Certyfikowany Trener Biznesu i rozwoju osobistego, Certyfikowany moderator Design Thinking. Przedsiębiorca od kilku lat. Szczerze zakochany w metodologii Lean. Zawsze stara się dostarczyć produkt na rynek jak najszybciej przy najmniejszym nakładzie kapitałowym.

Współpracował z firmami: T-mobile, Ecard, inPost, ING, Nationale Nederlanden, Brainly, Publicis, Netguru. Organizator konferencji DesignWays Conf.