Typ: Projekt Koncepcyjny
Czas trwania: marzec 2022 - sierpień 2022; uplift graficzny listopad 2023 - grudzień 2023
Moja rola: Product Designer, UX/UI Designer
Zainteresowałem się projektowaniem aplikacji do zamawiania zdrowego jedzenia, ponieważ zdrowe odżywianie stało się bardzo popularne w ostatnim czasie, a jednak wiele osób wciąż ma z tym trudności. Chciałem stworzyć rozwiązanie, które pomoże użytkownikom łatwiej wybierać zdrowe posiłki, a jednocześnie pozwoli mi rozwijać swoje umiejętności w projektowaniu interfejsów użytkownika.
Mimo, że przecież większość z nas chciałaby się zdrowo odżywiać (93% według L.E.K. Consulting 2018 food and beverage survey), to jednak stosunkowo niewiele osób naprawdę tak robi, a nie tylko deklaruje (20% według NDP group). Dlaczego trudno nam odżywiać się zdrowo? Wiedziałem, że poznanie odpowiedzi na to pytanie będzie kluczem do zaprojektowania dobrej aplikacji.
Odpowiedź nie była prosta. Mamy problem z odżywianiem się zdrowo, bo jest to zwyczajnie zbyt trudne. Wyszczególniłem 7 przeszkód które się na to składają:
Dzięki zrozumieniu problemu, doszedłem do wniosku, że najlepsze rozwiązanie powinno przede wszystkim odpowiadać na sześć pierwszych przeszkód (na biologię jeszcze nic nie poradzimy). Potencjalni użytkownicy chętnie skorzystają z tej aplikacji, jeśli poczują, że ułatwia im zdrowe odżywianie. A co z tymi, którzy obecnie odżywiają się zdrowo? Oni również docenią aplikację, która będzie wspomagać ich w tym stylu życia. Dostępne w internecie wyniki ankiet wskazują na cztery główne motywacje, które nimi kierują:
Przygotowałem 3 persony, które reprezentują zebrane przeze mnie dane:
W ramach wstępnych badań, potrzebowałem jeszcze określić kto potencjalnie odpowiadałby za taką aplikacją. Oszacowałem, że najprawdopodobniej z taką inicjatywą wyszłaby niewielka sieć restauracji, która chciałaby wypełnić tę niszę.
Do audytu wybrałem zarówno platformy (Uber Eats i Pyszne) jak i popularne sieci fastfoodowe. Podczas porównywania interesowały mnie przede wszystkim rozwiązania ułatwiające identyfikację zdrowych posiłków oraz to, jak wygląda proces zamawiania. Co ciekawe, nie każda sieć ma dedykowaną aplikację (np. Subway), często też decydują się nie realizować dowozów sami, lecz powierzają tę działkę platformie (tak jak robi to McDonald's proponując dokończyć proces zamawiania korzystając z np. Glovo).
Platformy obsługujące restauracje nie wymagają aby te podawały wartości odżywcze, dokładnie katagoryzowały posiłki lub chociaż podały listę składników. Taka sytuacja utrudnia odszukanie zdrowego lub dopasowanego posiłku. Prawdopodobnie jest to spowodowane tym, że gdyby skład posiłków, szczególnie tych fast-foodowych był jasno podany, część osób mogłaby zostać zniechęcona od zakupu, co zmniejszyłoby zyski. Aplikacje różnych sieci restauracji oferują niewiele więcej. Mimo, że często promują dania wegańskie, to jednak nie zawsze chcą wspomnieć o ich dokładnym składzie. Tabelę z wartościami odżywczymi swoich posiłków znalazłem w zaledwie dwóch:
North Fish przedstawia je w formie rozwijanej listy przy każdym z produktów. Wartości zapisane są małym fontem i są umieszczone blisko siebie, przy czym nie są zbyt czytelne. Na dodatek, zauważalna część posiłków nie posiada uzupełnionych wartości.
Drugą aplikacją pokazującą te dane jest McDonald's. To w jaki sposób je przedstawia, jasno daje znać, że wolałby tego nie robić. Aplikacja stosuje wiele zabiegów aby nas skutecznie do tego zniechęcić. Jeżeli chcemy je zobaczyć, najpierw jesteśmy przenoszeni na inny ekran, gdzie znowu musimy potwierdzić, że nas to interesuje. Kiedy to zrobimy, otwiera się nasza przeglądarka, gdzie ładuje się wielka tabela, wypełniona praktycznie wszystkimi produktami jakie możemy znaleźć w McDonald's. Niemożliwym jest wyświetlenie potrzebnych informacji jednocześnie, trzeba cały czas przesuwać tabelę i pilnować żeby przypadkiem nie zgubić kolumny produktu, który nas interesuje. Jest to bardzo niewygodne rozwiązanie dla użytkownika.
Proces zamawiania nie różnił się znacznie pomiędzy aplikacjami, prawie wszystkie wykorzystywały znane i sprawdzone schematy. Za to różnice w szybkości działania aplikacji były odczuwalne. W szczególności irytujące były przestoje w Uber Eats, kiedy aplikacja “myślała” nie dając żadnego znaku dla użytkownika.
Kiedy miałem już wszystkie potrzebne informacje, mogłem zająć się próbą pokonania przeszkód które wykryłem. Postarałem się, aby rozwiązania były proste do realizacji oraz nie wymagające wysokich kosztów.
Z przygotowanymi rozwiązaniami zabrałem się do tworzenia low-fi prototypu w Figmie. Miał mi posłużyć do przeprowadzenia szybkiego testu użyteczności, który powiedział by mi czy użytkownicy potrafią bez problemów ukończyć główny flow aplikacji. Metodologia jaką zastosowałem przy tworzeniu makiety oraz przeprowadzania testu jest stosowana i promowana przez Google, stąd decyzja o używaniu tekstu lorem ipsum, małej ilości kolorów, czarnych pasków zamiast prawdziwego tekstu oraz "blokowej" konstrukcji.
Dopiero później zdałem sobie sprawę, że ten sposób jest nieoptymalny, ponieważ w niewiele dłuższym czasie mógłbym przygotować prototyp dużo wyższej jakości, który nie tylko nie powoduje konfuzji u osób testujących, ale też zapewnia bardziej przydatne dane. Usunięcie fazy testów na prototypie low-fi zmniejszyłoby koszta wiążące się z serią testów jak i ilość czasu, którą trzeba byłoby poświęcić do uzyskania działającego produktu. Dodatkowo, NN/g w swoich badaniach odkrył, że testerzy mogą mieć problem ze zrozumieniem konceptu czarnych linii i tekstu zastępczego. Od czasu pracy nad Macrolicious zapoznałem się z alternatywnymi metodologiami i staram się dokładnie dopasowywać je do skali projektu.
Testy które przeprowadziłem, potwierdziły, że użytkownicy potrafią bezbłędnie ukończyć główny flow, lecz kiedy spytałem ich o komentarze, to zwrócili moją uwagę na pewien element wyrażając swoje opinie:
"Takie puste się to wydaje, że ciężko mi coś ocenić."
"A będzie się dało wyszukiwać co ma mało kalorii i inne takie?"
"Nie zmienia się ile jest kalorii nawet jak wybiorę wszystkie składniki dodatkowe."
"Chciałabym widzieć od razu jakieś oznaczenie albo filtr dla rzeczy bez mięsa."
Część z tych uwag wynikała ze specyfiki makiety low-fi oraz sposobu działania prototypów w Figmie, jednak mogłem z nich wywnioskować, że karta przedmiotu i związane z nią dane mogłyby być lepiej zaprezentowane. Wróciłem do moich dotychczasowych badań i zorientowałem się, że kluczem może być zrobienie tego zupełnie inaczej od innych. Skoro atutem Macrolicious jest oferowanie zdrowych posiłków, które mają dobrze zbilansowne wartości odżywcze, czemu nie postawić na to nacisk i jasno to pokazać?
Jeśli aplikacja pokazywałaby informacje o wartościach odżywczych bezpośrednio przy zdjęciach posiłków, sprawiłoby to, że prościej i szybciej byłoby użytkownikom znaleźć ten najbardziej dopasowany do swoich potrzeb. Z tym rozwiązaniem jednak wiązał się minus - zmiana znanego użytkownikom schematu może wywołać u nich uczucie zagubienia, które mogłoby spowodować odbicie się od aplikacji jeśli wydawałaby się zbyt skomplikowana. W przypadku kiedy chciałem przedstawić kartę przedmiotu w trochę inny sposób niż standardowy, to musiałem zadbać, aby była jak najbardziej intuicyjna. Było to największe wyzwanie z jakim się spotkałem w ramach pracy nad Macrolicious.
Chciałem aby karta zawierała nazwę, oznaczenie o typie diety (wegetariańska, wegańska), cenę i informacje o makroskładnikach. Jej rozmiar musiał być też odpowiednio mały, aby przewijanie kart było wygodne na ekranie telefonu. Skoro chciałem wspomagać szybkie znajdowanie odpowiedniego dla siebie posiłku, najlepiej byłoby przedstawić te informacje w formie graficznej, która jest interpretowana przez człowieka o wiele szybciej niż forma tekstowa, chociaż nie jest aż tak precyzyjny. Najlepszym więc rozwiązaniem byłoby połączenie obu tych sposobów prezentowania danych. Z takimi założeniami rozpocząłem projektowanie:
Część z tych przedstawionych propozycji rozwiązań miało potencjał, jednak nie zdałyby egzaminu w skrajnych przypadkach jak np. kiedy danie posiadałoby w informacjach dotyczących wartości odżywczych kilka trzycyfrowych liczb. Finalny projekt musiał być też prosty do zrozumienia. Pomimo obecnej popularności ekranów z onboardingiem, nowe badania pokazują, że niekoniecznie jest to dobra praktyka, ponieważ użytkownicy często je pomijają lub "przeklikują" bez podjęcia próby przyswojenia zawartych w nich informacji. Dlatego chciałem, aby natychmiast rozumieli znaczenie podawanych przez Macrolicious cyfr oraz kolorów; dzięki temu nie będą musieli się martwić, że zapomną co oznaczają nawet jeśli nie będą korzystać z aplikacji przez dłuższy czas.
Finalny design pozwala użytkownikowi w bardzo krótkim czasie znaleźć np. wysokobiałkowy posiłek, który zawiera mniej niż 400 kcal.
Jednak nie przewidziałem, że karta może być zbyt duża na ekranach małych i średnich telefonów, a jej pomniejszenie powoduje, że cyfry są zbyt małe lub za bardzo ściśnięte aby je wygodnie przeczytać. Dlatego stworzyłem alternatywną wersję, dostosowaną do małych ekranów. Wersja "duża" będzie mogła być wykorzystywna w sekcji "daily deals", gdzie będzie mogła bardziej przyciągać uwagę. Podczas projektowania zadbałem, aby mój design wykorzystywał 8p siatkę oraz logiczny auto-layout, który ułatwiłby wdrożenie aplikacji deweloperom na każdym rozmiarze telefonu.
Przy projektwaniu zadbałem o to, aby każdy ekran konsekwentnie korzystał z odległości bazujących na liczbie 4.
Dwie skrajne opcje na dolnej nawigacji, zostały odrobinę przesunięte do środka, aby dopasować je wizualnie z resztą opcji.
Kiedy ekrany były gotowe, dodałem do przejść pomiędzy nimi animacje, które nie tylko mają na celu być przyjemnymi dla oka, ale też umocnić wizerunek marki. W przypadku Macrolicious najbardziej odpowiednimi wydawały mi się smukłe animacje kojarzące się z byciem energicznym.
Prototyp Macrolicious można sprawdzić tutaj.
Pomimo tego, że projektowałem Macrolicious z myślą o tym, żeby spełniał standardy WCAG, postanowiłem to zweryfikować po zakończeniu projektu. Wyniki przeprowadzonej analizy potwierdziły, że wykorzystywane kolory mają odpowiedni kontrast zarówno dla dużych jak i małych fontów.
Font Manrope, który jest wykorzystywany w całej aplikacji oprócz ekranu tytułowego jest uznawany za czytelny i dostosowany do wykorzystywania w sieci. Podpisy wartości odżywczych (kcal, Fat, Carbs i Protein) mają rozmiar 10px zamiast sugerowanych 12px, jednak nie są niezbędną informacją - stałe kolory oraz rozmieszczenie wartości odżywczych sprawia, że nie trzeba ich czytać za każdym razem, dlatego ich rozmiar nie powinien być problematyczny dla niedowidzących.
Gotowy prototyp przedstawiłem 5 osobom z grupy docelowej, dając im kilka minut na przetestowanie go samodzielnie, po czym zadałem im pytanie "Czy korzystałbyś/korzystałabyś z Macrolicious do zamawiania zdrowej żywności zamiast innej aplikacji?" 4 z 5 osób odpowiedziało - Tak.
Testerzy mogli wyrazić też swoją opinię bardziej szczegółowo komentarzem. Rzeczą, która przyciągnęła najwiecej uwagi były informacje o makroskładnikach, co dobrze podsumowuje komentarz:
"Czemu inne aplikacje tego nie pokazują?"
Jeśli nie byłby to projekt konceptualny, to nie ograniczyłbym się jedynie do aplikacji mobilnej, bo funkcje z jakich korzysta Macrolicious nie wymagają dedykowanych rozwiązań i również sprawdziłyby się na responsywnej stronie internetowej. Praca nad Macrolicious była dla mnie szczególnie rozwijająca. Usprawniła moją umiejętność odczytywania feedbacku oraz pozwoliła mi odkryć zainteresowanie optymalizacją pracy UX dla biznesu oraz projektowania interakcji.
