Case Studies

Aplikacja dla wszystkich, czyli proces tworzenia produktu white label

W czerwcu 2019 dla jednego z naszych klientów, mieliśmy okazję projektować platformę White Label, czyli taką, którą w prosty i szybki sposób można dopasować do potrzeb dowolnego klienta. Poznaj proces przygotowania i stworzenia nowej wersji produktu White Label.

Klient
NDA
Cel
platforma w formie produktu White Label
Okres współpracy
czerwiec 2019
Liczba sprintów
4
Liczba osób w projekcie
1

Kontekst projektu

Rozpoczynając współpracę wiedzieliśmy, że bardzo duży nacisk musimy położyć na analizę. To klucz w tworzeniu produktów White Label. Poprzednia wersja aplikacji została stworzona “na szybko”, na aktualne potrzeby, do obsługi klientów korporacyjnych. Była oparta o jeden z trendów w projektowaniu – material design, ale zaprojektowana bez większej analizy.

Naszym celem było w 3 tygodnie opracować kompletny Design wersji Systemu CRM, do zarządzania klientami na rynkach kapitałowych, w branży funduszy inwestycyjnych.

Problemy projektowe, które napotkaliśmy:

  • ograniczony czas,
  • zaawansowana terminologia i procesy wewnątrz systemu,
  • aplikacja wyświetlana tylko na specjalnie przygotowanym środowisku, 
  • ograniczony dostęp do grupy docelowej.

Sprint 1: Warsztat & analiza

Warsztat stacjonarny u klienta, aby dobrze poznać jego potrzeby

Start projektu rozpoczął się od wylotu do siedziby firmy klienta. W związku z zawiłą terminologią projektu ważne było poznanie środowiska pracy, a to właśnie bezpośredni kontakt pozwala nawiązać lepsze relacje w projekcie sprzyjające obustronnemu zrozumieniu.

Warsztat kick-offowy zawsze pełni dla nas kluczową rolę, nie inaczej jest, kiedy projektujemy produkt White Label. Podczas warsztatów na miejscu dokonaliśmy przeglądu aplikacji. Uszeregowaliśmy flow od najważniejszego, do najmniej istotnego oraz przeanalizowaliśmy poszczególne ścieżki użytkowników.

Kolejnym etapem były szybkie wywiady z użytkownikami. To właśnie podczas tych rozmów okazało się, że osoby korzystające z programu, pracowały na dwóch 27” monitorach, wspierali proces salesforcem (narzędziem do obsługi klienta) i inną wewnętrzną platformą. Dużo tego! Stworzyliśmy więc daily routine, aby wiedzieć jak przebudowywane narzędzie ma wpisać się w ich codzienny tryb pracy.

Na sam koniec razem z Product Ownerem ustaliliśmy priorytet ścieżek użytkownika i naszkicowaliśmy pierwsze ekrany Low-fi zgodne z metodyką tworzenia produktu White Label.

Podczas warsztatów ustaliliśmy:

  • priorytet prac w poszczególnych flow,
  • wspólne oczekiwania w stosunku do projektu,
  • zasady współpracy: codzienny daily oraz design review raz w tygodniu,
  • model akceptacji wersji.

Podczas wywiadów uzyskaliśmy input do dalszych prac:

  • rozdzielczość (full hd) i toolbox narzędziowy,
  • błędy niedostrzegane przez przełożonych,
  • lepsze zrozumienie narzędzia,
  • oczekiwania użytkowników.

W tej fazie wykorzystaliśmy takie narzędzia & metody pracy jak: wywiady indywidualne, Daily Routine, Live Testy narzędzia, kartę i ołówek 🙂

Chcesz lepiej pracować nad strategią swojej firmy?

Dołącz do naszego newslettera i zyskaj dostęp do Biblioteczki Narzędzi Lean, gdzie znajdziesz 30+ narzędzi i szablonów. Za darmo.



    Zgadzam się na przetwarzanie moich danych osobowych przez Project: People Sp. z o.o. w celu komunikacji marketingowej, a tym samym wysyłania mi newslettera, informacji o usługach, promocjach lub nowościach zgodnie z Polityką prywatności

    Analiza danych zastanych 

    Po warsztatach i powrocie do biura w Krakowie cała współpraca przybrała formę zdalną. Rozpoczęliśmy analizowanie informacji otrzymanych i zebranych od klienta.

    Znając priorytetowe zadania dla użytkowników, zaczęliśmy się zastanawiać: w jaki sposób użytkownicy mogą je zrealizować? Dlaczego aktualna architektura informacji we wdrożonym narzędziu nie działa? Z których funkcji użytkownicy korzystają najczęściej, a które zajmują tylko miejsce na ekranie?

    W ten oto sposób zaprojektowaliśmy architekturę informacji oraz spiorytetyzowaliśmy konkretne akcje w poszczególnych flow. W rezultacie doprecyzowaliśmy dokładnie wszystkie wymagania dotyczące produktu White Label :).

    W tej fazie ustaliliśmy:

    • listę ekranów i stanów potrzebnych w projekcie,
    • priorytetyzację funkcjonalności,
    • zwizualizowanie aplikacji i przepływu użytkowników.

    Architektura informacji powstała przy użyciu narzędzia draw.io. Use case, czyli przykładowe ścieżki korzystania z produktu przez użytkowników, tworzyliśmy z wykorzystaniem Excela, 🙂

    Sprint 2: Produkt White Label dla deweloperów

    Kiedy zebraliśmy już wszystkie potrzebne informacje, mogliśmy przejść do projektowania. W związku z krótkim terminem oddania projektu, zleceniodawca zdecydował się na pominięcie fazy makiet, czego efektem było projektowanie od razu finalnego designu. 

    Jednym z głównych założeń projektu było przygotowanie go w prosty sposób, czyli stworzenie produktu White Label. Zanim jednak przejdziemy do projektowania – warto rozważyć poniższe pytania.

    Pytania, które należy rozważyć:

    • W jaki sposób to narzędzie będzie customizowane?
    • Jak sprawić, aby narzędzie wyglądało “ładnie”, niezależnie od wybranego przez klienta koloru?
    • Jak dostosować czcionki i typografie, aby były elastyczne?
    • Co z potencjalną modyfikacją danych?
    • Czy brać pod uwagę zasady accessibility, czyli dostępności dla osób z niepełnosprawnościami, np. niedowidzących?

    I czas przystąpić do pracy, czyli zaprojektowania style guide’a (zasady kompozycji i stylu), na którym ustaliliśmy parę zasad działania produktu White Label.

    • Użytkownik może edytować tylko 2 kolory w aplikacji.
    • Kiedy programista otrzyma kolory zdefiniowane przez klienta, na tej podstawie “przeliczy” kolory używane w pozostałych miejscach, jak na przykład tło. Będzie operował wartością opacity, w związku z czym aplikacja zawsze będzie wyglądała odpowiednio (niezależnie od kolorów paleta barw będzie zbieżna).

     

    • Zostały określone tak zwane kolory Fixed, czyli kolory które będą stałe, niezależnie od pozostałych zmian dokonanych w projekcie.  Mowa tutaj o kolorach statów takich jak error czy ostrzeżenie.

     

    • Czcionki zostały oparte o Ratio 1.618. Podstawowy rozmiar to 16px. Każdy kolejny rozmiar to wielokrotność pomnożona przez ratio.

     

    • Zostały też określone zasady dostępności dla osób niedowidzących. Co oznacza, że poszczególne kolory powinny mieć określony kontrast.
    • Stworzyliśmy też ogólne zasady interakcji i informacji o stanach błędu i sukcesu.
    • Zaprojektowaliśmy również wspólne zasady dla elementów klikalnych, np. wszystko co jest klikalne posiada określony kolor wraz z ikoną.
    • Przewidzieliśmy również zachowania przycisków oraz inputów w stanach: natywny, active, focus, filled.

    Oczywiście zaproponowany style guide był na wstępnym etapie. Od niego jednak należało zacząć, gdyż nasz sprint wyprzedzał sprint Front-end Developerów o tydzień. W późniejszym procesie niektóre elementy uległy zmianie, jednak ogólne kwestie dotyczące zasad tworzenia produktu White Label pozostały w taki sposób, jak zaplanowaliśmy.

    Wykorzystywane narzędzia:

    • Sketch,
    • Invision,
    • Kartka, ołówek.

    Sprint 3: Design i Guerilla Testy


    Design

    Kiedy wiemy już co robimy i przy pomocy jakich komponentów, należy wreszcie zaprojektować jakieś ekrany. 😉 Wydawać by się mogło, że jeśli wszystko jest gotowe do tworzenia produktu White Label, to wykonanie poszczególnych elementów powinno być już tylko formalnością.

    Jak to jednak w projekcie bywa, przy wizualizacji kolejnych ekranów napotyka się nowe wyzwania i możliwości. Zaczęliśmy projektowanie ekranów od pierwszego elementu we flow, czyli od etapu, kiedy użytkownik wchodzi do aplikacji. Problem? Klient naciska na rozpoczęcie projektowania od najważniejszego elementu. Dlatego wytłumaczyliśmy mu logikę takiego działania, tzn:

    W naturalnym flow użytkownik nigdy nie zobaczy “najważniejszego” ekranu jako pierwszego. W związku z tym, jego doświadczenie zaczyna się dużo wcześniej, jeszcze przed tym ekranem. Wzorce, które wypracujemy na poprzednich ekranach (np. nauczymy go, że zielony kolor wraz z ikonką na elemencie z cieniem to coś klikalnego), bezpośrednio przekładają się na kolejne ekrany. 

    Dlatego też zaprojektowaliśmy pierwszą wersję ekranu początkowego, potem dopiero wyników wyszukiwania, a na samym końcu pojedynczą stronę użytkownika. Po zakończeniu projektowania ekran był przekazywany do Product Ownera oraz do Head of Product, którzy weryfikowali z grupą docelową, w jaki sposób ekrany są klikane (rozumiane). W ten sposób iterowaliśmy blisko 7 wersji najważniejszych ekranów, aby mieć pewność, że użytkownicy nie tylko w pełni rozumieją, ale również będą używać odpowiednich funkcji.

    Guerilla Tests

    Po zaprojektowaniu całościowego flow zaprosiliśmy na testy faktycznych użytkowników narzędzia. Chcieliśmy zwalidować, jak za pomocą nowego designu rozwiązujemy ich problemy. Na bieżąco sprawdzaliśmy, jak rozumieją poszczególne elementy. Polegało to na szybkim testowaniu poszczególnych elementów w postaci pokazywania im różnych alternatywnych wersji oraz pytania, jak rozumieją projekt.

    Krok ten trwał najdłużej z całego procesu ze względu na czasochłonność projektowania. W czasie kolejnych iteracji doszło do modyfikacji style guide, który na bieżąco był aktualizowany. Oczywiście proces ten generował usprawnienia dla deweloperów. Każda zmiana była jednak konsultowana z Front-end Developerami, aby sensownie je wprowadzić. W ten sposób klient zaoszczędził, ponieważ pozbył się kosztów związanych z poprawkami, które miałyby miejsce po zakończeniu projektu.

    Pracujemy w leanie. Należy więc pamiętać, że proces ulepszania aplikacji, według tej metodyki, może trwać w nieskończoność. Jako, że aplikacja to MVP, ustaliliśmy z góry satysfakcjonujący moment dla każdego interesariusza, który był momentem zakończenia prac.

    W czasie tego etapu:

    • zaprojektowaliśmy kolejne ekrany,
    • dokonaliśmy oprawek i bieżących aktualizacji na podstawie obserwacji i feedbacku z użytkownikami.

    Wykorzystywane narzędzia:

    • Sketch,
    • Invision,
    • Zepplin,
    • Live testy,
    • Guerilla testy.

    Sprint 4: Wdrożenie

    Wdrożenie odbywało się równocześnie z naszymi pracami począwszy od drugiego sprintu. Po oddaniu pliku i uporządkowaniu Zepplina (narzędzie do współpracy z deweloperami), cały czas nadzorowaliśmy i konsultowaliśmy poziom i jakość wdrożenia. Przykładowo: kiedy pojawiały się wątpliwości dotyczące długości animacji, czy ładownia wyników wyszukiania, wprowadzaliśmy drobne poprawki w designie. 

    Podsumowanie projektu – w liczbach i nie tylko

    Proces tworzenia aplikacji trwał trzy i pół tygodnia. Czy udało się zrealizować wszystkie cele? Oczywiście, że nie. Jest to zbyt krótki okres, aby być pewnym, że nic nie zostało pominięte. 

    Jednakże cel założony na początku warsztatów, czyli zaprojektowanie produktu White Label, został osiągnięty. Z aplikacji kompletnie nieużywanej powstały solidne podstawy do rozwoju. Zostały przemyślane elementy techniczne, które będą wykorzystywane w dalszych pracach. Co więcej, aplikacja powstawała w myśl User Centered Design.

    52

    Liczba ekranów

    4

    tygodnie na przygotowanie desingu

    5

    osób w zespole projektowym

    Narzędzia, metody i techniki wykorzystane w projekcie

    • Wywiady indywidualne,
    • Daily Routine,
    • Live testy narzędzia,
    • Draw.io,
    • Excel,
    • Sketch,
    • Invision,
    • Zeplin,
    • Live testy,
    • Guerilla testy,
    • kartka i ołówek.

    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

    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.