Projektowanie aplikacji webowych
Projektujemy aplikację, która działa w przeglądarce - role i uprawnienia, architekturę modułów, wzorce widoków i komplet stanów, w których użytkownik narzędzia spędza większość dnia pracy. Do ręki dostajecie bibliotekę komponentów danych, katalog stanów i dokumentację zachowań, z których Wasz zespół składa kolejne moduły bez wracania do nas po każdą decyzję.
Pracowaliśmy dla najlepszych firm i startupów
Wyzwania
Kiedy panel wymaga projektu, a nie kolejnej funkcji
Narzędzie ocenia się inaczej niż stronę - użytkownik nie przyszedł popatrzeć, tylko wykonać zadanie, często dziesiąty raz tego dnia. Poniżej cztery sytuacje, w których projekt zwraca się najszybciej.
-
„Interfejs odzwierciedla bazę danych, nie pracę użytkownika”
Ekrany powstawały wokół tabel w bazie, a nie wokół zadań. Efekt: proste zadanie wymaga przejścia przez cztery widoki, bo tak wygląda model danych. Porządkujemy to od strony zadania.
-
„Kluczowe rzeczy dzieją się w Excelu obok”
Najpewniejszy sygnał, że narzędzie nie pasuje do pracy. Arkusz obok systemu to nie lenistwo użytkownika, tylko lista brakujących funkcji zapisana jego ręką. Zaczynamy od jej odczytania.
-
„Systemu trzeba się nauczyć, zamiast go używać”
Jeśli narzędzia nie da się obsłużyć bez szkolenia i ściągi, koszt rośnie z każdą rotacją. Projektujemy tak, żeby najczęstsze zadania były wykonalne bez instruktażu.
-
„Funkcje macie, ale demo nie robi wrażenia”
W przetargu i na demo produkt ocenia się w kilkanaście minut, głównie po tym, jak wygląda i jak szybko widać w nim wartość. To jest ta sytuacja, w której warstwa wizualna ma realny wpływ na sprzedaż.
Dla kogo
Dla kogo projektujemy panele i systemy
-
Zespoły operacyjne w dużych firmach
Obsługa zleceń, rozliczenia i logistyka pracują na jednym systemie od lat, a on jest zbyt krytyczny, żeby wyłączyć go na kwartał. Nikt nie ma przy tym pełnej mapy tego, jak sprawa przechodzi dziś przez wszystkie działy.
-
Dostawcy oprogramowania dla jednej branży
Ten sam panel trafia do kilkudziesięciu klientów, a każdy prosi o własne pola, słowniki i wyjątki. Rozstrzygnięcia wymaga to, co mieści się w konfiguracji jednego wzorca, a co staje się osobną wersją utrzymywaną potem latami.
-
Firmy z CRM-em albo ERP-em z pudełka
Standardowy system pilnuje danych, ale codzienna praca dzieje się w nakładkach, raportach i integracjach dorabianych przez kolejne zespoły. Użytkownik przechodzi między nimi kilka razy dziennie i za każdym razem trafia na inne nazwy tego samego pola.
-
Organizacje prowadzące sprawy pod terminem
Pracownik zamyka sprawę w reżimie terminu umownego albo ustawowego, a każdy jego krok musi zostawić ślad i mieścić się w uprawnieniach. Interfejs ma tu dwa zadania naraz - skrócić obsługę i nie dopuścić do czynności, której później nie da się obronić.
Nasza różnica
Co odróżnia nasz projekt systemu
-
Czas najczęstszego zadania mierzymy przed i po
Na starcie liczymy, ile kroków i ile minut zajmuje dziś zadanie wykonywane najczęściej, a ten sam pomiar powtarzamy na prototypie. Decyzja o układzie widoku zapada wtedy na różnicy między dwiema liczbami, nie na wrażeniu z przeglądu.
-
Prototyp obsłużony z klawiatury
Osoba pracująca na systemie codziennie porusza się skrótami, więc projektujemy kolejność fokusu, skróty, zaznaczanie wielu wierszy i wprowadzanie danych bez sięgania po mysz. Prototyp przechodzi test, w którym mysz zostaje odłożona na bok.
-
Rysujemy w bibliotece, na której stoi Wasz front
Jeśli zespół pracuje na MUI, Ant Design albo własnym design systemie, projekt powstaje na jego komponentach i tokenach, a nie obok nich. Wdrożenie sprowadza się wtedy do konfiguracji istniejących elementów zamiast do odtwarzania ich od nowa.
-
Przejście ze starego panelu jest częścią projektu
Ludzie, którzy znają obecny system na pamięć, tracą na nowym układzie pierwsze tygodnie, więc ustalamy kolejność przełączania modułów i te przyzwyczajenia, które zostawiamy nietknięte. Do przekazania wchodzi opis różnic dla osób prowadzących wdrożenie po Waszej stronie.
Proces
Jak to prowadzimy
- Tydzień 1–2
Role i zadania
Kto korzysta z systemu, co robi najczęściej i gdzie traci czas. Wychodzimy z mapą ról i listą zadań uszeregowaną częstością, bo to ona wyznacza, co projektujemy najstaranniej.
- Tydzień 2–4
Architektura i nawigacja
Struktura modułów, uprawnienia i sposób poruszania się między nimi. W narzędziu używanym codziennie nawigacja jest kosztem stałym - każdy zbędny poziom mnoży się przez liczbę zadań.
- Tydzień 3–6
Wzorce widoków
Lista, szczegół, formularz, kreator, ustawienia. Projektujemy wzorce, a nie ekrany - dzięki temu setny widok wygląda jak pierwszy i nie wymaga osobnej decyzji.
- Tydzień 5–9
Komponenty danych i stany
Tabele, filtry, sortowanie, paginacja, stany puste, ładowanie, błędy i uprawnienia. Użytkownik narzędzia spędza w tych stanach większość czasu, więc traktujemy je jak główny zakres.
- Tydzień 9–12
Przekazanie i wsparcie wdrożenia
Dokumentacja zachowań, biblioteka komponentów, Dev Mode i sesja przekazania. Zostajemy dostępni w trakcie kodowania, bo pytania o stany pojawiają się dopiero wtedy.
Zakres
Co dostajecie na koniec
-
Mapa ról i uprawnień
Kto co widzi i co może zrobić, w rozbiciu na moduły. Dokument, z którego korzysta zarówno projekt, jak i zespół backendowy.
-
Architektura i nawigacja
Struktura modułów i ścieżki między nimi, zaprojektowane pod najczęstsze zadania, a nie pod kompletność menu.
-
Wzorce kluczowych widoków
Lista, szczegół, formularz, kreator, ustawienia - jako wzorce z regułami, dzięki którym kolejne ekrany powstają bez nowych decyzji projektowych.
-
Biblioteka komponentów danych
Tabele, filtry, wykresy, pola formularzy, komunikaty - z wariantami, stanami i tokenami. To ona decyduje o tempie dokładania funkcji przez kolejne lata.
-
Katalog stanów
Puste listy, ładowanie, brak uprawnień, błędy walidacji i serwera, dane częściowe. Rozpisane, bo to w nich użytkownik narzędzia spędza większość czasu.
-
Dokumentacja dla developerów
Specyfikacja zachowań, breakpointów i przypadków brzegowych, Dev Mode w Figmie i sesja przekazania z zespołem wdrażającym.
Warsztat
Co stosujemy
Narzędzie ocenia się przez lata, nie przez pierwszy tydzień, więc zestaw reguł jest w każdym projekcie ten sam. Poniżej to, od czego nie odstępujemy, nawet gdy zakres jest wąski.
- WCAG 2.2 AA jako kryterium odbioru makiet, nie audyt po wdrożeniu
- Kontrast tekstu 4,5:1, elementów sterujących 3:1, mierzony w pliku
- Komponenty z wariantami, stanami i tokenami, gotowe do Dev Mode
- Katalog stanów przy każdym wzorcu - pusty, ładowanie, błąd, brak uprawnień
- Widoki danych projektowane na rzeczywistej próbce z Waszej bazy
- Punkty łamania liczone od najmniejszego monitora w Waszym zespole
- Nazwy pól, statusów i komunikatów spisane w jednym słowniku
- Dokumentacja zachowań i przypadków brzegowych powstaje razem z makietą
Następny krok
Porozmawiajmy o Waszym projekcie
Powiedzcie, co macie do zrobienia. Wracamy z zakresem i wyceną.
Realizacje
Aplikacje i panele, które zaprojektowaliśmy
Wybór z realizacji oznaczonych tym typem produktu. Większość prac tej kategorii powstaje pod NDA, więc pełny zestaw pokazujemy na konsultacji.
-
WygodnaDieta - Aplikacja i sklep internetowy diety pudełkowej
-
NeoBank - Koncepcja aplikacji bankowej dla młodych klientów
-
myAzymut - Koncepcja portalu klienta dla firmy transportowej
-
Puls CRM - Koncepcja aplikacji CRM dla zespołu sprzedaży
-
Flotino - Serwis internetowy z pożyczkami gotówkowymi
-
Fonia - Aplikacja cashback dla osób kupujących online
-
EzzyGuide - Aplikacja z wycieczkami łącząca przewodników i turystów
-
VERSA - Koncepcja Panelu B2B dla dystrybutora części
-
Tip Card - Platforma napiwków bezgotówkowych
-
Jawny Lublin - Portal obywatelski o jawności miasta
-
Bosfor Charter - Platforma wynajmu i czarteru jachtów
-
Wolumen - Porównywarka cen energii i gazu dla firm
Efekty
Co zostaje u Was po projekcie
-
Na własność
biblioteka komponentów danych i katalog stanów - puste listy, ładowanie, brak uprawnień, błędy walidacji i serwera - wchodzą do przekazania w komplecie, nie jako plik do oglądania
-
72 widoki w 2 miesiące
skala i tempo projektu CWZN z naszego portfolio - punkt odniesienia dla panelu o kilkudziesięciu widokach, prowadzonego w trzyosobowym zespole
-
101
tyle realizacji leży w publicznym portfolio na tej stronie - obejrzycie je, zanim do nas napiszecie
-
22
tyle branż jest reprezentowanych w tym portfolio - sprawdzicie, czy pracowaliśmy już w Waszej
Liczby z projektu CWZN pochodzą z jego publicznego case study, a 101 realizacji z 22 branż jest do przejrzenia w portfolio na tej stronie - stan na sierpień 2026. Biblioteka komponentów i katalog stanów to pozycje z listy przekazania wyżej, nie deklaracja marketingowa. Nie podajemy średniej oszczędności czasu ani wyników po wdrożeniu - panele powstają w większości pod NDA, więc konkretne wdrożenia omawiamy imiennie na konsultacji.
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
Przy narzędziu najwięcej zależy od tego, czy ktoś dobrze odczyta pracę Waszego zespołu - dlatego projekt prowadzi para projektant i konsultant.
-
Aleksandra Bondar
Senior UX/UI Designer
-
Katarzyna Adamczuk
Prezes, Analityk Biznesowy
-
Patryk Korycki
CEO, Analityk Biznesowy
-
Tadeusz Wadas
Senior UX/UI Designer
Czas i zakres
Ile to trwa i od czego zależy wycena
8–14 tygodni
Od warsztatu do przekazania zespołowi developerskiemu. Przy aplikacji rozwijanej równolegle pracujemy modułami, żeby wdrożenie mogło ruszyć przed końcem całego projektu.
-
Liczba modułów, ról i poziomów uprawnień
-
Liczba i złożoność widoków danych
-
Czy istnieje już design system albo biblioteka komponentów
-
Integracje i liczba systemów źródłowych
-
Wymogi dostępności (WCAG) i zgodności regulacyjnej
-
Zakres badań i testów z realnymi użytkownikami
Pytania
Pytania, które padają najczęściej
Ile kosztuje zaprojektowanie aplikacji webowej?
Próg wejścia mamy jawny, sama kwota końcowa czeka na zakres - przy narzędziach liczba widoków danych potrafi różnić się dziesięciokrotnie przy tej samej nazwie produktu. Na wycenę wpływa liczba modułów i ról, liczba i złożoność widoków danych, wymogi dostępności i to, czy istnieje już biblioteka komponentów. Konkretną kwotę wysyłamy w dwa dni robocze od zapytania.
Czy wycena obejmuje zaprogramowanie aplikacji?
Nie. Wyceniamy projekt - badanie, architekturę, wzorce widoków, komponenty, katalog stanów i przekazanie. Development to osobny budżet. Wspieramy zespół wdrażający w trakcie kodowania i to jest w zakresie, ale samego kodu aplikacji nie piszemy.
Mamy działający panel. Da się go poprawiać etapami?
Tak i przy narzędziach zwykle tak jest najrozsądniej. Zaczynamy od zadania, które zespół wykonuje najczęściej albo które najbardziej boli, i projektujemy je jako pierwsze. Efekt widać przed końcem całego projektu, a Wy nie zamrażacie rozwoju systemu na kwartał.
Skąd wiecie, jak wygląda praca naszego zespołu?
Pytamy i patrzymy. Rozmowy z użytkownikami, obserwacja realnej pracy na systemie oraz dane o tym, które ekrany są używane najczęściej. Najbardziej wartościowy sygnał to zwykle arkusz kalkulacyjny prowadzony obok systemu - to lista brakujących funkcji zapisana ręką użytkownika.
Czy projekt obejmuje stany puste, błędy i brak uprawnień?
Tak, jako osobna pozycja zakresu. To jest różnica między projektem aplikacji a projektem kilku ładnych ekranów. Użytkownik narzędzia spędza w tych stanach większość czasu, a ich brak w projekcie kończy się improwizacją na etapie kodowania i niespójnym systemem.
Projektujecie pod WCAG?
Tak, i przy systemach dla instytucji publicznych oraz dużych firm traktujemy to jako wymóg, nie opcję. Kontrast, obsługa z klawiatury, etykiety i komunikaty o błędach są uwzględnione w komponentach, więc dostępność nie jest doklejana na końcu. Prowadzimy też osobne audyty dostępności.
Czy biblioteka komponentów przyda się nam później, czy to tylko materiał do projektu?
To główna wartość długoterminowa tego projektu. Komponenty z wariantami, stanami i tokenami sprawiają, że kolejny moduł powstaje z gotowych elementów, bez nowych decyzji projektowych i bez zamawiania projektu za każdym razem.
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.
Nie wiemy jeszcze, czy problem leży w interfejsie, czy w procesie. Od czego zacząć?
Od diagnozy, nie od projektu. Prowadzimy osobno audyty UX i badania użytkowników - kończą się listą problemów uszeregowaną wpływem, z której wynika zakres projektu. To tańsze niż przeprojektowanie systemu na podstawie założeń.
Powiązane usługi