Ładne obrazki, z których nie da się zbudować
Programista otwiera plik i nie znajduje ani stanu pustego, ani błędu, a odstępy na każdym ekranie są inne. Resztę dopowiada po swojemu — i produkt rozjeżdża się z makietą.
Projektowanie UI/UX aplikacji — od badań do gotowego interfejsu
Ścieżki użytkownika, wireframes, design system i klikalny prototyp. Projekt, po którym programista buduje, a nie zgaduje. Pracujemy też bez późniejszej realizacji — jeśli kodujesz własnym zespołem, dostajesz komplet materiałów i prawa do projektu.
Z czym przychodzą klienci
Użytkownicy nie dochodzą do celu
Ruch jest, rejestracji nie ma, a onboardingu, formularza i ekranu płatności nikt nie przeszedł na żywym scenariuszu. Nie wiadomo, na którym kroku odpadają — poprawiasz w ciemno.
Każdy nowy ekran rysowany od zera
Po roku w produkcie są trzy odcienie tego samego przycisku i cztery warianty tej samej tabeli. Dodanie funkcji trwa dłużej — bo wygląd ustalacie od nowa.
Co wchodzi w zakres
Badania i scenariusze
Zadania użytkowników i ścieżki, którymi je realizują
Architektura informacji
Struktura ekranów, nawigacja i podział na role
Wireframes
Szkielety kluczowych ekranów, bez kolorów i grafik
Interfejs (UI)
Ekrany na siatce, z kontrastem sprawdzonym pod WCAG
Design system
Kolory, typografia, skala odstępów i komponenty ze stanami
Klikalny prototyp
Główne ścieżki połączone przejściami, na telefonie i desktopie
Wychodzisz z kompletem plików i prawami do projektu
- Wireframes kluczowych ekranów, razem ze stanem pustym i błędem
- Ekrany UI dla telefonu i desktopu, ze stanami
- Design system: kolory, typografia, skala odstępów i biblioteka komponentów
- Plik źródłowy i prawa do projektu po Twojej stronie
Jak pracujemy
Rozmowa i zakres
1–2 dniUstalamy cel produktu, kto z niego korzysta, jakie są ograniczenia techniczne i budżet. Spisujemy też, na jakich urządzeniach produkt ma działać i z czym musi się zgadzać: istniejącą marką, gotową biblioteką komponentów albo wymaganiami sklepów. Wychodzimy z listą ekranów do zaprojektowania, terminem i ceną.
Badania i scenariusze
2–4 dniPrzeglądamy obecny produkt, rozwiązania konkurencji i dane z analityki. Spisujemy zadania użytkownika, kroki, w których dziś się zatrzymuje, oraz urządzenia i przeglądarki, z których korzysta najczęściej — to przesądza, który układ projektujemy najpierw.
Architektura i wireframes
3–5 dniUkładamy strukturę, nawigację i szkielety ekranów. Już na szkicach ustalamy, co użytkownik widzi przy pustych danych i po błędzie, żeby te ekrany nie powstawały później w pośpiechu. Uwagi zbieramy na szkicach, zanim powstanie warstwa graficzna — poprawka kosztuje wtedy najmniej.
UI i design system
5–10 dniProjektujemy ekrany i równolegle budujemy bibliotekę komponentów. Sprawdzamy kontrast, rozmiar obszarów dotyku i czytelność na małych ekranach. Ekrany oddajemy partiami, co kilka dni, więc widzisz kierunek na bieżąco i nie czekasz z uwagami do końca etapu.
Prototyp i testy
2–3 dniŁączymy ekrany w klikalny prototyp i przechodzimy nim scenariusze od wejścia do celu, razem z cofnięciem i anulowaniem kroku. Uwagi zbieramy w jednym miejscu, w komentarzach przy ekranach, i odhaczamy po wprowadzeniu. Poprawki wchodzą do makiet, a nie do gotowego kodu.
Przekazanie zespołowi
1–2 dniPorządkujemy plik, opisujemy komponenty i specyfikację, oddajemy dostępy oraz link do prototypu. Przechodzimy przez plik z programistami na wspólnym spotkaniu: gdzie leżą komponenty, jak czytać zmienne, skąd brać eksporty i który ekran odpowiada któremu krokowi scenariusza. Zostajemy dostępni na pytania w trakcie wdrożenia.
Co dostaje zespół programistyczny
To miejsce, w którym najczęściej sypie się współpraca z projektantem. Poniżej dokładnie to, co trafia do programistów — niezależnie od tego, czy wdrażamy my, czy Twój zespół.
Uporządkowany plik Figma
Osobna strona na każdy przepływ, nazwane warstwy, ekrany w kolejności scenariusza. Wersje robocze oddzielone od zatwierdzonych.
Komponenty ze stanami
Każdy element ma warianty: domyślny, najechany, aktywny, wyłączony, ładowanie i błąd. Nazwy wariantów są takie same jak propsy w kodzie.
Design system, nie stos ekranów
Kolory, typografia i odstępy zapisane jako zmienne, nazwane według zastosowania. Zmiana w bibliotece rozchodzi się na wszystkie ekrany.
Specyfikacja odstępów, typografii i breakpointów
Skala odstępów, style tekstu z nazwami i rolą, siatka dla telefonu, tabletu i desktopu. Programista czyta wartości, zamiast mierzyć piksele na zrzucie.
Klikalny prototyp jako punkt odniesienia
Przejścia, kolejność kroków i zachowanie po błędzie widać w prototypie. Przekazujemy go linkiem, który otwiera się w przeglądarce i na telefonie.
Eksport i nazewnictwo zasobów
Ikony w SVG i grafiki w formatach dla web, iOS i Androida, nazwane tak samo jak w projekcie. Programista nie eksportuje niczego ręcznie.
Ścieżki brzegowe i dostępność
Pusta lista, brak internetu, odrzucona płatność, wygasła sesja — każda sytuacja ma ekran i treść komunikatu. Kontrast i obszary dotyku sprawdzone pod WCAG.
Narzędzia
- Figma
- Auto Layout
- Zmienne i tokeny
- Prototypowanie w Figmie
- FigJam
- WCAG 2.2
- Apple HIG
- Material Design 3
- React
- TypeScript
Projekty, w których to widać
Najczęstsze pytania
Ile kosztuje projekt UX/UI aplikacji?
Po rozmowie o zakresie — cenę podajemy przed startem prac. Wpływa na nią liczba ekranów i ról, liczba platform oraz to, czy design system już istnieje. Badania i testy z użytkownikami wyceniamy osobno.
Ile trwa projektowanie?
2–4 tygodnie od zatwierdzenia zakresu: kilka dni na badania i architekturę, tydzień do dwóch na UI i design system, kilka dni na prototyp. W ramach MVP projekt mieści się w 3–5 tygodni po ustaleniu zakresu.
Czy projektujecie bez późniejszej realizacji?
Tak. Plik źródłowy, design system i prawa do projektu są Twoje — możesz oddać je własnemu zespołowi albo innemu wykonawcy. Zostajemy dostępni na pytania w trakcie wdrożenia.
Co dostaje zespół programistyczny?
Uporządkowany plik Figma, bibliotekę komponentów ze stanami, zmienne kolorów i typografii, specyfikację odstępów i breakpointów, eksport ikon oraz klikalny prototyp. Do tego ścieżki brzegowe: pusta lista, błąd sieci, wygasła sesja.
Czy robicie audyt istniejącej aplikacji?
Tak. Przechodzimy główne scenariusze i zbieramy problemy nawigacji, formularzy, kontrastu, stanów i komunikatów błędów. Listę porządkujemy według wpływu na konwersję, a dla najważniejszych punktów oddajemy gotowe makiety.