Menu Zamknij
Find my dinner

Ogranicz na podstawie swoich preferencji ogromny wybór posiłków do zamówienia.

hero-fmd
Find my dinner

Ogranicz na podstawie swoich preferencji ogromny wybór posiłków do zamówienia.

hero-fmd-mobile

Moja rola

  • Praca z gotowymi wynikami researchu.
  • Zaprojektowanie architektury informacji.
  • Zaprojektowanie finalnej aplikacji.

 

Problemy do rozwiązania

  • Zbyt duży wybór posiłków w aplikacjach do zamawiania jedzenia("paradoks wyboru").
  • Brak uwzględnienia preferencji żywieniowych w niektórych aplikacjach.
1. DEFINIOWANIE

Persona

Z dostarczonych wyników badań (wywiadów) stworzyłem Personę. Jest to użytkownik do którego głównie będzie kierowany produkt. W dalszym rozwoju projektu, Persona przyda się w momentach podejmowania decyzji, czekających na dalszą weryfikację. Narzędzie będzie również przydatne, do przedstawienia przyszłym członkom zespołu, lub decydentom, jak należy patrzeć na podjęte decyzje.

Do Persony powracałem na wszystkich etapach projektowania. W trakcie jej tworzenia, bardziej od danych demograficznych skupiłem się na określeniu motywacji Persony (celów, frustracji, zachowań).

Persona na podstawie otrzymanych badań.

Activities / Objects / Features

Narzędzie AOF pozwoliło mi na prześledzenie, czego potrzebuje interfejs, aby użytkownik mógł wykonać konkretne działania. Dzięki narzędziu udało się zdefiniować kluczowe ekrany. Dodatkowo pojawiło się wiele mniejszych funkcjonalności (m.in zniżki uwzględniające Groupon’a; gramatura/kcal czy skala ostrości dania). AOF pozwoliło również na pierwsze podejście do stworzenia struktury aplikacji.

Najważniejsze funkcje: wykluczanie posiłków zawierających wskazane produkty, otrzymanie maksymalnie 4 propozycji, opinie o potrawie w danej restauracji.

Red Routes

Dla każdej aktywności (pochodzącej z AOF), przygotowałem tabelę Red Routes. Narzędzie pozwoliło na wartościowanie, które funkcje są bardziej, a które mniej ważne dla użytkownika. Te mniej istotne zostaną odłożone do późniejszego rozwoju aplikacji. Wartościowanie pozwoliło również na maksymalne skupienie prac na elementach, których najbardziej będzie potrzebował użytkownik, aby wykonać założony wcześniej cel.

User Flow

Stworzyłem różne wersje User Flow, aby rozpisać kolejne kroki przez które użytkownik będzie musiał przejść wykonując konkretne zadanie. Korzystając z tego narzędzia posiłkowałem się szkicami rozwiązań tworzonymi na bieżąco. Część z nich pojawiła się w poprzednich etapach prac, więc wymagała jedynie doprecyzowania na tym etapie.

User Flow dla aplikacji.

Flowchart

Za pomocą Flowchartu rozpisałem architekturę informacji. Szczegółowo wykonane drzewo pozwoliło na kontrolowanie prac i zdefiniowanie kluczowych ekranów, oraz tych, które można będzie uspójnić jednym szablonem. Narzędzie Flow chart pomogło uspójnić wiedzę na temat poruszania się po aplikacji.

Aplikacja będzie posiadać w pewnym sensie odwrotną ścieżkę użytkownika niż typowe aplikacje do zamawiania jedzenia. Użytkownik zamiast wyboru restauracji i dania, będzie najpierw wybierał danie, a następnie lokal, z którego posiłek zostanie zamówiony

Architektura informacji opisana za pomocą Flowchart'a.

2. PROTOTYPOWANIE

Prototyp

W oparciu o naszkicowane rozwiązania, powstałe w poprzedniej części pracy, przystąpiłem do tworzenia prototypu. Tworząc nowe elementy makiety, wykorzystywałem rozwiązania zgodne z utrwalonymi i znanymi wzorcami, które będą intuicyjne dla odbiorcy. Stworzony prototyp posłużył do testów użyteczności, dlatego żadna decyzja podjęta na tym etapie nie jest wiążąca. Interaktywny prototyp został wykonany w programie Axure RP.

Prototyp wykorzystany w badaniu użyteczności.

Badanie użyteczności

Celem badania było odnalezienie i wyeliminowanie problemów związanych z użytecznością interfejsu. Do testów rekrutowane były nie tylko osoby wpasowujące się w Personę. Uwagi respondentów najlepiej pasujących do persony były bardziej wartościowe w kontekście tworzonego rozwiązania.

Kilka spostrzeżeń pomiędzy badaniami:

  • bardzo dobrze sprawdziły się podpisy pod dużymi buttonami,
  • opcja wylosowania wyników 50/50 (nowe oraz te, które użytkownik już wcześniej jadł), była w pierwszej iteracji dosyć niezrozumiała,
  • wybór rozmiaru posiłku (lekki, duży), jak i skala ostrości okazały się zbyt względne dla każdego użytkownika.

Niektóre zmiany po badaniu użyteczności.

’50/50’ oraz ‚sprawdzone rozwiązania’ to miłe zaskoczenie – kiedy jestem bardzo głodny nie chcę ryzykować z nowym posiłkiem.
Łukasz
3. PROJEKT GRAFICZNY

Projekt interfejsu

Po serii testów, oraz stwierdzeniu, że interfejs jest w miarę intuicyjny (zwłaszcza dla docelowego odbiorcy definiowanego przez personę) zabrałem się za projektowanie UI. Całość zbudowana została w Axure RP, z pomocą odpowiednich bibliotek

Skorzystałem ze standardów Apple Human Interface, ponieważ aplikacja miała docelowo trafić do AppStore.

Interfejs aplikacji według standardów Apple Human Interface.

Podsumowanie

Otrzymałem solidną lekcję, na temat nie przywiązywania się do wielu pomysłów na mniejsze usprawnienia. Zdecydowanie lepszą opcją jest zrobienie dobrego MVP, zostawiając ciekawe usprawnienia na później.

Jedna, dobrze zdefiniowana Persona zapewnia wystarczającą ilość pracy. Taka postać tworzy szereg możliwości oraz definiowania/rozwiązywania jej problemów.

Mimo posługiwania się zwinną metodyką, pomocne okazały się luźno założone odgórne ramy.

Adam Klimas
Adam Klimas
Kontakt
klimas.adam1@gmail.com
linkedin.com/in/adam-klimas