Projektowanie aplikacji mobilnych

Projektujemy iOS i Androida razem - przepływy, makiety każdego ekranu i klikalny prototyp, który przechodzi się na telefonie, zamiast oglądać na slajdzie. Do przekazania wchodzi biblioteka komponentów zgodna z konwencjami obu platform, specyfikacja stanów krawędziowych i assety przygotowane pod wymagania sklepów.

Pracowaliśmy dla najlepszych firm i startupów

Wyzwania

Kiedy warto zacząć od projektu, nie od kodu

Aplikacja jest najdroższym typem produktu do poprawiania po starcie - każda zmiana wymaga nowego wydania i akceptacji sklepu. Poniżej cztery momenty, w których projekt oszczędza najwięcej.

  • „Zanim zamówicie development”

    Zespół developerski wyceni to, co mu opiszecie - a opis w dokumencie nigdy nie jest tak jednoznaczny, jak się wydaje przy pisaniu. Klikalny prototyp zamienia dyskusję o wyobrażeniach w rozmowę o konkretnych ekranach.

  • „Instalacje są, aktywacji nie ma”

    Pobranie kosztuje, a użytkownik, który nie dojdzie do pierwszej wartości w kilkadziesiąt sekund, nie wróci. Przeprojektowujemy onboarding i pierwszą sesję, bo tam odpada najwięcej osób.

  • „Nawigacja, w której nic już nie mieści się w menu”

    Każde wydanie dokładało ekran, aż struktura przestała odpowiadać temu, po co ludzie tę aplikację otwierają. Porządkujemy architekturę, zanim dołożycie kolejną funkcję.

  • „Android po iOS albo odwrotnie”

    Przeniesienie ekranu jeden do jednego wygląda na oszczędność, a kończy się aplikacją, która na drugiej platformie sprawia wrażenie obcej. Projektujemy różnice tam, gdzie mają znaczenie, i tylko tam.

Dla kogo

Dla kogo projektujemy aplikacje

  • Duże firmy usługowe z aplikacją dla klientów

    Aplikacja jest jednym z kanałów obok infolinii i panelu na www, a każdy z nich powstawał osobno i mówi dziś co innego. Trzeba pogodzić to, czego wymaga dział obsługi, z tym, co użytkownik chce załatwić w dwie minuty na peronie.

  • Zespoły SaaS wychodzące na telefon

    Produkt w przeglądarce działa i ma klientów, więc przeniesienie go na mniejszy ekran wygląda na naturalny krok. Na telefonie mieści się jednak ułamek funkcji, a decyzja, który to ułamek, waży więcej niż cała reszta projektu.

  • Software house'y bez projektanta w składzie

    Zespół ma moc wykonawczą i klienta, który oczekuje gotowego UX, a rekrutacja projektanta trwa dłużej niż sam projekt. Wchodzimy wtedy jako warstwa projektowa w ich proces - w rytmie ich sprintów i w ich narzędziach.

  • Firmy z aplikacją dla pracowników w terenie

    Serwisanci, kierowcy i brygady pracują w rękawicach, w hałasie i w miejscach bez zasięgu, a aplikacja powstała na wzór systemu biurowego. Liczy się liczba dotknięć do zamknięcia zlecenia i to, co dzieje się z danymi, kiedy sieć wraca.

Wydruki czterech układów interfejsu na stole: pulpit, ekran telefonu, formularz i tabela, jeden blok zakreślony markerem

Nasza różnica

Co robimy inaczej przy aplikacjach

  • Przeglądy prowadzimy na telefonie

    Każdą wersję oglądamy na fizycznym urządzeniu, nie w kadrze na monitorze. Ekran, który na dwudziestu siedmiu calach wygląda spokojnie, na sześciu calach, w słońcu i jedną ręką bywa nie do obsłużenia.

  • Wytyczne sklepów sprawdzamy na makietach

    App Store Review Guidelines i zasady Google Play dotyczą również projektu - zgód, ekranu logowania, usuwania konta, sposobu pobierania płatności. Weryfikujemy je, zanim ekrany trafią do kodu, bo odrzucenie w review kosztuje całe wydanie.

  • Przepływy konfrontujemy z zespołem, który to zakoduje

    Przed etapem interfejsu siadamy z Waszymi developerami nad mapą przepływów i zakresem pierwszej wersji. Ekran, którego nikt nie potrafi wycenić, wychodzi wtedy na makiecie, a nie dwa sprinty później.

  • Zdarzenia aktywacji ustalamy przy przepływach

    Razem z mapą ścieżek powstaje lista zdarzeń do wpięcia w analitykę i definicja momentu, w którym użytkownik dostaje pierwszą wartość. Po starcie widać wtedy, na którym kroku ludzie odpadają, zamiast domyślać się tego z ocen w sklepie.

Proces

Jak to prowadzimy

  1. Tydzień 1

    Warsztat i zakres

    Kto jest użytkownikiem, jakie ma zadanie i co w aplikacji jest naprawdę pierwszą wersją. Wychodzimy z listą funkcji podzieloną na to, co wchodzi teraz, i to, co czeka.

  2. Tydzień 1–3

    Przepływy i makiety

    Ścieżki użytkownika i układ ekranów w niskiej wierności. Tu zapadają decyzje, które w kodzie są najdroższe do cofnięcia, więc tu spędzamy najwięcej rozmów.

  3. Tydzień 3–6

    Interfejs i prototyp

    Pełne UI kluczowych ekranów i klikalny prototyp, który da się przejść na telefonie. Nie wideo i nie slajdy - działający przepływ.

  4. Tydzień 5–8

    Stany i przypadki brzegowe

    Offline, błędy sieci, puste listy, uprawnienia, powiadomienia, dostępność. To jest ta część zakresu, której brak wychodzi dopiero na testach i zawsze kosztuje wydanie.

  5. Tydzień 8–10

    Przekazanie do developmentu

    Specyfikacja zachowań, biblioteka komponentów, Dev Mode, assety i sesja przekazania. Zostajemy w kontakcie w trakcie kodowania, bo pytania pojawiają się wtedy, nie wcześniej.

Zakres

Co dostajecie na koniec

  • Mapa przepływów

    Ścieżki użytkownika od instalacji do celu, z rozgałęzieniami i punktami wyjścia. Dokument, na podstawie którego zespół developerski wycenia pracę.

  • Makiety wszystkich ekranów

    Nie kluczowe trzy. Każdy ekran, który aplikacja realnie ma, w obu platformach tam, gdzie się różnią.

  • Klikalny prototyp

    Przepływ do przejścia na telefonie - do testów z użytkownikami, do pokazania zarządowi i do rozmowy z inwestorem, jeśli taka jest w planie.

  • Biblioteka komponentów

    Komponenty z wariantami i stanami plus tokeny, zgodne z konwencjami iOS i Androida. Kolejna funkcja powstaje z niej, nie od zera.

  • Specyfikacja stanów krawędziowych

    Offline, błędy, puste listy, uprawnienia, powiadomienia, ładowanie. Rozpisane, bo to one decydują o ocenach w sklepie.

  • Assety i materiały do sklepów

    Ikona w wymaganych rozmiarach, ekran startowy i kadry do App Store i Google Play, przygotowane pod ich wytyczne.

Warsztat

Co stosujemy

Aplikację poprawia się wydaniem, a wydanie przechodzi przez recenzję sklepu, więc część reguł nie jest kwestią gustu. Poniżej zestaw, który obowiązuje w każdym projekcie niezależnie od zakresu.

Blat warsztatowy z góry: dwa wydruki układu interfejsu, lupa powiększająca jeden blok, stalowa linijka i wzornik szarości od bieli do czerni, jedna linia podkreślona pomarańczowym markerem
  • Apple Human Interface Guidelines dla iOS, Material Design dla Androida
  • Pole dotykowe nie mniejsze niż 44 pt na iOS i 48 dp na Androidzie
  • Kontrast tekstu 4,5:1, ikon i elementów sterujących 3:1
  • Skalowanie czcionki systemowej aż do największego ustawienia dostępności
  • Stan bez zasięgu i zasada synchronizacji projektowane razem z ekranem
  • Prośba o uprawnienie poprzedzona ekranem z uzasadnieniem
  • Ścieżka usunięcia konta dostępna z poziomu aplikacji
  • Ikona, ekran startowy i kadry w rozmiarach wymaganych przez oba sklepy

Następny krok

Porozmawiajmy o Waszym projekcie

Powiedzcie, co macie do zrobienia. Wracamy z zakresem i wyceną.

Realizacje

Wybór z naszego portfolio

Realizacje mobilne opisujemy w case study EzzyGuide i Fonia; pozostałe prace z tej kategorii są objęte NDA i pokazujemy je na konsultacji. Poniżej przekrój projektów z innych kategorii.

Projekty

Efekty

Na czym opieramy te terminy

  • 3 tygodnie

    tyle trwał UX i UI aplikacji EzzyGuide - 30+ makiet i klikalny prototyp, w dwuosobowym zespole

  • 4 tygodnie

    tyle zajął projekt aplikacji cashbackowej Fonia - 60+ makiet, w trzyosobowym zespole

  • 5 osób

    tylu użytkowników w teście prototypu wyłapuje większość problemów użyteczności (reguła Jakoba Nielsena, Nielsen Norman Group) - dlatego testujemy przed kodem, nie po wydaniu

Terminy pochodzą z dwóch naszych realizacji - EzzyGuide i Fonia; obie są opisane w case study na tej stronie, więc widełki z sekcji o wycenie da się do nich przyłożyć. Reguła pięciu użytkowników to publiczne ustalenie Nielsen Norman Group, nie nasza statystyka. Wyników po starcie w sklepach nie publikujemy - pokazujemy je imiennie na konsultacji, część projektów jest objęta NDA.

Opinie klientów

Co mówią nasi klienci

  • „Praca z zespołem Wzór była naprawdę świetnym doświadczeniem! Zawsze szybko odpowiadali na nasze pytania i elastycznie podchodzili do naszych uwag. Mają mnóstwo kreatywnych pomysłów, a jednocześnie są bardzo rzetelni i terminowi. Efekt końcowy w pełni spełnił nasze oczekiwania, zdecydowanie polecamy każdemu, kto szuka profesjonalistów z pasją.”
    Maja Wieloch-Silecka Dyrektor operacyjny, Bosfor Group
  • „Nasi Klienci oczekują od nas szybkiego, skutecznego działania w bardzo szerokim zakresie. Od stworzenia brandu, przez budowę strony internetowej wraz ze sklepem po przeprowadzenie skutecznej kampanii sprzedażowej. Temat niełatwy, ale do zrobienia jeśli ma się zgrany zespół i firmy, z którymi wyzwania bierze się z marszu. Dla nas jakość, odpowiedzialność i zaangażowanie są kluczowe, a współpraca z Agencją UX Wzór zapewnia nam to w 100%.”
    Piotr Alberski Chief Operating Officer, Agencja XO Media
  • „Współpraca z Agencją UX Wzór rozpoczęła się od naszej strony internetowej. Bardzo spodobał się nam sposób ich pracy. Dlatego podjęliśmy decyzję o podzlecaniu projektów realizowanych dla naszych Klientów w formie White Label. Bardzo spodobał nam się ich flow pracy, przekazywanie projektów naszemu zespołowi, ich dokumentacja czy praca na design systemie. Teraz możemy podejmować większe ryzyko.”
    Mateusz Swół Chief Operating Officer, Sellace

Zespół

Kto poprowadzi Wasz projekt

Aplikację prowadzi u nas dwuosobowy zespół projektowy - tak samo jak przy EzzyGuide. Wiecie z góry, z kim pracujecie.

  • Aleksandra Bondar

    Aleksandra Bondar

    Senior UX/UI Designer

  • Katarzyna Adamczuk

    Katarzyna Adamczuk

    Prezes, Analityk Biznesowy

  • Tadeusz Wadas

    Tadeusz Wadas

    Senior UX/UI Designer

Czas i zakres

Ile to trwa i od czego zależy wycena

8–10 tygodni

Od warsztatu do przekazania zespołowi developerskiemu. Sam development to osobny czas i osobny budżet - jeśli nie macie zespołu, pomagamy go dobrać.

  • Liczba ekranów i funkcji w pierwszej wersji

  • Jedna platforma czy obie

  • Zakres testów z użytkownikami na prototypie

  • Integracje - płatności, logowanie, mapy, systemy zewnętrzne

  • Czy istnieje już identyfikacja i biblioteka komponentów

  • Wymogi dostępności i zgodności regulacyjnej

Pytania

Pytania, które padają najczęściej

Ile kosztuje zaprojektowanie aplikacji mobilnej?

Próg wejścia mamy jawny, kwotę za konkretną aplikację ustalamy dopiero po zakresie - pierwsza wersja potrafi znaczyć piętnaście ekranów albo sześćdziesiąt, a to inne projekty i inne kwoty. Na wycenę wpływa liczba ekranów, to czy projektujemy jedną platformę czy obie, zakres testów z użytkownikami i liczba integracji. Konkretną kwotę wysyłamy w dwa dni robocze od zapytania.

Czy wycena obejmuje też zaprogramowanie aplikacji?

Nie. Wyceniamy projekt - badanie, przepływy, makiety, interfejs, prototyp i przekazanie. Development to osobny budżet i osobny czas, zwykle wielokrotność kosztu projektu. Mówimy o tym wprost na starcie, bo pomylenie tych dwóch pozycji jest najczęstszym powodem rozjazdu oczekiwań.

Projektujecie osobno na iOS i osobno na Androida?

Projektujemy jeden produkt i różnicujemy go tam, gdzie konwencje platform naprawdę się różnią - nawigacja, gesty, typografia systemowa, wzorce formularzy. Kopiowanie ekranów jeden do jednego wygląda na oszczędność, a kończy się aplikacją, która na drugiej platformie sprawia wrażenie obcej.

Co dokładnie znaczy „klikalny prototyp"?

Działający przepływ, który przechodzicie palcem na własnym telefonie - nie wideo i nie slajdy. Służy do trzech rzeczy: testu z użytkownikami przed kodem, pokazania decydentom, jak produkt naprawdę działa, i wyceny przez zespół developerski na podstawie czegoś jednoznacznego.

Testujecie projekt z użytkownikami?

Tak, na prototypie i przed kodem - to najtańszy moment na wykrycie, że ścieżka jest niezrozumiała. Zakres testów ustalamy razem, bo to jedna z pozycji, która najmocniej rusza wyceną. Jeśli budżet jest ciasny, mówimy, które decyzje warto przetestować, a które można podjąć bez badania.

Czy pomożecie znaleźć zespół, który to zaprogramuje?

Tak. Nie programujemy aplikacji mobilnych, ale przekazujemy projekt w formacie, z którego da się wycenić i kodować, i pomagamy porównać oferty zespołów developerskich. Zostajemy w kontakcie w trakcie wdrożenia, bo pytania do projektu pojawiają się właśnie wtedy.

Do kogo należą prawa do projektu?

Do Was. Majątkowe prawa autorskie do projektu przenosimy w umowie, wraz z plikami źródłowymi. Nie stosujemy licencji czasowych ani uzależnienia od dalszej współpracy z nami.

Podpisujecie NDA?

Tak, standardowo - przy aplikacjach przed premierą to raczej reguła niż wyjątek. Możemy podpisać Wasz wzór albo przesłać własny przed pierwszą rozmową merytoryczną.

Mamy już aplikację. Da się poprawić ją etapami, bez przepisywania wszystkiego?

Da się i zwykle tak właśnie robimy. Zaczynamy od ścieżki, na której tracicie najwięcej osób - najczęściej to onboarding - i projektujemy ją jako pierwszą, żeby efekt było widać przed końcem całego projektu. Jeśli chcecie zacząć od zdiagnozowania, gdzie leży problem, prowadzimy osobno audyt UX.

Umów bezpłatną konsultację z ekspertem, aby omówić Twój projekt i otrzymać odpowiedzi na nurtujące Cię pytania.

- Patryk Korycki, CEO

Zaplanuj spotkanie
Umów bezpłatną konsultację