Przewidywany czas: 1-2 godziny. Zalecam wykonanie tego ćwiczenia z kluczowymi interesariuszami.
Zacznijmy od założenia, że otrzymałeś zadanie stworzenia aplikacji mobilnej. Pierwszą rzeczą, jaką powinieneś zadać, jest pytanie: „Jaki problem rozwiązuję i dla kogo go rozwiązuję?”. Odpowiedzi na to złożone pytanie ustanowią fundament dla Twojego projektu, ponieważ dostarczą spostrzeżeń, które mogą napędzać cechy i funkcje Twoich projektów. Odpowiedzi te z pewnością pomogą Ci również zdecydować, co MVP (minimum viable product) będzie dla Twojego projektu.
Na przykład, możesz mieć wiele funkcji na mapie drogowej produktu, ale musisz skupić się tylko na istotnych funkcjach, aby pomyślnie uruchomić pierwszą wersję aplikacji. Możesz zacząć od pytania: „Jakie cechy i funkcje musimy stworzyć, aby nasza docelowa demografia mogła zrealizować swój cel/zadanie?”
Aby odpowiedzieć na to pytanie, możesz stworzyć przepływ użytkownika w oparciu o „szczęśliwą ścieżkę” swojego głównego użytkownika (możesz skupić się na wszystkich przypadkach brzegowych później). Polecam tablicę, na której najpierw wypiszesz wszystkie kluczowe kroki użytkownika. Kiedy masz już zapisane te kluczowe kroki, możesz zacząć tworzyć wysokopoziomowe szkice tych kroków. To pomoże Ci określić, jakich udogodnień potrzebuje użytkownik na każdym kroku i utrzyma zakres pełzania na dystans.
Uwaga: Spróbuj powstrzymać się od szkicowania bez uprzedniego napisania przepływu użytkownika. Nasze umysły mogą stać się bardzo kreatywne i zboczyć z toru, jeśli od razu przejdziemy do szkicowania.
Tak może wyglądać to ćwiczenie po rozpisaniu przepływu użytkownika i stworzeniu pod nim wstępnych szkiców. Pamiętaj, to nie musi być ładne, ale powinno przekazać twoje pomysły na tyle, abyś mógł przejść do następnego kroku, czyli cyfrowych szkiców.
Przykład 1
Przykład 2
Przykład 3
Krok drugi: Low-fidelity digital wireframes
Przewidywany czas: 2-3 dni, w zależności od zakresu MVP.
Gdy już masz swoje MVP wireflows rozgryzione, następnym krokiem jest stworzenie nieco bardziej szczegółowych wireframes. Możesz stworzyć papierowy prototyp lub od razu przejść do cyfrowych makiet (jeśli szybkość jest istotna, zwykle przeskakuję do cyfrowych makiet).
Uwaga: Jeśli pracujesz z uznaną marką, może być możliwe użycie komponentów z istniejącego systemu projektowania i możesz od razu przejść do wysokiej wierności, Krok 3, poniżej.
Zalecam stworzenie tablic graficznych dla kluczowych ekranów, które odkryłeś podczas szkicowania. Liczba potrzebnych ekranów będzie wzrastać w miarę przechodzenia przez proces wireframingu od szkiców, przez makiety o niskiej wierności, do makiet o wysokiej wierności.
Dla cyfrowych makiet o niskiej wierności, użyj wybranego narzędzia do projektowania, aby utworzyć proste kształty i użyć podstawowych czcionek do stworzenia swoich makiet. Istnieje również wiele zestawów UI, które mogą przyspieszyć ten proces i stworzyć projekty o niskiej wierności, które są nieco bardziej atrakcyjne wizualnie. Zalecam również używanie średniego rozmiaru tablicy, który może pracować na większości rozmiarów ekranów telefonów. Jeśli masz dane na temat docelowej grupy demograficznej i rozmiaru telefonu, który jest przez nią używany, to użyj tego rozmiaru ekranu.
Używam artboardu o rozmiarze 875 x 667px podczas korzystania z Adobe XD (lub jakiegokolwiek innego narzędzia projektowego, ponieważ większość z nich ma wbudowane predefiniowane rozmiary), ponieważ jest to „środkowa ścieżka” rozmiarów ekranu (szczególnie dla iPhone’a). Stwierdzam, że ten rozmiar działa dobrze dla iPhone’a 8 i iPhone’a X, i stwierdzam, że działa to dobrze również dla Androida.
Oto przykład ekranów low-fidelity w akcji:
Po stworzeniu ekranów niskiej wierności, przetestowaniu projektów z użytkownikami i uzyskaniu zgody interesariuszy, jesteś gotowy do stworzenia ekranów wysokiej wierności.
Krok trzeci: Cyfrowe makiety wysokiej wierności
Przewidywany czas: 1+ tygodni. Będzie to zależało od tego, czy masz system projektowania w miejscu lub jeśli tworzysz go od zera, jak idziesz. Ten etap również trwa dłużej, ponieważ prawdopodobnie zostanie dodanych więcej ekranów niż w fazie low-fidelity.
Ten etap to miejsce, w którym Twoje projekty ożywają! Jest to również faza, w której twoje projekty naprawdę zaczynają wyglądać jak działająca aplikacja mobilna, którą możesz prototypować, testować, iterować, uzyskać zatwierdzenie, a następnie, ostatecznie, przekazać zespołowi deweloperskiemu.
Rozważania:
- Jeśli produkt, nad którym pracujesz, ma już ustaloną markę, najprawdopodobniej wyciągniesz kolory, ikony i czcionki z wytycznych marki.
- Jeśli produkt, nad którym pracujesz, nie ma w pełni ustalonego wyglądu i sposobu działania marki, możesz użyć zestawu UI, aby przyspieszyć proces projektowania.
Kolejne rozważania dotyczą tego, od jakich ekranów zaczniesz? Możesz zacząć od:
- Kluczowych ekranów dla każdej sekcji głównej nawigacji, lub;
- Kluczowych przepływów użytkownika dla użytkownika, lub;
- Priorytetyzuj ekrany, które projektujesz w oparciu o kolejność harmonogramu rozwoju (jest to typowe miejsce, w którym zaczynam, więc mogę pracować w metodzie zwinnej, upewniając się, że mam ekrany gotowe do przekazania, gdy zespół programistów ich potrzebuje).
W tym przykładzie, zamierzam pokazać proces korzystania z ustalonego zestawu UI w Adobe XD. Zacznę od logowania użytkownika i tworzenia profilu, ponieważ zespoły programistów, z którymi pracowałem, zwykle zaczynają od zarządzania użytkownikami w procesie tworzenia aplikacji.
Zestaw UI, który wybrałem, ma już ustaloną paletę kolorów, style znaków i wspólne elementy UI (aka komponenty), które można kopiować i wklejać w całym projekcie.
Uwaga: Na początku zalecam przekształcenie wszystkich elementów, które planujesz ponownie wykorzystać, w komponenty (lub symbole). W ten sposób, jeśli musisz zmienić strzałkę wstecz ze strzałki ” ← ” na marchewkę „<„, możesz ją zmienić za pomocą głównego komponentu i mieć ją zaktualizowaną we wszystkich szkicach, zamiast kopiować i wklejać edycję na każdym ekranie, który wymaga aktualizacji.
Przykład kolorów, stylów postaci i komponentów:
Aby rozpocząć proces, zacząłbym budować ekrany przyjęcia do pracy, logowania i profilu użytkownika:
Następnie, zacząłbym budować globalne elementy nawigacyjne:
Po tym, zacząłbym tworzyć druty wysokiej wierności dla wszystkich przepływów użytkownika dla aplikacji, zaczynając od priorytetowych przepływów opartych na dostarczaniu do rozwoju (lub dla wszelkich elementów, które nadal wymagają testów użytkownika).
Zalecam tworzenie oddzielnych plików projektowych dla każdego z kluczowych przepływów użytkownika, tak aby można było łatwo prototypować i dzielić się z rozwojem podczas pracy w zwinnej metodzie (tj. jeden plik dla rejestracji użytkownika i tworzenia konta, jeden plik dla wiadomości, jeden plik dla doświadczenia wyszukiwania, itp.).
Jak projekty zostaną zatwierdzone i przekazane do rozwoju, zalecam utworzenie jednego pliku głównego ze wszystkimi ekranami i komponentami głównymi. Podczas pracy w zespołach, zazwyczaj zalecam, aby jedna osoba była odpowiedzialna za plik główny, aby zmniejszyć zamieszanie. W ten sposób każdy członek zespołu wie, że czerpie z zatwierdzonego pliku głównego podczas pracy nad tworzeniem nowych funkcji i przepływów dla aplikacji.
Na przykład, oto widok z lotu ptaka pliku głównego dla jednego z moich projektów. Zauważ, że pogrupowałem i uporządkowałem ekrany według przepływu użytkownika i priorytetu rozwoju. Będę kontynuował dodawanie do tego pliku głównego, gdy będę budował kolejną sekwencję przepływów użytkownika.
Kilka zasad przewodnich do tworzenia lepszych aplikacji mobilnych
Teraz, gdy już wiesz, jak rozpocząć tworzenie makiet swoich cyfrowych doświadczeń, nadszedł czas, aby podnieść poziom swojego podejścia do projektowania. Jeśli tworzysz doświadczenie dla urządzeń mobilnych, na systemach operacyjnych takich jak iOS i Android, istnieją pewne kluczowe czynniki, o których należy pamiętać. Oto kilka ogólnych wskazówek (i kilka osobistych opinii) na temat projektowania aplikacji mobilnych i tego, jak spędzić mniej czasu na projektowaniu dla każdego typu urządzenia na rynku. Jeśli szukasz dalszych inspiracji, możesz również sprawdzić te przykłady ramek dla stron internetowych i aplikacji mobilnych.
Mam silne przekonanie, że projekt powinien być tak wszechobecny, jak to tylko możliwe. Dlatego, gdy tylko jest to możliwe, zachęcam do projektowania bez systemu operacyjnego. Oto dlaczego:
- Jeśli użytkownik przesiada się z telefonu z Androidem na iPhone’a, nie powinien być zmuszony do nauki dwóch różnych sposobów korzystania z aplikacji, która rozwiązuje tę samą potrzebę. Rozwiązanie powinno być wciąż takie samo. Wiem, że mogą istnieć różnice w gestach i możliwościach specyficznych dla danego urządzenia, ale uważam, że aplikacja powinna oferować ten sam interfejs i przepływ użytkownika niezależnie od systemu operacyjnego. I ważne funkcje nie powinny być ukryte zbyt głęboko w menu kontekstowym; to po prostu złe UX.
- Projektowanie, rozwijanie i utrzymywanie dwóch (lub więcej) całkowicie różnych doświadczeń jest kosztowne (zwłaszcza, gdy doświadczenie może być takie samo niezależnie od platformy).
- Podczas projektowania i utrzymywania różnych doświadczeń, doświadczenia mogą zacząć się bardzo różnić. To może zaszkodzić marce i sprawić, że śledzenie i wdrażanie opinii i funkcji będzie trudniejsze.
Jak więc tworzyć wszechobecne projekty i być agnostykiem urządzeń? Oto jak ja to robię:
- Traktuj moje mobilne projekty tak, jakbym projektował dla mobilnej sieci. Moje projekty są responsywne, ponieważ istnieje nieskończona liczba rozmiarów ekranów i gęstości pikseli (zmieniają się one tak szybko, jak firmy mogą je zaprojektować). Jako projektanci nie mamy czasu na projektowanie dla każdej gęstości pikseli i nie sądzę, aby moi klienci chcieli płacić za ten czas. Używam więc szerokości artboardu 375, która działa dla większości nowoczesnych modeli iPhone’a i Androida.
- Radzę sobie z dziwnym kształtem ekranu iPhone’a X i iPhone’a 11, mówiąc zespołowi dev, aby po prostu rozszerzył kolor tła nagłówka do góry.
- Mam szczęście mieć kilka różnych typów telefonów w moim zasięgu, więc mogę następnie przetestować moje projekty za pośrednictwem aplikacji mobilnej XD za pomocą USB. Jest to pomocne, ponieważ mogę testować rozmiary czcionek, punkty dotyku UI oraz widoczność zawartości ekranu, gdy klawiatura jest podniesiona. Mogę również przetestować linię „zagięcia” i upewnić się, że ważne treści, takie jak CTA i ważne treści, pozostają widoczne i nie znikają z dołu ekranu.
- Staram się używać tylko gestów, które są uniwersalne, np. stuknij, przesuń, naciśnij i przytrzymaj. Myślę, że powinniśmy być w stanie skupić się na najlepszym doświadczeniu użytkownika niezależnie od systemu operacyjnego.
- Używam SVG dla wszystkich ikon i logo, aby wyglądały świetnie na każdej rozdzielczości ekranu.
- Używam struktur nawigacji i menu, które są uniwersalne i nie są zbyt specyficzne dla systemu operacyjnego.
Jedynym momentem, w którym muszę projektować szkielety, które są specyficzne dla urządzenia, jest prototypowanie i wywoływanie funkcji natywnego urządzenia, takiego jak aparat. Nawet to może się różnić w zależności od telefonu i systemu operacyjnego.
Większość moich klientów zaczyna od iOS. Testujemy i walidujemy projekt, a gdy jest już na dobrej drodze, rozwijamy go dla Androida. I wiesz co? Staramy się nie zmieniać UI w ogóle, ani przepływu użytkowników. Zamiast tego, skupiamy się na brandingu, wyglądzie i sposobie działania, cechach i funkcjach oraz przepływie użytkowników. Wszystko to wraca do najważniejszej rzeczy: głównego doświadczenia użytkownika.
