Case Studies

Jak skrócić czas pracy adwokata? – Redesign aplikacji dla prawników w 3 tygodnie

Usprawnienie pracy adwokatów i poprawienie ich wydajności – to była idea stojąca za narzędziem naszego klienta. Jak poprawić jego działanie i sprawić, by był bardziej użyteczny? To było wyzwanie dla nas. O tym, jak zmieniliśmy dzień pracy prawników z Wielkiej Brytanii, przeczytacie w naszym case study z redesignu aplikacji.

Klient
prawnicy z Wielkiej Brytanii
Cel
redesign aplikacji dla prawników
Okres współpracy
sierpień 2018
Liczba sprintów
3
Liczba osób w projekcie
2

Kontekst projektu

W sierpniu 2018 roku zgłosił się do nas klient – zespół prawników z Wielkiej Brytanii, który rozwijał aplikację mającą za zadanie usprawnić pracę adwokatów, poprawić ich wydajność i zwiększyć dokładność. Celem naszej współpracy, było zweryfikowanie przydatności narzędzia w codziennej pracy prawników oraz jego redesign w taki sposób, by było jak najbardziej użyteczne. 

Prawo w krajach anglosaskich różni się w znacznym stopniu od prawa obowiązującego w Polsce. System prawny w Wielkiej Brytanii opiera się między innymi na prawie precedensowym (tzw. case lub commonlaw), gdzie podstawę stanowią wyroki wydane w dotychczasowych sprawach sądowych. 

Obowiązujący system wymusza z kolei na adwokatach pracę na bardzo długich dokumentach, gdzie terminy prawnicze i różnego rodzaju definicje są umieszczone z reguły na początku lub na końcu takiego pisma. Prawnik pracujący nad tego typu dokumentem jest zmuszony, co jakiś czas wracać do sekcji z definicjami, by sprawdzać, czy dana definicja współgra z kontekstem reszty dokumentu. 

System budowany przez naszego klienta miał za zadanie ułatwić adwokatom pracę na długich tekstach w taki sposób, że prawnik czytający dany przepis nigdy nie traci jego kontekstu i w trakcie kontroli całego dokumentu ma możliwość przeglądania i zmieniania zawartych w nim definicji. 

Proces pracy podzieliliśmy na 3 sprinty (3 tygodnie) przy zaangażowaniu dwóch osób do projektu na różnych etapach pracy.

Sprint 1: UX research i testy użyteczności – poznajemy biznes klienta i komu klient chce sprzedawać

Celem pierwszego sprintu było zapoznanie się z narzędziem i zebranie jak największej ilości  informacji od klienta na temat jego pomysłu oraz zbadanie potrzeb grupy docelowej, a w szczególności:

  • Określenie typowego dnia prawnika 
  • Poznanie procesu pracy z dokumentami i problemów, które dotykają użytkowników podczas pracy z nimi 
  • Określenie nawyków związanych z aktualnymi metodami rozwiązywania tych problemów  
  • Sprawdzenie, jak grupa docelowa reaguje na ideę stojącą za narzędziem i czy widzi potencjał na zastosowanie go w swojej pracy 
  • Zweryfikowanie użyteczności aktualnej wersji narzędzia 

Wywiad z klientem – zbieramy informacje o pomyśle klienta 

Pracę nad projektem rozpoczęliśmy od wywiadów z klientem w celu zebrania informacji o narzędziu. Celem takich wywiadów było pozyskanie następujących informacji:

  • jaka motywacja stoi za projektem?
  • jaki jest jego cel?
  • co klient chce osiągnąć za pomocą aplikacji?
  • jak wygląda cały zespół projektowy?
  • kto jest grupą odbiorców?
  • jaki problem użytkowników ma rozwiązać aplikacja?

Ponadto zależało nam na zapoznaniu się z narzędziem i przetestowaniu go przy pracy na dokumentach, na których na co dzień pracują prawnicy, by zapoznać się z mechaniką stojącą za aplikacją i wstępnie wyłapać te obszary, w których użytkownicy mogą się zgubić.

Wywiady z grupą docelową połączone z testami użyteczności pierwotnej wersji aplikacji

Po wywiadach z klientem i wstępnych testach rozpoczęliśmy przygotowania do badania jakościowego użytkowników (wywiady indywidualne via Skype), połączonego z testem użyteczności aktualnej wersji narzędzia. 

Wywiady indywidualne pozwalają na szybkie zebranie informacji o grupie docelowej, umożliwiają poznanie odbiorcy, jej potrzeb i problemów, które ma rozwiązywać dane narzędzie. W naszym wypadku połączyliśmy je z testem użyteczności aplikacji. Chcieliśmy zweryfikować nie tylko, czy dany problem faktycznie występuje, ale odpowiedzieć na pytanie, czy stworzone narzędzie jest już rozwiązaniem tego problemu oraz jakich usprawnień wymaga. 

Zależało nam przede wszystkim na pozyskaniu informacji o tym, jak użytkownicy rozumieją aplikację, a zwłaszcza: 

  • Jak reagują na zaproponowane rozwiązanie? 
  • Co im się podoba w aktualnym narzędziu?
  • Jakie napotykają problemy podczas korzystania z niego? 
  • Jakich funkcji im brakuje?

Sprint 2: Analiza wyników UX researchu – jakie informacje udało nam się uzyskać

Drugi sprint poświęciliśmy w całości na analizę zebranych materiałów i wyciągnięcie z nich najważniejszych wniosków. 

Z informacji, jakie udało nam się zebrać wynikało, że podczas wykonywania codziennych obowiązków prawnicy spędzają około 80% swojego czasu na pracy z dokumentami – na ich przygotowaniu, weryfikowaniu i przerabianiu. 

Ich głównym problemem podczas pracy na bardzo długich dokumentach było sprawdzanie pojawiających się w nich definicji – weryfikowanie, czy dana definicja w tekście w każdym momencie występowania współgra z definicją podaną na początku lub końcu dokumentu. 

Pozyskaliśmy również informacje o sposobach, dzięki którym prawnicy radzą sobie z tym problemem:

  • Używanie dwóch monitorów, bądź dzielenia ekranów – na jednym ekranie prawnicy zawsze zostawiali początek dokumentu z definicjami, a na drugim przeglądali tą część dokumentu, nad którą aktualnie pracowali
  • Drukowanie całego dokumentu – nasi badani bardzo często drukowali cały dokument, bądź sekcję z definicjami, by móc na bieżąco się do niej odnosić
  • Używanie ctrl+F – prawnicy wyszukiwali dane terminy poprzez skróty klawiszowe 

Typowy dzień prawnika zobrazowaliśmy za pomocą User Journey Map (narzędzie do opisu ścieżki korzystania z danego produktu/usługi) skupiając się na fazie, którą określiliśmy jako aktywną – gdy prawnik nie uczestniczy w spotkaniach i rozprawach, a pracuje bezpośrednio na dokumentach oraz czyta i odpisuje na maile. 

Pokazując narzędzie naszej grupie docelowej zyskaliśmy potwierdzenie, że może ono im pomóc w codziennej pracy i jest rozwiązaniem ich problemów i frustracji. Dodatkowo zyskaliśmy też pewność, że wymaga ono kilku usprawnień i poprawy użyteczności, ponieważ natknęliśmy się na momenty, w których użytkownicy nie radzili sobie z jego obsługą. 

Wynikiem przeprowadzonego researchu były dwie persony, których problemy chcieliśmy rozwiązać, dzięki narzędziu naszego klienta: 

  • Josh – doświadczony prawnik, multizadaniowy analityk, któremu zależy na poszukiwaniu narzędzi, które maksymalnie przyspieszą mu pracę.  

 

  • Samantha – poukładana, dobrze zorganizowana i skrupulatna prawniczka, której zależy na przygotowywaniu dokumentów bez żadnych pomyłek.

Sprint 3: UX design – prototyp nowej wersji aplikacji, czyli jak wykorzystaliśmy informacje zebrane od użytkowników

Po etapie analizy rozpoczęliśmy budowę prototypu w podejściu leanowym (szybko, eksperymentalnie, w ciągłym kontakcie z wszystkimi osobami zaangażowanymi w projekt), bazując na narzędziu, które dostarczył nam klient. Każdy pomysł konsultowaliśmy współpracując ściśle zarówno z klientem, deweloperami, jak i użytkownikami produktu.

Pracę skończyliśmy dostarczając klientowi pełny prototyp (32 ekrany) gotowy do wdrożenia. Nawet już po oficjalnie zakończonej współpracy byliśmy do dyspozycji teamu deweloperskiego i na bieżąco konsultowaliśmy z nimi wszelkie poprawki.  

Podsumowanie projektu – w liczbach i nie tylko

2

persony

10.5

godziny rozmów

7

wywiadów indywidualnych

32

ekranu prototypu

 

Co dalej z aplikacją? Otrzymaliśmy od klienta informacje, że team developerski ukończył prace nad narzędziem i aplikacja jest obecnie wdrażana do jednej z firm prawniczych w Wielkiej Brytanii.

A tak współpracę z nami ocenił klient:

“Potrzebujesz pomysłowości przy tworzeniu legalnego produktu technologicznego, ponieważ większość prawników jest nietechniczna i nieufna wobec produktów technologicznych, które je zastępują. Podczas projektowania Define chcieliśmy upewnić się, że zróżnicowany zestaw prawników może pomóc w stworzeniu interfejsu użytkownika i UX. Project: People wykroczyli poza zakres zapewnienia, że udało nam się zaprojektować nasz produkt i nie możemy się doczekać, aby ponownie razem pracować.” 

Narzędzia

  • User Journey Map – narzędzie wykorzystywane do poukładania ścieżki użytkownika, zaznaczenia jego flustracji i problemów podczas interakcji z danym systemem/wykonywania danych zadań

Zespół projektowy, czyli kto za co odpowiadał

Autor Case Study

Katarzyna Smoleń Lean UX Designer & Researcher
Na co dzień pracuje przy projektach UXowych i strategicznych, gdzie zajmuje się głównie prowadzeniem researchu, weryfikowaniem pomysłów na nowe produkty czy usługi oraz tworzeniem strategii biznesowych. Wierzy, że dobry UX jest wsparciem dla biznesu i działa mocno na jego korzyść. Zwolenniczka zwinnego podejścia (zwłaszcza leanu) do projektowania. Współautorka Experiment Sprint Canvas i Personal Development Canvas. Prywatnie fanka tańca towarzyskiego.

Pozostali członkowie zespołu

Tomasz Osowski Lean UX & Service Designer
Pomaga firmom stworzyć doskonałe doświadczenie użytkownika zapewniając jednocześnie odpowiednią rentowność biznesu. Jego zdanie to stworzyć produkt 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 6 lat szczerze zakochany w metodologii Lean. Zawsze stara się dostarczyć produkt jak najszybciej na rynek przy najmniejszym udziale kapitałowym.

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

Case study to za mało?

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

Porozmawiajmy!