Modernizacja aplikacji

Bezpłatna konsultacja Projekty

Produkt działa, zarabia i ma użytkowników, których nie da się na pół roku odciąć od pracy. Zakładamy na niego nowy interfejs partiami - ekran po ekranie, na tych samych danych, za przełącznikiem, który cofa się tego samego dnia.

Pracowaliśmy dla najlepszych firm i startupów

Wyzwania

Trzy momenty, w których modernizacja wyprzedza przepisanie od zera

Nie wiesz, czy Twój przypadek to modernizacja, czy jednak nowy produkt? Umów konsultację - powiemy wprost także wtedy, gdy przepisanie wyjdzie taniej.

  • „Rewrite został wyceniony i odłożony”

    Ktoś policzył koszt napisania systemu od nowa, zarząd zobaczył liczbę i temat wrócił do szuflady. Interfejs starzeje się dalej, bo jedyny rozważany wariant był wariantem wszystko albo nic.

  • „Interfejs przegrywa demo, choć produkt wygrywa funkcjami”

    Handel dostaje pytania o wygląd wcześniej niż o możliwości, a młodszy konkurent robi wrażenie samym pierwszym ekranem. Różnicy nie widać w changelogu, tylko na spotkaniu sprzedażowym.

  • „Nowa osoba uczy się systemu z instrukcji, nie z ekranu”

    Wdrożenie operatora opiera się na dokumencie, wewnętrznym szkoleniu i koledze z sąsiedniego biurka. Interfejs, który wymaga tłumaczenia, kosztuje przy każdej rekrutacji i przy każdym nowym kliencie.

Dla kogo

Dla kogo modernizujemy aplikacje

  • Producenci oprogramowania z długą historią wersji

    Produkt sprzedaje się od lat, ma komplet funkcji i klientów, których nie da się przenieść z dnia na dzień. Nowy interfejs powstaje tak, żeby dało się go włączać instancja po instancji, bo część odbiorców będzie chciała zostać przy starym widoku jeszcze przez jeden cykl budżetowy.

  • Zespoły utrzymujące system wewnętrzny bez budżetu na rewrite

    Aplikacja niesie codzienną pracę działu, a jej przepisanie nigdy nie wygra priorytetu z roadmapą sprzedażową. Migracja idzie z bieżącego budżetu utrzymaniowego, ekranami, które najczęściej trafiają do zgłoszeń serwisowych.

  • SaaS, który przerósł swój pierwszy interfejs

    Nawigacja projektowana pod pięć funkcji obsługuje dziś czterdzieści, a nowe moduły doklejane są tam, gdzie akurat było miejsce. Porządkujemy architekturę widoków i wprowadzamy ją stopniowo, żeby obecni klienci nie zastali innego produktu po jednym logowaniu.

  • Firmy z aplikacją, której nie wolno wyłączyć

    System pracuje w trybie ciągłym, a okno serwisowe liczy się w minutach i wymaga zgody poza zespołem produktowym. Każde wydanie planujemy z warunkiem wejścia i procedurą powrotu, więc zmiana interfejsu nie wymaga zatrzymania operacji.

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

Nasza różnica

Czym różni się nasze podejście

  • Zaczynamy od jednego ekranu na produkcji

    Pierwszym efektem nie jest komplet makiet, tylko jeden widok przepuszczony przez całą drogę aż do użytkowników. Dopiero on pokazuje, gdzie nowy interfejs zderza się z realnymi danymi, uprawnieniami i przyzwyczajeniami zespołu - i jest to wiedza z produkcji, a nie z prototypu.

  • Nie ruszamy kontraktów danych

    Backend zostaje tam, gdzie jest. Różnice między tym, czego potrzebuje nowy widok, a tym, co oddaje istniejące API, pokrywamy warstwą pośrednią po stronie interfejsu. Zmiany w backendzie zbieramy jako osobną listę z uzasadnieniem, żeby były decyzją, a nie skutkiem ubocznym redesignu.

  • Każde wydanie ma drogę powrotu

    Nowy ekran wchodzi za przełącznikiem, na wskazaną grupę użytkowników, z ustalonym z góry warunkiem wycofania. Powrót do starego widoku jest operacją na minuty i nie wymaga wydania awaryjnego, więc zespół nie odkłada wdrożenia na spokojniejszy tydzień.

  • Wygaszenie starego interfejsu jest w zakresie

    Zadanie kończy się w momencie, w którym stare widoki znikają z kodu, a nie w momencie oddania nowych. Najdroższy scenariusz modernizacji to dwa interfejsy utrzymywane obok siebie przez lata - dlatego data ich rozdzielenia stoi w planie wydań od pierwszego tygodnia.

Proces

Od spisu ekranów do wygaszenia starego interfejsu

  1. Tydzień 1–2

    Inwentaryzacja ekranów i ruchu

    Przechodzimy produkt widok po widoku razem z Waszym zespołem i analityką. Wychodzi z tego lista ekranów z ruchem, rolami i miejscami, w których użytkownicy tracą najwięcej czasu.

  2. Tydzień 2–3

    Kolejność i podział na wydania

    Ustalamy, co przechodzi na nowy interfejs najpierw, a co czeka. Kolejność bierze się z kosztu operacyjnego i ryzyka wdrożenia, nie z tego, który ekran ładniej wygląda w portfolio.

  3. Tydzień 3–6

    Pierwszy ekran end-to-end

    Jeden pełny widok przechodzi całą drogę - projekt, komponenty, integracja z istniejącym API, testy z użytkownikami, wejście na produkcję za przełącznikiem. To on weryfikuje założenia całej migracji.

  4. Tydzień 6 i dalej

    Kolejne partie ekranów

    Migracja idzie wydaniami wpisanymi w Wasze sprinty. Stary i nowy widok żyją obok siebie, a udział ruchu na nowym interfejsie rośnie w tempie, które kontrolujecie Wy, nie kalendarz projektu.

  5. Ostatnie wydanie

    Wygaszenie starych widoków

    Ostatnie wydanie usuwa przełączniki i stary kod interfejsu. Bez tego kroku modernizacja kończy się dwoma interfejsami utrzymywanymi równolegle, czyli kosztem większym niż przed startem.

Zakres

Trzy rzeczy. Nie prezentacja z nowym wyglądem

  • Mapa migracji ekranów

    Spis wszystkich widoków produktu z ruchem, rolami użytkowników i kosztem operacyjnym każdego z nich. Do tego kolejność przechodzenia na nowy interfejs, podział na wydania i termin, w którym stare widoki znikają z kodu.

  • Nowe ekrany gotowe do wdrożenia

    Projekty w Figmie i komponenty w Waszym stacku, zbudowane na kontraktach danych, które już macie. Każda partia wchodzi na produkcję osobno, więc pierwsze ekrany pracują, zanim powstaną ostatnie.

  • Plan wydań i wycofania

    Dla każdej partii jedno miejsce z kompletem ustaleń: zakres, warunek wejścia, grupa użytkowników, mierniki do obserwacji i procedura powrotu do starego widoku. Po wydaniu dokładamy raport pokrycia.

Warsztat

Co stosujemy

Modernizacja żywego systemu to w połowie projektowanie, a w połowie kolejność i odwracalność zmian. Stąd zestaw, w którym obok standardów interfejsu stoją wzorce wdrożeniowe.

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
  • Strangler Fig Pattern (Martin Fowler)
  • Feature flagi i wydania kanarkowe
  • WCAG 2.2 AA accessibility
  • Design Tokens W3C standard
  • Core Web Vitals (LCP, INP, CLS)
  • Testy moderowane na zadaniach z produkcji

Następny krok

Porozmawiajmy o Waszym projekcie

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

Bezpłatna konsultacja Projekty

Realizacje

Realizacje z produktów, które modernizujemy najczęściej

Wybór projektów z tych typów systemów, przy których modernizacja pojawia się u nas najczęściej - paneli operacyjnych, aplikacji webowych i platform sprzedawanych klientom biznesowym. Mapy migracji powstają w systemach klientów, więc pokazujemy je na konsultacji.

Projekty

Efekty

Co dostajecie, w jakim terminie i po czym to sprawdzicie

  • 6 tygodni

    Tyle dzieli brief od pierwszego widoku wypuszczonego na produkcję za przełącznikiem, razem z testami i integracją

  • Ten sam backend

    Nowy interfejs siada na istniejących API i kontraktach danych - różnice pokrywamy adapterem po stronie interfejsu

  • WCAG 2.2 AA

    Publiczny standard dostępności W3C, wobec którego sprawdzamy każdy ekran, zanim wejdzie do wydania

  • Raport co wydanie

    Po każdej partii podajemy udział ruchu obsługiwanego przez nowy interfejs, więc postęp migracji jest liczbą, a nie wrażeniem

Terminy i zakres wydań pochodzą z harmonogramu opisanego wyżej na tej stronie, a WCAG 2.2 AA to publiczny standard W3C. Nie uśredniamy wyników wdrożeń u klientów - mapy migracji i raporty pokrycia żyją w systemach klientów, więc pokazujemy je 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

Czas i zakres

Ile trwa modernizacja i od czego zależy wycena

6–16 tygodni

Sześć tygodni to droga do pierwszego widoku działającego na produkcji. Pełna migracja mierzy się liczbą wydań, nie jedną datą - przy kilkudziesięciu ekranach, wielu rolach albo kilku instancjach produktu rozkłada się na kilkanaście tygodni i dalej, dlatego zakres tniemy tak, żeby każde wydanie samo w sobie coś naprawiało.

  • Liczba ekranów i ról użytkowników objętych migracją

  • Stan istniejącego API i to, ile trzeba pokryć warstwą pośrednią

  • Stack frontendowy oraz możliwość wpięcia przełączników wydań

  • To, czy kod piszemy my, Wasz zespół, czy obie strony razem

  • Liczba instancji produktu, na które nowy interfejs ma wejść

Pytania

Pytania, które padają najczęściej

Ile kosztuje modernizacja aplikacji?

Wyceniamy indywidualnie, bo dwa produkty o tej samej liczbie ekranów potrafią różnić się kosztem kilkukrotnie. Na wycenę wpływa liczba widoków i ról objętych migracją, stan istniejącego API i to, ile trzeba pokryć warstwą pośrednią, możliwość wpięcia przełączników wydań w Wasz stack, podział pracy między nasz zespół a Wasz oraz liczba instancji produktu, na które nowy interfejs ma wejść. Wstępny zakres i podział na wydania dostajesz w trzy dni robocze od briefu, a wiążącą propozycję po inwentaryzacji ekranów.

Czy trzeba przy tym przepisać backend?

Nie. Punktem wyjścia jest założenie, że backend zostaje tam, gdzie jest, a nowy interfejs siada na istniejących API i kontraktach danych. Różnice między tym, czego potrzebuje nowy widok, a tym, co oddaje obecny endpoint, pokrywamy warstwą pośrednią po stronie interfejsu. Zmiany, których naprawdę nie da się obejść, zbieramy jako osobną listę z uzasadnieniem i kosztem, żeby były Waszą decyzją, a nie efektem ubocznym redesignu.

Czym to się różni od audytu UX?

Audyt kończy się diagnozą - listą problemów z priorytetami i rekomendacjami do wdrożenia po Waszej stronie (patrz /uslugi/audyty-ux/). Modernizacja zaczyna się tam, gdzie audyt się kończy, i doprowadza zmianę do produkcji - projektuje nowe ekrany, wpina je za przełącznikiem i prowadzi migrację aż do usunięcia starych widoków. Jeśli nie wiecie jeszcze, czy problem leży w interfejsie, tańszą pierwszą rundą bywa audyt.

Czy to nie jest po prostu design system?

Nie, choć często idą razem. Design system to biblioteka komponentów jako osobny produkt z własnym utrzymaniem i governance (patrz /uslugi/design-system/). Modernizacja dotyczy konkretnych ekranów Waszej aplikacji i kończy się wtedy, gdy stare widoki znikają z kodu. Biblioteka powstaje tu w zakresie, jakiego wymaga migracja - jeśli po drodze okaże się, że opłaca się ją rozbudować do pełnego systemu, mówimy o tym wprost i wyceniamy osobno.

Co z użytkownikami przyzwyczajonymi do starego interfejsu?

Dlatego migracja idzie partiami, a nie jednym przełączeniem. Nowy widok włącza się wskazanej grupie - najpierw zespołowi wewnętrznemu, potem wybranym klientom albo rolom - a nie całemu ruchowi naraz. Przez czas przejściowy oba interfejsy działają obok siebie, więc powrót do starego widoku jest kwestią minut. Do wydań, które zmieniają utrwalone nawyki, przygotowujemy krótkie materiały wprowadzające dla Waszego zespołu wsparcia.

Kto pisze kod - Wy czy nasz zespół?

Pracujemy w obu modelach i decyzja należy do Was. Możemy wejść we frontend Waszego repozytorium i dowozić ekrany razem z Waszymi developerami, możemy też oddać projekty i komponenty do implementacji po Waszej stronie, zostając przy review i planie wydań. Najczęstszy układ jest mieszany - pierwszy ekran end-to-end robimy my, żeby ustawić wzorzec, a kolejne partie przechodzą stopniowo do Waszego zespołu.

Co się stanie, jeśli migracja utknie w połowie?

To najczęstszy sposób, w jaki modernizacje kończą się drożej niż rewrite, więc planujemy ją tak, żeby połowa drogi też miała wartość. Każde wydanie jest zamkniętą całością - naprawia konkretne ekrany i samo w sobie się broni, nawet gdyby kolejne przesunęło się o kwartał. Termin rozdzielenia starego i nowego interfejsu stoi w planie od pierwszego tygodnia, a po każdym wydaniu raportujemy, jaki udział ruchu obsługuje już nowy interfejs. Zatrzymanie migracji jest wtedy decyzją podjętą na liczbach, a nie stanem, który zauważacie po roku.

Powiązane usługi

Powiązane usługi

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ę