Projektowanie UX/UI aplikacji mobilnej to według ankiety GoodFirms około 76–180 godzin pracy, czyli 2–4,5 tygodnia, i 8–20% godzin całego projektu - to najtańsze miejsce na zmiany. Poprawka na makiecie kosztuje godziny, ta sama poprawka w gotowym kodzie - dni pracy i ponowne testy.
Poniżej rozpisujemy etapy projektu z czasem i względnym kosztem, zasady onboardingu, najczęstsze powody odinstalowań, wymagania platform i dostępności oraz listę pytań, które pomogą ocenić projekt przed akceptacją.
Czym jest projektowanie UX/UI aplikacji mobilnej?
UX (user experience) odpowiada na pytanie, jak użytkownik dojdzie do celu: jakie ekrany zobaczy, w jakiej kolejności i co może pójść nie tak. UI (user interface) to warstwa wizualna: typografia, kolory, ikony, odstępy, animacje. Dobre projektowanie UX/UI aplikacji mobilnej zaczyna się od UX, a grafika przychodzi na końcu.
Efektem nie są „ładne obrazki”, tylko komplet materiałów, z których programiści zbudują aplikację bez zgadywania:
- mapa ścieżek użytkownika dla każdej roli,
- makiety wszystkich ekranów, łącznie ze stanami pustymi, błędami i ładowaniem,
- klikalny prototyp, po którym można przejść jak po gotowej aplikacji,
- projekt graficzny i biblioteka komponentów (design system),
- specyfikacja dla programistów: odstępy, zachowania, animacje, teksty.
Stany brzegowe są pomijane najczęściej. Co widzi użytkownik, gdy lista jest pusta, połączenie zerwane, a zdjęcie się nie wysłało? Projekt, który tego nie pokazuje, przerzuca te decyzje na programistę - a ten podejmie je w pośpiechu.
Ile trwa projekt UX/UI aplikacji i od czego zależy jego koszt?
Czas i koszt zależą od liczby ekranów i ról użytkowników oraz od tego, czy projekt obejmuje badania z użytkownikami. Tabela pokazuje typowy przebieg dla aplikacji z 15–25 ekranami.
| Etap | Co powstaje | Czas (dni) | Koszt (poziom względny) |
|---|---|---|---|
| Warsztat i rozmowy z użytkownikami | Cele, profile użytkowników, lista problemów do rozwiązania | 2–4 | niski |
| Architektura informacji i ścieżki | Mapa ekranów, nawigacja, scenariusze dla każdej roli | 2–4 | niski |
| Makiety (wireframes) | Układ wszystkich ekranów i stanów, bez grafiki | 4–7 | średni |
| Prototyp i testy z użytkownikami | Klikalny prototyp, pięć sesji testowych, poprawki | 4–7 | średni |
| Projekt graficzny i design system | Wygląd ekranów, komponenty, ikony, tryb ciemny | 4–7 | wysoki |
| Przekazanie i wsparcie budowy | Specyfikacja, odpowiedzi na pytania programistów | w trakcie budowy | niski |
Poziomy kosztu dotyczą aplikacji z 15–25 ekranami - najwięcej pracy pochłaniają projekt graficzny z design systemem i makiety. Aktualne ceny AppCreo znajdziesz w cenniku. Przy prostym MVP projekt często skraca się do makiet i jednego testu, a przy aplikacji z kilkoma rolami rośnie wraz z liczbą ścieżek.
Na czym nie oszczędzać? Na testach prototypu. Według Nielsen Norman Group pierwsza runda testów z pięcioma użytkownikami ujawnia około 85% problemów z użytecznością - zanim powstanie choćby linia kodu.
Jeśli liczysz cały budżet aplikacji, udział projektu interfejsu w wycenie pokazujemy w tekście ile kosztuje aplikacja mobilna. Przy pierwszej wersji produktu zakres projektu warto dopasować do kosztu i czasu MVP.
Jak zaprojektować onboarding aplikacji mobilnej, który nie zniechęca?
Onboarding to pierwsze minuty z aplikacją. Użytkownik jeszcze nic w nią nie zainwestował, więc odejście nic go nie kosztuje. Najczęstszy błąd to żądanie rejestracji, zgód i uprawnień, zanim aplikacja pokaże jakąkolwiek wartość.
Dobry onboarding w aplikacji dla klientów przebiega w tej kolejności:
- Pokaż główną korzyść na pierwszym ekranie jednym zdaniem, bez karuzeli pięciu slajdów.
- Pozwól wykonać pierwszą czynność bez konta: przejrzeć ofertę, sprawdzić dostępność, policzyć cenę.
- Poproś o rejestrację wtedy, gdy jest potrzebna, np. przy zapisie koszyka. Daj logowanie przez Apple i Google.
- Pytaj o uprawnienia w kontekście: o aparat, gdy użytkownik chce zrobić zdjęcie, o lokalizację, gdy szuka punktu w pobliżu.
- O zgodę na powiadomienia pytaj po pierwszym sukcesie i wyjaśnij, co w nich będzie.
- Zaprojektuj puste ekrany tak, żeby podpowiadały następny krok, zamiast pokazywać „brak danych”.
- Mierz, na którym kroku odpadają użytkownicy, i skracaj ten krok w kolejnych wersjach.
Kontekst ma też znaczenie techniczne. Od Androida 13 aplikacja musi poprosić o zgodę na powiadomienia, tak jak na iOS. Odmowę trudno odwrócić - użytkownik musi sam wejść w ustawienia systemu - więc pierwsza prośba musi być dobrze uzasadniona.
Onboarding w aplikacji firmowej
W aplikacji dla pracowników wygląda to inaczej: konto zakłada administrator, a użytkownik loguje się raz, najlepiej biometrią. Zamiast samouczka lepiej sprawdza się krótkie szkolenie na starcie i podpowiedzi przy funkcjach używanych rzadko.
Dlaczego użytkownicy odinstalowują aplikacje i co ma z tym wspólnego UX?
Użytkownik rzadko odinstalowuje aplikację z jednego powodu. Zwykle nakłada się kilka drobnych irytacji, a ostatnią kroplą jest powiadomienie wysłane nie w porę. Najczęstsze przyczyny da się rozwiązać już na etapie projektu:
- Wymuszona rejestracja na starcie - użytkownik nie wie jeszcze, czy aplikacja jest warta jego danych.
- Zbyt wiele powiadomień - push bez wartości uczy, że kolejne można zignorować, a potem wyłączyć.
- Niejasna nawigacja - funkcje ukryte w menu, do których nie da się wrócić tą samą drogą.
- Wolne działanie i awarie - pusty ekran ładowania zamiast szkieletu treści i informacji, co się dzieje.
- Nadmiar uprawnień - prośba o kontakty czy lokalizację bez widocznego powodu budzi nieufność.
Awarie to nie tylko problem programistów. Google Play obniża widoczność aplikacji, które przekraczają progi jakości w Android vitals, więc stabilność wpływa także na pozyskiwanie użytkowników. Jak mierzyć retencję i jakość, piszemy w tekście o KPI aplikacji mobilnej.
Retencja zaczyna się w projekcie
Aplikacja utrzymuje użytkowników, gdy wpisuje się w ich rytm. Przypomnienie o terminie, status zamówienia, punkty lojalnościowe widoczne tuż po zakupie - to elementy UX, a nie marketingu. Zaprojektuj je razem z główną ścieżką, zamiast doklejać po starcie.
Personalizacja działa, gdy jest wyczuwalna, ale nie nachalna. Ulubione produkty na górze listy, ostatnie zamówienie do powtórzenia jednym dotknięciem, powiadomienie lokalizacyjne tylko za zgodą. Kanały odzyskiwania nieaktywnych użytkowników opisujemy w tekście o promocji aplikacji mobilnej.
Opisz aplikację w 3 zdaniach - odsyłamy przedział cenowy w 24 h w dni robocze. Jeśli masz już makiety albo projekt graficzny, dołącz je - wycenimy budowę na ich podstawie. wypełnij formularz, napisz na biuro@appcreo.pl albo zadzwoń: +48 783 477 243.
Jakie wytyczne platform i zasady dostępności trzeba uwzględnić?
Apple i Google publikują własne wytyczne: Human Interface Guidelines dla iOS i Material Design dla Androida. Użytkownicy znają wzorce swojego systemu - gest powrotu, położenie przycisków, wygląd okien dialogowych - i każde odstępstwo kosztuje ich chwilę namysłu.
Nie oznacza to dwóch różnych aplikacji. Przy technologii wieloplatformowej, takiej jak Flutter, projektuje się wspólny wygląd marki i dostosowuje elementy systemowe: nawigację, przełączniki, wybór daty, zachowanie przycisku wstecz na Androidzie.
Obie firmy odświeżają swoje języki projektowe - Apple wprowadził w 2025 roku Liquid Glass, Google rozwija Material 3 Expressive. Design system oparty na własnych komponentach łatwiej dostosować do takich zmian niż ekrany projektowane pojedynczo.
Minimalne rozmiary i kontrast
Przyciski muszą dać się trafić kciukiem. Apple zaleca obszar dotyku co najmniej 44 × 44 punkty, Google 48 × 48 dp, a WCAG 2.2 na poziomie AA wymaga minimum 24 × 24 piksele CSS. Zwykły tekst powinien mieć kontrast co najmniej 4,5:1 względem tła.
Aplikacja musi też działać przy powiększonej czcionce systemowej, w trybie ciemnym i z czytnikiem ekranu. Te wymagania warto zapisać w briefie, bo dodane po fakcie oznaczają przebudowę wielu ekranów.
Dostępność to także obowiązek prawny
Od 28 czerwca 2025 roku aplikacje w handlu internetowym, bankowości i transporcie pasażerskim podlegają wymaganiom dyrektywy 2019/882. W Polsce wdraża ją ustawa o zapewnianiu spełniania wymagań dostępności niektórych produktów i usług przez podmioty gospodarcze. Mikroprzedsiębiorstwa usługowe są zwolnione.
Ikona i zrzuty ekranu to też UX
Ikona i zrzuty ekranu w sklepie to pierwszy kontakt z aplikacją. Dlatego ikona powinna być czytelna w małym rozmiarze i nie powtarzać nazwy. Zrzuty pokazują korzyści, a nie ekran logowania. Jak przygotować kartę aplikacji, opisujemy w przewodniku ASO - pozycjonowanie aplikacji.
Jak ocenić projekt UX/UI aplikacji przed akceptacją?
Akceptacja projektu to ostatni tani moment na zmiany. Nie oceniaj go wyłącznie po tym, czy Ci się podoba. Przejdź przez prototyp z pytaniami:
- Czy najważniejszą czynność da się wykonać w trzech–czterech dotknięciach od uruchomienia?
- Czy każdy ekran ma zaprojektowany stan pusty, ładowanie i błąd?
- Czy projekt pokazuje, co dzieje się bez zasięgu?
- Czy teksty są napisane językiem użytkownika, a nie wewnętrznymi nazwami działów?
- Czy przyciski główne są w zasięgu kciuka, a akcje nieodwracalne wymagają potwierdzenia?
- Czy prototyp przeszło co najmniej pięć osób z grupy docelowej i wiesz, co poprawiono po testach?
- Czy dostajesz pliki źródłowe projektu i prawa do nich razem z aplikacją?
Jeśli projektowanie UX/UI aplikacji mobilnej jest częścią zlecenia całej aplikacji, sprawdź, czy ma w harmonogramie osobny punkt z akceptacją. Jak ułożyć cały proces, opisujemy w przewodniku jak zlecić aplikację mobilną, a naszą usługę - na stronie tworzenie aplikacji mobilnych.
Kiedy interfejs jest samym produktem
Nails Room nakłada kolory i zdobienia na paznokcie na zdjęciu lub w czasie rzeczywistym przez kamerę, z użyciem rozszerzonej rzeczywistości. W takich aplikacjach testy prototypu są jeszcze ważniejsze, bo efekt na ekranie jest tym, za co płaci użytkownik. Zobacz opis realizacji Nails Room.
