Autor: Marcin Bartusik

Miałem możliwość realizować bardzo ciekawy projekt nietypowego komponentu w standardowym procesie zakupowym
wraz z zespołem z global4net.

Komponent, o którym mowa zaznaczyłem zakreśleniem.

Krok I – Koszyk

• 

Jeśli się przyjrzeć z bliska, posiada bardzo dużo informacji wymaganych przez dział prawny, ale dostosowany jest tak aby zminimalizować poczucie przytłoczenia, poprzez wydzielenie przestrzeni zgodnie z zasadami Gestalten.

Proces zakupowy dla produktów jednorazowych

Proces zakupowy dla turystyki

Komplikacja pojawia się wtedy, gdy chcemy każdy proces zakupowy obsłużyć w podobnej ścieżce, a posiadamy różne segmenty produktów, w tym przypadku turystykę.

Proces zakupowy dla abonamentów

Pewnie w kolejnych iteracjach będzie można zrobić to lepiej, ale jak na pierwszy cykl, uchwycone zostały wszystkie wymagania biznesowe, prawne i uspójnienie estetyczne tak trudne dla wielu segmentów produktowych.

Ścieżka powrotu wykorzystywana w szczególności w e-commerce stała się dla mnie inspiracją do stworzenia menu kontekstowego, wraz z dynamiczną rolą powrotu. Temat z 2017 ale cały czas aktualny.

Typowa ścieżka powrotu (breadcrumbs):

Głównym założeniem menu była możliwość wchodzenia w głąb oraz prosty sposób powrotu w zależności od zagłębienia.

Tak powstało menu z podziałem na 3 konteksty:

Element klikalny to ikona oraz napis. Ikona resetuje wartości wybrane lub prowadzi do danego kontekstu. Napis otwiera menu kategorii.

Samo działanie możemy zobaczyć na filmie poniżej we wdrożonym projekcie EduFox dla systemu zarządzania przedszkolami.

Pierwszy sposób użycia odnosi się do przejścia po każdej kategorii, aż wybierzemy docelowy oraz szybki powrót poprzez wybranie ikony.

Drugi sposób przedstawia ominięcie jednej z kategorii i przejście do konkretnego wybranego.

W zależności od wybranego kontekstu, dodawanie nowego elementu powoduje automatyczne wrzucenie go do danej kategorii. Przyśpieszamy dzięki temu proces wyboru, pozostawiamy dobre praktyki z możliwością pozostawienia ścieżki powrotu oraz wprowadzamy kontekstową budowę elementów.

Komponent ten został sprawdzony na bardzo wymagającej grupie docelowej, w której sprawdził się doskonale.

Budowa i rozwój systemów „informatycznych” z roku na rok wchodzi w bardziej zaawansowany etap. Kiedyś pracowaliśmy na jednorodnych systemach (Monolitach) gdzie elementy wizualne przetrzymywane były w arkuszach styli CSS i po roku utrzymania takiego systemu mieliśmy już niezły bajzel.

Potem zakochaliśmy się w Mikroserwisach i komunikacji poprzez API i dzięki temu przeszliśmy na budowę elementów wizualnych z podziałem na Elementy i Komponenty wykorzystując np. Idee Atomic Design, co doprowadziło do powstania Design Systemów, Storybooków itp.

Będąc tu i teraz szukam rozwiązania dla własnych zespołów, korzystając z obecnych rozwiązań tak aby rola projektantów nie stanowiła jedynie dostawcy makiet / grafik w pośpiechu, a posiadała najważniejszą część, w której pracuje już IT, czyli iteracje. Możliwość powtarzania, wyciągania wniosków i ulepszania daje jakościowe rezultaty.

Tym sposobem powstał pierwszy własny Design WorkFlow:

Był rok 2019, flow nie było doskonałe, nie bazowało na metodyce Atomic Design, ale już posiadało wybranie reguł ogólnych do osobnego pliku CSS, który mógł być szybko nadpisywany oraz do CSS dla poszczególnych komponentów z wykorzystaniem nazewnictwa w konwencji BEM.

Wyciągając wnioski z błędów popełnionych w takim rozwiązaniu i w związku ze zmianami technologicznymi budując Flow w drugiej wersji, wykorzystujemy pracę projektową w oparciu o Elementy i Komponenty w Design Systemie po stronie Projektowej i Storybooku po stronie Programistycznej.

WorkFlow wygląda mniej więcej tak:

Sam Design System po stronie projektowej, czyli tam, gdzie sami możemy wprowadzić ulepszenia jest najistotniejszy, ponieważ to my projektanci jeśli nie opracujemy sposobu własnej pracy nie możemy oczekiwać że IT nam ją przedstawi w taki sposób jak nam odpowiada, bo po prostu jej nie zna. IT zawsze będzie oczekiwać materiałów do wdrożenia w terminie, to jest zrozumiałe i to się nie zmieni.

Projektanci muszą wymyślić swoje flow pracy tak, aby było jakościowe i dostarczało na czas rozwiązania. Dlatego na flow pracy projektowej składa się flow pracy nad Design Systemem, który jest ciągłym procesem doskonalenia.

Design System Flow może wyglądać tak:

Najważniejszym elementem rozwoju DS jest przestrzeń dla projektantów gdzie mogą swobodnie nanosić zmiany, komentarze i uspójnienia na przyszłość pracując dalej w wersji obecnego DS. Dzięki przestrzeni, wymogi czasu i pchania projektów do przodu, utrzymujemy pamięć na spójności i jakości, którą możemy wdrożyć w kolejnej iteracji DS.

Dodatkowo bardzo ważnym czynnikiem jest dopuszczenie do pracy projektowej interesariuszy projektu, nieraz osób bezpośrednio z biznesu lub pracowników różnego szczebla firmy. Stąd wciąż zmieniany proces projektowy oparty jest o wciąż rosnące w popularności narzędzie Figma i może wyglądać tak: