Projektowanie ekranów na platformie Ferryt, szczególnie dla sektora bankowego, choć z pozoru proste, jest zadaniem wieloetapowym, stanowiącym często wyzwanie zarówno pod względem technicznym, jak i organizacyjnym.
Proces ten obejmuje analizę makiet, optymalizację layoutów, dostosowanie do wytycznych klienta oraz nieustanne balansowanie między wymaganiami UX, aspektami technologicznymi i codziennymi realiami projektowym.
Ze względu na wymagania oraz rygorystyczne standardy dotyczące bezpieczeństwa i dostępności (w tym WCAG), każdy z tych etapów musi być wykonany ze szczególną dbałością o detale.
Analiza makiet i dobre praktyki
Odbiór makiet – narzędzia
Podstawowym narzędziem wykorzystywanym w pracy nad makietami jest Figma, stosowana w procesie projektowania doświadczeń użytkownika (UX) oraz interfejsów użytkownika (UI). Jest to edytor graficzny i narzędzie do prototypowania, które umożliwia tworzenie zaawansowanych makiet, w tym również makiet interaktywnych, pozwalających na odwzorowanie sposobu działania projektowanego rozwiązania. Praca na komponentach i bibliotekach wspiera zachowanie spójności wizualnej oraz standaryzację projektu, a także umożliwia precyzyjny odczyt parametrów takich jak rozmiary czcionek, kolory czy wartości marginesów i paddingów.
Analiza spójności i zgodności z identyfikacją wizualną klienta
W pierwszej kolejności stworzony zostaje Design System – ustandaryzowany zbiór komponentów, zasad oraz wytycznych projektowych, który pomaga zachować spójność w obrębie tworzonego projektu. Na tym etapie należy weryfikować kolorystkę i elementy graficzne, a także kontrolki, by pozostały zgodne z identyfikacją wizualną klienta.
Po zatwierdzeniu Design Systemu rozpoczynają się prace nad makietami wniosku. Podczas ich tworzenia należy skupić się na układzie pól, typach kontrolek, nagłówków i odstępach, tak by były spójne na każdym kroku formularza.
Warto już na tym etapie zadawać pytania dotyczące niejasnych fragmentów makiet. Pozwala to oszacować ryzyko i odpowiednio zaplanować sprint.
WCAG a projektowanie ekranów
WCAG (Web Content Accessibility Guidelines) to międzynarodowy standard opisujący wymagania dotyczące dostępności treści cyfrowych dla osób z różnymi niepełnosprawnościami, opracowany przez organizację W3C. Wytyczne WCAG obejmują m.in. czytelność tekstów, odpowiedni kontrast kolorów, nawigację klawiaturą oraz zapewnienie alternatyw dla elementów graficznych.
Zgodność z wytycznymi WCAG powinna być brana pod uwagę już na etapie tworzenia Design Systemu, a nie dopiero podczas wdrożenia lub testowania gotowego rozwiązania. Im wcześniej projektanci, analitycy i developerzy zaczną myśleć o dostępności, tym mniej poprawek i nieporozumień pojawi się w trakcie prac, a całość procesu przebiegnie sprawniej.
Co można zrobić w praktyce na etapie projektowania?
- Kolory i kontrast – sprawdzanie czy kontrast między tekstem a tłem spełnia minimalne wartości określone w WCAG (np. 4.5:1 dla zwykłego tekstu).
- Struktura treści– projektowanie nagłówków, list i opisów tak, by były logiczne i łatwe do zrozumienia, także dla osób korzystających z czytników ekranu.
- Nawigacja klawiaturą – upewnienie się, że wszystkie interaktywne elementy (przyciski, linki, formularze) będą dostępne również z poziomu samej klawiatury.
- Czytelność tekstów – stosowanie prostego języka, odpowiedniej wielkości czcionek i odstępów, aby treść była komfortowa w odbiorze.
- Spójne wzorce projektowe – korzystanie z powtarzalnych elementów interfejsu, co ułatwia poruszanie się po systemie osobom z zaburzeniami poznawczymi.
Przygotowanie struktury ekranów w Ferryt
- Wykorzystanie istniejących układów
Przed implementacją należy sprawdzić, czy w systemie istnieje już odpowiedni układ ekranów, którego można użyć lub zmodyfikować. W przypadku braku – należy stworzyć własny, pamiętając o:
- Odpowiednim podziale przestrzeni (np. procentowe wypełnienie panelu bocznego względem całego ekranu).
- Właściwych ustawieniach stopki oraz progress panelu ( wykorzystując opcję rozciągnięcia tych elementów na cały ekran, a także dostosowania wyświetlanej zawartości do szerokości ekranu).
- Identyfikacja i klasyfikacja ekranów
Na początku warto zidentyfikować i przeanalizować wszystkie ekrany, które są wykorzystywane w procesie. Jeżeli występuje duża liczba podobnych ekranów (np. liczne nagłówki), należy rozważyć ich optymalizację i redukcję do jednego – przy założeniu, że nie wpłynie to negatywnie na użyteczność.
Trzeba pamiętać jednak, że taka redukcja wiąże się ze zmianami w workflow, co może nieznacznie wydłużyć pracę.
Po przeprowadzeniu identyfikacji ekranów, każdemu z nich przypisuje się odpowiednią sekcję formularza, zgodnie z jego przeznaczeniem i funkcją w procesie. Przykładowo, ekrany pełniące rolę nagłówków oznacza się jako „progress panel”, stopki przypisuje się do sekcji „panel akcji” lub „stopka”, natomiast główną część formularza zwykle oznacza się jako „formularz” (jest to ustawienie domyślne). W przypadku występowania bocznego panelu, stosuje się sekcję „prawa strona” lub „lewa strona” w zależności od docelowego umiejscowienia panelu na ekranie.
Poniżej przedstawiono przykładowy wniosek wraz z zastosowaniem powyższych typów sekcji ekranów.
Stosowanie typów sekcji ekranów umożliwia zachowanie większej czytelności formularza oraz znacząco ułatwia analizę wprowadzonych zmian podczas pracy w edytorze layoutów.
Dodatkowo, istnieje możliwość dostosowania kolejności wyświetlania poszczególnych ekranów w formularzu. W tym celu należy zmodyfikować wartości w kolumnie „kolejność”. Można to zrobić poprzez kliknięcie na ikonę trzech pionowych kropek umieszczoną po prawej stronie danego wiersza i wybranie opcji „Edycja”. Wprowadzona liczba określa pozycję ekranu na formularzu: im wyższy numer, tym niżej dany ekran zostanie wyświetlony.
Projektowanie
Budowa szablonów – oszczędność czasu i większa spójność
W sytuacji, gdy planowane jest tworzenie kilku podobnych procesów, warto rozważyć przygotowanie tzw. szablonów. Chodzi tu o stworzenie kilku ekranów technicznych „wzorcowych” – dopracowanych w najdrobniejszych szczegółach, przetestowanych i zaakceptowanych przez zespół UX oraz biznes. Po zatwierdzeniu szablonów można je importować do pozostałych procesów, zmieniając jedynie grafiki, treści czy pola. Rozwiązanie to pozwala oszczędzić czas, a jednocześnie zapewnia wizualną i techniczną spójność ekranów we wszystkich procesach.
Organizacja i dostępność szablonów
Najlepszym miejscem do przechowywania szablonowych ekranów jest proces techniczny w Ferryt, który pozostaje dostępny dla wszystkich zespołów. Pozwala to każdemu deweloperowi szybko sięgnąć po sprawdzony „punkt odniesienia”. Dzięki temu projektowanie staje się prostsze i mniej czasochłonne.
Takie podejście buduje solidny fundament pracy zespołowej: eliminuje powielanie błędów, ułatwia standaryzację i zapewnia, że wszystkie nowe rozwiązania powstają w oparciu o te same, zatwierdzone wzorce. W efekcie proces projektowy staje się przewidywalny, uporządkowany i skuteczniejszy.
Poniżej zaprezentowano przykładowe, szablonowe ekrany – każdy z nich daje możliwość podpięcia wybranych pól procesu po lewej stronie edytora.
Obraz 1. Edytor ekranu nagłówka z zaznaczonymi miejscami do podpięcia pól procesu
Rysunek 2. Edytor ekranu stopki z zaznaczonymi miejscami do podpięcia pól procesu
Rysunek 3. Edytor ekranu formularza z zaznaczonymi miejscami do podpięcia pól procesu
Komponenty i customizacja
Dostępność i wybór komponentów
Ferryt 2.0 oferuje bogatą bibliotekę komponentów interfejsu użytkownika, które stanowią podstawę do tworzenia spójnych i użytecznych ekranów. W praktyce oznacza to, że projektowanie makiet powinno odbywać się w oparciu o dostępne już komponenty – tak, aby uniknąć sytuacji, w której przygotowany projekt nie może zostać zrealizowany technicznie.
Przykłady niektórych dostępnych kontrolek w Ferryt 2.0:
- Pola formularzy – pola tekstowe, etykiety
- Listy rozwijane (dropdowny) – z pojedynczym lub wielokrotnym wyborem.
- Checkboxy i radio buttony – do wyboru jednej lub wielu opcji.
- Suwaki
- Komunikaty.
- Karuzele
Dopuszczalne jest również korzystanie z komponentów, które planowane są do wdrożenia w przyszłości. W takim przypadku, do czasu ich faktycznej dostępności, makiety powinny być budowane w oparciu o aktualnie dostępne elementy, stanowiące ich najbliższy odpowiednik. Dzięki temu zespół zyskuje spójność wizualną i funkcjonalną, a jednocześnie unika opóźnień wynikających z oczekiwania na nowe rozwiązania.
W sytuacjach, gdy w makiecie pojawi się potrzeba zastosowania elementu, którego Ferryt jeszcze nie zawiera, należy w pierwszej kolejności:
- sprawdzić możliwość wykorzystania istniejącego komponentu (czasem wystarczy niewielka modyfikacja),
- skonsultować z biznesem zasadność takiego rozwiązania,
- skonsultować z programistami ograniczenia techniczne,
- w ostateczności zgłosić zapotrzebowanie na nowy komponent – co wiąże się z dodatkowym czasem i zaangażowaniem zespołów.
W niektórych przypadkach pojawia się potrzeba modyfikacji lub rozszerzenia funkcjonalności komponentu przy użyciu kodu JS. Kod zamieszczany jest wtedy najczęściej w zakładce Konfiguracje procesów –> Procesy -> Ustawienia rozszerzone.
Standardy wyświetlania na różnych urządzeniach
Wymagania dotyczące responsywności różnią się w zależności od instytucji finansowej i specyfiki projektu. Zazwyczaj definiuje się trzy główne szerokości ekranów, które należy wziąć pod uwagę podczas projektowania makiet. Przykładowe wartości mogą wyglądać następująco:
- Desktop: 1360 px
- Tablet: 1067 px
- Mobile: 768 px
Są to przykładowe wymiary, często stosowane w praktyce, jednak każda organizacja może określić własne wartości. Ważne jest, aby projektowanie było dostosowane do wymagań danego klienta i obejmowało najważniejsze punkty łamania (breakpointy), umożliwiając prawidłowe wyświetlanie na różnych urządzeniach.
Aby móc zastosować je na formularzu należy najpierw w Ferryt Admin w zakładce Administracja -> Konfiguracja parametrów systemu wyszukać parametr Resolution dla tabletu i urządzenia mobilnego i wprowadzić ustalone wartości.
Następnie w Architekcie w zakładce Konfiguracje procesów – > Procesy -> Ustawienia rozszerzone należy wprowadzić wartości punktów łamania w odpowiednim miejscu.
Ferryt 2.0 posiada domyślne mechanizmy wspierające responsywność, jednak w praktyce zaleca się każdorazową weryfikację, czy layout wyświetla się poprawnie na docelowych urządzeniach. Edytor daje możliwość blokowania poszczególnych widoków poprzez kliknięcie ikony kłódki w prawym górnym rogu, co pozwala na usunięcie ryzyka niepożądanych przesunięć czy deformacji ekranów.
Na poniższej grafice ukazany jest odblokowany widok mobilny.
Przy projektowaniu dla widoku mobilnego warto zwrócić uwagę na zachowanie czytelności – pola, przyciski i ikony muszą być odpowiednio większe i wygodne do obsługi dotykiem, w przeciwieństwie do widoku desktopowego, gdzie użytkownicy często korzystają z myszy i klawiatury co pozwala na zastosowanie mniejszych kontrolek. Na małych ekranach zaleca się również korzystanie z układu jednokolumnowego i stosowanie akordeonów lub rozwijanych sekcji, aby nie przeciążać widoku.
Wyzwania UX/UI i współpraca z biznesem
Jednym z największych wyzwań jest liczba oraz częstotliwość zmian zgłaszanych przez UX i biznes. Każda zmiana w makiecie wymaga aktualizacji implementacji na formularzu, co znacząco wydłuża czas wdrożenia.
Dobre praktyki:
- Regularne spotkania statusowe z UX/biznesem.
- Szybkie prototypowanie zmian na dedykowanych środowiskach testowych.
- Dokumentowanie wszystkich uzgodnionych zmian oraz decyzji.
Balansowanie pomiędzy kreatywną wizją projektanta, oczekiwaniami klienta, a możliwościami technicznymi Ferryt wymaga stałej komunikacji oraz szybkiego reagowania na pojawiające się zmiany. Warto jasno informować o ograniczeniach platformy oraz zgłaszać propozycje alternatywnych rozwiązań, gdy dany efekt nie jest możliwy do osiągnięcia “out of the box”.
Przy komunikacji z biznesem warto zadbać o:
- Wspólne spotkania review, podczas których uzgadniane są detale ekranów i kluczowe funkcje.
- Unikanie rozpoczynania prac na niezatwierdzonych makietach, co minimalizuje ryzyko podwójnej pracy i zbędnych poprawek.
Podsumowanie
Efektywne projektowanie ekranów w Ferryt to proces wymagający połączenia umiejętności analizy, komunikacji i technicznej sprawności. Kluczowe znaczenie ma dokładna analiza makiet, optymalizacja layoutów i wykorzystywanie szablonów, a także elastyczne podejście do zarządzania zmianą. Regularny kontakt z UX, biznesem oraz szybkie reagowanie na zgłaszane uwagi pozwalają znacząco przyspieszyć wdrożenie oraz minimalizować liczbę powtarzanych czynności.
Warto dzielić się doświadczeniem oraz spisywać napotkane problemy – zarówno dla własnej korzyści, jak i dla przyszłych członków zespołu. Odpowiednio przygotowane procesy i dobrze zorganizowana praca pozwalają nie tylko spełnić wysokie wymagania banku, ale także zrealizować wdrożenie w sposób wydajny i profesjonalny.