Case Studies

Badania UX aplikacji low-code, czyli jak określić grupę docelową

badania ux aplikacji low code

Czy zbudowanie własnej aplikacji bez znajomości języka programowania, nawet w kilka dni, jest możliwe? Za nami badania UX aplikacji low-code z zakresu product discovery, mającej na celu umożliwienie szybkiego tworzenia własnego oprogramowania. Jacy użytkownicy najchętniej skorzystają z takiego rozwiązania? O tym, jak w ciągu 7 tygodni zbadaliśmy rynek, określiliśmy potencjalne grupy docelowe oraz kluczowe funkcjonalności, dowiecie się z poniższego case study.

Z poniższego case study dowiesz się:

  • Jak określić grupę docelową dla nowego produktu?
  • Dlaczego badania eksploracyjne są tak ważne?
  • W jaki sposób możesz przeprowadzić analizę rynku dopasowaną do Twoich potrzeb?
  • Co zrobić w wypadku, gdy Twoje rozwiązanie jest już na rynku?
  • W jaki sposób możesz szybko wyznaczyć kierunek dalszych badań i podstawowe założenia projektowe?
Klient:
White-Label
Cel:
Scharakteryzowanie grupy docelowej oraz głównych funkcjonalności nowego narzędzia
Okres współpracy:
lipiec-sierpień 2021
Liczba sprintów:
7
Liczba osób w projekcie:
2

Kontekst projektu


W lipcu i sierpniu 2021 roku mieliśmy przyjemność prowadzić badania UX dla aplikacji low-code, mające na celu określenie potencjalnych grup docelowych dla nowego produktu. Poprzez low-code w tym wypadku rozumiane jest umożliwienie budowy aplikacji w sposób wizualny, bez szczegółowej znajomości języka programowania (np. za pomocą diagramów, grafów czy formularzy).


Klient zgłosił się do nas z wstępnie opracowanym technicznie rozwiązaniem i potrzebą określenia, jacy użytkownicy chcieliby wykorzystać aplikację w swojej pracy. Czy będą to młodzi deweloperzy? A może pracownicy biurowi, chcący stworzyć rozwiązanie na potrzeby własnego działu? Tego nie wiedzieliśmy – wiedzieliśmy natomiast, że stoi przed nami wyzwanie dotyczące szybkiego określenia i zbadania potencjalnych grup w celu jak najlepszej weryfikacji pomysłu. 

 

W związku z 7-tygodniowym zakresem prac działania zostały podzielone tak, aby w jak najszybszym czasie zwalidować wstępne hipotezy projektowe, pozostawiając przestrzeń na badania pogłębiające z konkretnymi grupami. Wprowadzenie eksploracji przed badaniami pogłębionymi okazało się kluczowe w wypadku tego projektu. Dlaczego? Tego dowiesz się z dalszej części tekstu. 

 

Wyzwania, z którymi mierzył się klient:

  • gotowe rozwiązanie, nieprzetestowane z użytkownikami,
  • potrzeba wyznaczenia potencjalnych grup docelowych aplikacji,
  • określenie głównych funkcjonalności oraz priorytetyzacji ich wdrażania,
  • niescharakteryzowany kierunek rozwoju rozwiązania.

Sprint 1 i 2 – Rozpoczęcie działań i badania eksploracyjne


Warsztaty startowe

Jak w każdym projekcie badawczym, punktem wyjściowym było zapoznanie się z dostępnymi już danymi (tak zwane dane zastane) oraz przeprowadzenie warsztatu kick-off. Działanie to jest nieodłącznym elementem prawie każdego z naszych projektów, gdyż pozwala na pełne zrozumienie potrzeb i celów, z którymi przychodzi do nas klient.

Rozmowy rozpoczęły się od ustalenia wspólnych zasad oraz oczekiwań na płaszczyźnie wzajemnej współpracy. Jakie wartości są dla nas ważne? W jaki sposób najefektywniej będziemy mogli się komunikować? Odpowiedzieć na między innymi na te pytania pomogło nam użycie Team Canvas, czyli narzędzia wykorzystywanego również przy budowie zespołu w firmie. Pierwsze ustalenia związane ze współpracą umożliwiły przejście do kolejnego etapu, czyli opowieści o produkcie oraz wspólnego uzupełnienia Lean Canvas, gdzie poznaliśmy historię pomysłu, wstępne założenia projektowe i biznesowe oraz mieliśmy możliwość zobaczyć gotową wersję rozwiązania.

Jednym z ostatnich działań warsztatowych, tuż obok wyróżnienia głównych hipotez i pytań badawczych, było ustalenie wstępnej priorytetyzacji funkcji, które według zespołu powinno posiadać rozwiązanie. Zadanie to polega na wyróżnieniu kluczowych funkcjonalności aplikacji oraz określeniu ich kolejności zgodnie ze skalą od koniecznych do wdrożenia (must have) do mniej potrzebnych użytkownikom (nice to have). Każda z funkcjonalności opisana jest na osobnej karteczce oraz umieszczona w odpowiednim miejscu na pionowej osi. Dzięki temu prostemu zadaniu zespół badawczy ma możliwość zapoznania się z priorytetami klienta i bezpośredniemu zestawieniu ich z informacjami zgromadzonymi w trakcie działań badawczych.

badania ux kickoff

Priorytetyzacja i podsumowanie działań

Działania badawcze w zakresie Product Discovery mają tą szczególną cechę, że wraz z gromadzeniem informacji w procesie, pojawia się coraz więcej pobocznych pytań i hipotez, które czekają na pogłębienie. W związku z świadomością ograniczeń czasowych oraz finansowych, niezbędnym więc jest ustalenie priorytetów działań już na samym początku procesu, tak aby zawsze skupiać się na głównym celu badania. Działanie to pozwala również na jasne określenie wspólnego celu w zespole i minimalizację ewentualnych nieporozumień w trakcie dalszych działań. Podczas warsztatu kick-off wyróżnione zostały więc również główne priorytety w 3 stopniowej skali.

W pierwszej kolejności scharakteryzowane zostały główne priorytety, czyli cele lub hipotezy, które powinny być głównym tematem badań. Zależnie od wielkości priorytetu, mogą one również zostać priorytetyzowanie wewnętrznie, tak aby odpowiednio podzielić ilość czasu na każde z zagadnień. W tym wypadku wewnętrzna priorytetyzacja polegała na umieszczeniu od 1 do 3 gwiazdek (3 gwiazdki jako najwyższy priorytet, 1 gwiazdka jako najmniejszy). Dopiero w następnej kolejności wyznaczone zostały pozostałe ważne cele (gospodarowania w trakcie badań, jednak nie będące ich głównym trzonem) oraz dodatkowe cele (gospodarowania w wypadku możliwości czasowych, ale poza głównym zakresem potrzeb lub oferty).

badania ux aplikacji low code

Wszystkie zdobyte informacje, w połączeniu z przeprowadzeniem wstępnych działań eksploracyjnych oraz analizy danych zastanych (tzw. desk research), umożliwiły na określenie listy głównych pytań oraz hipotez, będących podstawą do stworzenia planu badawczego.  

 

Pierwsze badanie – ankiety oraz wywiady eksploracyjne wśród potencjalnych użytkowników

Tuż po określeniu wszystkich hipotez, stanęliśmy przed wyzwaniem – co teraz? Posiadaliśmy ogromną ilość pytań oraz działań badawczych, jednak które z nich powinno być pierwsze? Odpowiedź była prosta – zapytajmy użytkowników!

 

W wypadku badań eksploracyjnych dla nowych aplikacji bardzo często wyróżniane na wstępnie grupy docelowe bardzo od siebie się różnią. Nie inaczej było w tym wypadku. Po przeanalizowaniu i przegrupowaniu potencjalnych grup uzyskaliśmy podział zgodnie z potrzebami oraz zaawansowaniem użytkowników, który określił konieczność przeprowadzenia dwóch różnych ankiet, w związku z odmiennymi pytaniami i hipotezami do każdej z ogólnych grup. Zastosowany schemat pytań opierał się o podejście pozwalające również na przebadanie opinii dotyczącej rozwiązania, bez naprowadzania uczestnika na nieświadomy wybór odpowiedzi. Dlaczego jest to tak ważne?

W wypadku tworzenia scenariuszy ankiet lub wywiadów dla nowych produktów istotne jest unikanie sytuacji, w której odbiorca odpowiada na główne pytania po zapoznaniu się z opisem rozwiązania. Sytuacja taka może wpłynąć negatywnie na wyniki w związku z podstawową ludzką cechą – życzliwością. Jeśli opiszemy nasze rozwiązanie przed zadaniem głównych pytań, możliwe jest, że udzielona zostanie nam (nawet nieświadomie!) odpowiedź potwierdzająca naszą hipotezę.

W celu uniknięcia takiej sytuacji, zachowana została struktura, w której najpierw uzyskaliśmy odpowiedzi związane z głównymi hipotezami (np. częstotliwość występowania konkretnych problemów, świadczących o potencjalnej potrzebie rozwiązania), następnie uszczegóławia liśmy temat bardziej konkretnymi pytaniami (np. wykorzystywane dotychczas rozwiązania), aby dopiero na samym końcu przedstawić ogólnie rozwiązanie i zapytać o opinie z nim związaną.

low code aplikacja

Podczas działań związanych z dystrybucją i bieżącym nadzorowaniem wyników ankiety wykonane zostały dodatkowe wywiady eksploracyjne oparte o bardzo podobną strukturę do pytań w ankietach, jednak z możliwością bieżącego pogłębienia wiedzy dzięki pytaniom dopełniającym. Nawet bardzo krótkie, 10- lub 15-minutowe rozmowy są w stanie przekazać nam ogrom informacji, dając odpowiedzi zarówno bezpośrednio związane z zadawanymi pytaniami, jak i szansę na obserwację emocji i zachowania użytkownika, w momencie opowiadania o konkretnym zagadnieniu.

Sprint 3 – Analiza konkurencji i weryfikacja początkowej wersji aplikacji low-code


Analiza konkurencji

W celu poszerzenia informacji dotyczących potencjału rozwiązania nieodzownym działaniem jest analiza konkurencji oraz dostępnych analiz rynkowych (np. w postaci raportów). W celu ustrukturyzowania gromadzonej wiedzy, zastosowany został między innymi Competition Canvas, indywidualnie dopasowany do potrzeb prowadzonego badania. Łącznie 14 rozwiązań wybranych podczas warsztatu oraz dalszej eksploracji, zostało przeanalizowanych dzięki wykorzystaniu netnografii, informacji w wywiadów eksploracyjnych, raportów rynkowych, samodzielnego korzystania z rozwiązania i budowania aplikacji czy analizy ogólnodostępnych materiałów – wszystko w ramach zachowania odpowiedniej etyki badawczej.

Dodatkowo, w celu lepszej walidacji hipotez, zastosowane zostały graficzne porównania, pozwalające na szybkie zobaczenie zagospodarowania konkretnego zakresu przez konkurencję. Działanie to umożliwia między innymi szybkie zauważenie potencjalnych przestrzeni do zagospodarowania. Zastosowane porównania firm dotyczyły głównych hipotez i opierały się o skalę związane z:

  • wielkością firmy grupy docelowej,
  • złożonością stworzonego rozwiązania,
  • intuicyjnością i łatwiością obsługi,
  • rodzajem rozwiązania (mobilne, desktopowe).

analiza konkurencji rozwiązania low code

Negatywna weryfikacja – i co dalej?

Istotnym celem eksploracji i analiz rynkowych (np. analizy konkurencji) jest wczesna weryfikacja potencjału rozwiązania. W wypadku negatywnej weryfikacji hipotez działania te pozwalają na zaoszczędzenie zasobów związanych z ewentualną inwestycją w nieopłacalne rozwiązanie. W wypadku pozytywnej – dostarczają nam danych potwierdzających słuszność projektu (np. w celach prezentacji inwestycyjnych) oraz nowych informacji związanych z potrzebami użytkowników.

W wypadku prowadzonych badań zgromadzone informacje jednoznacznie wskazywały na duże zagospodarowanie rynku przez konkurencję, z jednoczesnym mniejszym zainteresowaniem wstępnie określonych przez klienta grup docelowych. Czy taka sytuacja oznacza koniec projektu? W żadnym wypadku!

Brak wstępnego zainteresowania na rynku nie musi oznaczać złego rozwiązania – jest ono po prostu skierowane do nieodpowiedniej grupy docelowej lub na przykład rozwiązuje nie ten problem, który powinno. Nieodłącznym etapem środowiska produktowego jest tak zwany pivot, czyli istotna zmiana w modelu biznesowym, wpływająca na funkcjonowanie produktu. W wypadku startupów, należy on wręcz do nieodłącznego elementu realiów życia organizacji. Wprowadzanie tych zmian nie jest niczym złym ani umniejszającym naszej idei – jest kolejnym etapem ewolucji produktu, służącym jeszcze lepszemu dopasowaniu projektu do prawdziwych potrzeb użytkownika i rynku.O przykładowym przeprowadzeniu pivotu w startupie, możesz dowiedzieć się więcej z innego z naszych case studies.

Stanęliśmy więc przed poważnym pytaniem – co dalej? W celu określenia dalszego kierunku badań zastosowaliśmy dwa działania. Najpierw jasno oznaczyliśmy wszystkie negatywnie zwalidowane hipotezy, w celu oddzielenia ich od potencjalnych szans. Następnie przygotowaliśmy schemat przedstawiający szczegółowo możliwe kierunki rozwoju produktu, określając ogólny rodzaj produktu, potencjalną grupę docelową, zagrożenia, szanse i główną konkurencję. 

 

badania ux aplikacji

Dzięki tak ułożonym informacjom mogliśmy bezpośrednio zestawić wszystkie możliwe ścieżki i określić wraz z klientem, która z nich posiada największy potencjał do pogłębienia w dalszej części badań (zgodny z celami biznesowymi). Dopiero na tej podstawie ustalony został dalszy plan działania, mający na celu pogłębienie branż i informacji o wybranym kierunku.

Sprint 4 – Analiza rynku w celu wyboru nowego kierunku badań 

Analiza branż i potencjału rynkowego

W jaki sposób w przeciągu tygodnia przeanalizować wstępnie ponad 60 branż, aby zawęzić je do najbardziej obiecujących? Trzeba najpierw mieć plan! Stając przed kolejnym rozległym tematem, podzieliliśmy to zadanie na dwa główne filary: dodatkową analizę branż w oparciu o rozwiązania konkurencyjne oraz ogólne sprawdzenie potencjału rynkowego dla każdej branży.

Korzystając z zgromadzonych wcześniej informacji oraz zestawień konkurencji, przygotowana została tabela, pozwalająca na dopasowanie każdego z 53 rozwiązań do jednej lub kilku z 60 konkretnych branż, w celu określenia najbardziej i najmniej zagospodarowanych zakresów rynku. 

badania pogłębione ux

 

W tym samym czasie przeprowadzona została skrócona analiza rynkowa branż, mająca na celu szybkie wyodrębnienie obszarów mających największe szanse na wprowadzenie rozwiązania (np. w związku z zapotrzebowaniem). Analizowane zakresy dotyczyły nie tylko szans i zagrożeń, ale również głównych “jobs to be done”, których rozwiązanie umożliwia wykonanie dla użytkownika. Umożliwiło to wstępne oszacowanie, które z branż będą w stanie prawdopodobnie wykorzystywać rozwiązanie w wielu aspektach, a które tylko w jednym. Wszystkie działania opierały się o netnografię oraz analizę dostępnych danych w formie raportów.

Wyróżnione na tej podstawie branże, wraz z zestawieniem zagospodarowania rynkowego, pozwoliły na zawężenie ich liczby do 5 w celu dalszego pogłębienia

Potencjalne branże i wybór kierunku

Wyróżnione 5 branż zostało poddanych dodatkowej analizie z pomocą metody zwanej mind-mappingiem. W celu przyspieszenia działań, wszystkie zgromadzone informacje zostały przedstawione na schematach, ułatwiających ewentualne ich odpisywanie lub graficzne zaznaczanie. Podczas działań brane pod uwagę były również trendy wyróżniające się w każdej z branż, w celu wyznaczenia już wstępnie ewentualnego kierunku rozwoju nowych funkcji.

Po zestawieniu po raz kolejny szans i zagrożeń dla każdej z branż, określone zostały 3 z największym potencjałem: edukacja, prawo i meblarstwo. Dodatkowo, w związku z możliwością ewentualnego zagospodarowania innych branż, wyznaczony został plan kierunku uniwersalnego, który miał tworzyć podstawę do dalszego rozwoju branżowego.

badania ux

Sprint 5 i 6 – Pogłębienie informacji w postaci badań jakościowych dla aplikacji low-code

 

Przygotowanie do dalszego badania UX 

Znaczne zawężenie wybranych kierunków rozwoju umożliwiło przygotowanie i przeprowadzenie kolejnych badań, mających na celu dalszą weryfikację. W związku z potrzebą szczegółowego zbadania potrzeb odbiorców (w tym funkcjonalnych), jako metoda badawcza wybrane zostały indywidualne wywiady pogłębione. W przypadku każdego z kierunków przygotowaliśmy osobny scenariusz, najbardziej pasujący do każdej z grup branżowych oraz do grupy uniwersalnej. Tak samo jak w wypadku wcześniej prowadzonego badania zastosowana została struktura nienakierowująca odbiorcy. Jednak w tym wypadku skupiliśmy się nie tylko na weryfikacji hipotez, jak i również gromadzeniu konkretnych potrzeb, istotnych w procesie określania podstawowych funkcjonalności. 

 

Indywidualne wywiady pogłębione

W związku z zgromadzonymi we wcześniejszych etapach kontaktami do potencjalnych uczestników badań, pomimo znacznie ograniczonego okresu czasowego, przeprowadzone zostały ostatecznie wywiady w 4 grupach: uniwersalnej i trzech branżowych. Ostatecznie, udało się nam przeprowadzić łącznie 26 wywiadów, dostarczających znaczących dla projektu informacji. W trakcie spisywania informacji korzystaliśmy zarówno z prostego arkusza, umożliwiającego porównywanie poszczególnych wypowiedzi między uczestnikami, jak i również zwykłych karteczek post-in na wirtualnej tablicy Miro. Dzięki korzystaniu jednocześnie z obu metod, mogłyśmy spisać oraz przeanalizować tak dużą ilość materiału zwrotnego w okresie niecałego tygodnia.

 

indywidualne wywiady pogłębione

 

Wyznaczenie kierunków

Jako podstawowy kierunek rozwoju aplikacji, będący bazą dla kierunków branżowych, określony został kierunek uniwersalny. Nie odnosił się on do żadnej z branż i pozwalał na łatwe dostosowanie rozwiązania do nowej grupy docelowej, w wypadku potrzeby pivotu. 

Wyznaczony kierunek jest również odpowiedzią na jeden z najważniejszych wniosków, które udało uzyskać się w trakcie indywidualnych wywiadów pogłębionych. Okazało się, że problemy scharakteryzowane podczas warsztatu są obecne w firmach – jednak rozwiązanie ich nie powinno dotyczyć tylko rozwiązań narzędziowych, ale również działań wewnątrz organizacji. Wniosek ten pozwolił na całkowite przedefiniowanie dotychczasowego spojrzenia na produkt, oraz skierowanie się z rozwiązaniem również do potrzeb wychodzących poza zakres wykorzystywanego oprogramowania. 

Dzięki zgromadzonym informacjom, badane kierunki branżowe zostały zwalidowane oraz udało się wyróżnić konkretne potencjalne grupy docelowe rozwiązania, które mają największy potencjał w zakresie bycia wczesny odbiorcą. 

 

Sprint 7 – Opracowanie i podsumowanie wyników 


Grupy docelowe i ich persony

W łącznym rozrachunku, opracowane zostało 9 grup docelowych, oraz 10 głównych person, odpowiadających najbardziej wyróżniającym się użytkownikom. Wprowadzenie przedstawienia wniosków w formie person miało na celu zarówno ułatwienie ich zrozumienia przez osoby trzecie, jak i również wyróżnienie istotnych różnic w obrębie jednej grupy docelowej.

Ważnym elementem charakteryzowanych grup i person było jasne wyznaczenie nie tylko danych takich jak demografia, kanały dotarcia czy bio, ale również określenie głównych celów grupy / persony oraz cech szczególnych. Zwłaszcza istotne było wyróżnienie, wśród tych ostatnich, cech będących szansą lub zagrożeniem dla rozwoju projektu. Pozwoliło to na ostateczne zestawienie wszystkich opracowanych wniosków i wybranie rekomendacji dotyczących ostatecznego kierunku.

grupa docelowa rozwiązania low code

 

UVP oraz dodatkowe wartości

Zgromadzone w trakcie badań informacje o prawdziwych potrzebach i problemami użytkowników umożliwiły określenie potencjalnej unikalnej propozycji wartości, skupiającej się na problemach nie rozwiązywanych dotychczas przez konkurencję. Możliwe było to dzięki wyjściu poza schemat patrzenia na odbiorców tylko w kontekście używanych przez nich narzędzi oraz holistycznej obserwacji wszystkich problemów pojawiających się w zakresie ich pracy. Również sama charakterystyka UVP dotyczyła zwrócenia uwagi na pojawiający się problem, a nie rozwiązanie w postaci narzędzia, w celu lepszej identyfikacji przez odbiorców.

Dodatkowo, w związku z wstępnym etapem cyklu życia produktu, wyróżnione zostały dodatkowe wartości. Mimo ich powtarzalności z wartościami oferowanymi przez rozwiązania konkurencyjne, ich jasne zapisanie i określenie stanowi swego rodzaju wyróżnienie głównych założeń, związanych z wartościami, które powinna posiadać firma, aby w połączeniu z UVP, móc wyróżnić się faktycznie od konkurencji i utrzymać wystarczająco wysoki poziom usługi. 


Główne założenia projektowe rozwiązania

Podczas tworzenia nowego produktu, niezależnie od jego formy, bardzo pomocne jest określenie głównych założeń projektowych rozwiązania. Są one swojego rodzaju wyznacznikiem i kierunkiem dla osób projektujących. Istotne jest, aby wynikały nie tylko z założeń kluczowych dla biznesu lub zasobów którymi dysponujemy, ale aby również określały wszystkie inne niezbędne czynniki lub założenia, które pozwolą na lepsze zrozumienie idei. Również w wypadku tego projektu, określone zostało 5 głównych założeń, będących trzonem do dalszych prac nad aplikacją

W wypadku tworzenia założeń pierwszy raz pomocny może być podstawowy podział na:

  • założenia ideowe – czyli związane zwłaszcza z głównym celem narzędzia,
  • założenia technologiczne – czyli wszystkie wytyczne oraz ograniczenia z zakresu technologii,
  • założenia funkcjonalne – czyli wszystkie wytyczne związane z funkcjonalnościami, które będzie posiadało rozwiązanie,
  • założenia estetyczne – czyli wszystkie związane z formą zewnętrzną narzędzia,
  • założenia biznesowe – czyli związane z głównymi celami biznesowymi.

projekt aplikacji low code

 

Zależnie od prowadzonego projektu kategorie założeń powinny być dobierane i tworzone indywidualnie – istotne jest ich spisanie i uporządkowanie, w celu jasnego przekazania wiedzy pozostałym członkom zespołu lub osobom przejmującym projekt w dalszych etapach.

 

Kluczowe funkcjonalności aplikacji

Wyróżnione zostały dwie główne grupy funkcjonalności: funkcjonalności pozwalające na pracę w narzędziu, oraz funkcjonalności dostępne do zbudowania w narzędziu (w tworzonej aplikacji). Podział ten jasno określał jakie elementy będą niezbędne do ogólnego przedstawienia produktu uczestnikowi, zachowując intuicyjną obsługę oraz jakie z nich mogą zostać rozłożone w czasie, zależnie od wybranej grupy. 

W związku z wczesnym etapem rozwoju, konieczne było odpowiednie priorytetyzowanie wyróżnionych funkcjonalności w celu wyróżnienia zakresu do pierwszej wersji rozwiązania MVP (Minimum Viable Product) oraz kolejnych kroków rozwoju zgodnie z wewnętrzna roadmapą. W tym celu wykorzystaliśmy nie tylko podstawowe znane narzędzie do priorytetyzacji takie jak MoSCoW, ale również prezentację za pomocą Use Cases, czyli przykładowych sposobów użycia przez poszczególne grupy docelowe, zgodnych z ich potrzebami. Dodatkowo, w związku z zebraną ilością danych szczegółowych, przedstawione zostały przykładowe aplikacje, które mogłyby być stworzone przez badane narzędzie.

Podsumowanie projektu

Jak widać na przykładzie powyższego projektu, wprowadzenie do procesu badań eksploracyjnych w celu walidacji głównych hipotez może mieć kluczowe znaczenie dla dalszego rozwoju biznesu i zarządzania jego zasobami. Negatywna walidacja naszego pomysłu nie musi też kończyć się rezygnacją z rozwiązania, a może być nowego produktu, nawet dla tych samych grup docelowych.

Obecnie projekt jest w fazie dalszego opracowywania – bogatszy o wiedzę o potrzebach użytkowników i planem wdrażania poszczególnych elementów w czasie.

Podsumowanie projektu w liczbach

53

przeanalizowane rozwiązania

60

przeanalizowanych branż

36

wywiadów indywidualnych

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

Laura Piwowarska UX Researcher w Project: People
Uważa, że najlepszym sposobem, żeby sprawdzić, ile o sobie wiemy, jest podjęcie próby opisania siebie w kilku zdaniach.

Kim jestem? To pytanie zadecydowało o wyborze jej ścieżki zawodowej.

Jest badaczką, wspiera klientów w podejmowaniu decyzji dotyczących powstawania i rozwoju produktu kładąc nacisk na etyczny wymiar badań i pracy w UX.

Moderator Design Thinking i pasjonatka kreatywnych metod przekazywania wiedzy.

Radość sprawia jej odkrywanie nowych miejsc, krajów i kontynentów. Szuka różnorodności w ludziach, kulturach, językach i… w jedzeniu.