Jak przekazać projekt UX/UI i wprawić deweloperów w osłupienie

Poprzedni rok w Autentika zaznaczył się znaczącym wzrostem liczby projektów, w których odpowiadamy głównie za design UX/UI. Wymagało to od nas przyjęcia nowego podejścia do przekazywania efektów naszej pracy zewnętrznemu zespołowi.

„Czym to różni się od projektu, który samodzielnie realizujecie?" – możesz zapytać. Po pierwsze – chodzi o komunikację, a konkretnie o to, jak bardzo się komplikuje, gdy projekt realizują niezależne zespoły. Dwie firmy (trzy, wliczając klienta!), grono nieznajomych, różne procedury, brak wspólnych doświadczeń i komunikacja w czasie rzeczywistym. Nie ma miejsca na nieporozumienia przenoszące się między etapami projektu i nadzieje na natychmiastowe konsultacje w razie potrzeby. Wiedza musi być wyczerpująca, kompletna, tu i teraz. Co więcej, musi być usystematyzowana i przedstawiona w sposób czytelny dla każdego, kto zetknie się z naszą pracą po raz pierwszy.

Nie odbieramy telefonów!

Wiem, brzmi to dziwnie i należy to traktować z przymrużeniem oka, ale właśnie taki cel postawiliśmy sobie, tworząc plan ostatecznego „pakietu" do przekazania. Chcemy sprostać oczekiwaniom deweloperów i dostarczyć możliwie najbardziej wyczerpujący zestaw materiałów i informacji. Koniec z pytaniami „Na który ekran przechodzimy po rejestracji?" czy prośbami „Przyślijcie ikony do tego ekranu". Jako projektanci jesteśmy zawsze dostępni, ale nie chcemy dostawać pytań, które mogłyby sprawić, że wyglądamy na niekompetentnych.

Co ważniejsze, po naszej stronie miało to być boleśnie powtarzalne. Bez względu na projektanta i projekt, każdy ma jasny podręcznik, co i jak tworzyć.

Do rzeczy! Co nam dacie?

#1 Faza discovery

Najpierw sporządzamy kartę projektu. Gromadzi ona informacje o celach biznesowych, kluczowych miarach i wskaźnikach efektywności. Przedstawia interesariuszy. Projekt jest opisany w formie zakresu wysokiego poziomu, swoistego „widoku z lotu ptaka". Ryzyka i ograniczenia są wyraźnie wymienione. Na koniec zawiera harmonogram i budżet oraz wskazuje model rozliczeń.

Najważniejszą częścią jest karta produktu. Opracowujemy ją metodologią User-Centered Design. Wymieniamy cechy grupy docelowej wraz z jej bolączkami, motywacjami i obawami. Produkt jest definiowany przez pryzmat sposobów rozwiązywania problemów użytkowników, a także istniejących alternatyw dla produktu. Ta część jest podsumowana definicją przewag konkurencyjnych planowanego przedsięwzięcia i jego unikalnej propozycji wartości – korzyści, jaką użytkownik uzyskuje korzystając z produktu.

Rozdział dotyczący rynku to opis branży i jej lokalnego oraz międzynarodowego środowiska konkurencyjnego. Najczęściej obejmuje szczegółową analizę konkurencji, która sama w sobie może liczyć kilkaset stron materiałów.

Mówiąc o warstwie technologicznej projektu, gromadzimy informacje o środowisku, w którym ma on działać: urządzeniach, systemach, oprogramowaniu. Interesuje nas przede wszystkim możliwość wpływu na obszar UX/UI.

Na tym etapie analizujemy też wszelkie badania przeprowadzone przez klienta w przeszłości. Dane zebrane z Google Analytics, Hotjar lub badań jakościowych przekuwamy w konkretne wnioski, które pomagają nam podjąć właściwe decyzje projektowe. Tutaj często przedstawiamy rekomendacje dotyczące dalszych metod analizy potrzeb i zachowań użytkowników.

Ostatnim elementem karty produktu jest język komunikacji. Poznajemy markę, jej sygnet i identyfikację wizualną, styl języka, a także design system – choć ten ostatni jest wciąż dość rzadki, nawet wśród dużych korporacji. Analizujemy też decydentów pod kątem ich preferowanego stylu graficznego (tzw. draftest – nasza własna, autorska metoda).

#2 Faza ideacji

Najpierw dzielimy zakres funkcjonalny rozwiązania na obszary i moduły. Pozwala to stworzyć ramę, która ułatwia wskazanie konkretnego procesu (stąd nazwa „mapa procesów"). Od samego początku narzucamy dobrze zorganizowany model numeracji. Na przykład:

01. Aktualności 01.01 Administracja aktualnościami 01.01.01 Dodawanie artykułów

Przebieg każdego z procesów jest przedstawiony graficznie w postaci diagramu. Pokazuje on początek i każdy krok procesu aż do wyniku danego scenariusza w przejrzysty, czytelny sposób.

#3 Etap projektowania

Zestaw plików tworzonych na etapie projektowania spełnia standardy branżowe:

• Szczegółowe makiety dla każdego z widoków, uwzględniające stany (walidacja, interakcje). Oczywiście opracowane dla desktopa i urządzeń mobilnych w razie potrzeby,
• projekty graficzne przygotowane na podstawie makiet,
• pliki źródłowe .sketch dla makiet i projektu graficznego z dobrze zorganizowanymi artboardami i warstwami,
• prezentacja projektu w Invision wraz z historią komentarzy z procesu recenzji ekranów,
• UI Kit – zbiór projektów graficznych obejmujący różne stany i interakcje dla kompletnego interfejsu systemu,
• klikalny prototyp (jeśli wymagany) w Invision, animacje przedstawiające zachowanie elementów interaktywnych, fonty użyte w projekcie,
• assety, czyli elementy graficzne zawarte w projekcie (ikony, obrazy, ilustracje), najczęściej eksportowane do formatów .svg, .png, .jpg.

I tutaj wielu projektantów kończy swoje zaangażowanie, a my dorzucamy kolejną porcję solidnej wartości dla zespołu wdrożeniowego...

#4 Faza ideacji ciąg dalszy – wymagania

Tak, wracamy do punktu wyjścia – a w naszym przypadku do mapy procesów, dokumentu, dla którego wcześniej położyliśmy fundamenty. Wzbogaceni decyzjami podjętymi na etapie projektowania, musimy uzupełnić stworzone widoki o szczegółowe opisy wymagań. Projekty graficzne, choć wiele mówią, nie pozwalają zobaczyć, co dzieje się poza ekranem, po stronie backendu i zarządzania.

Uzupełniamy procesy o informacje dotyczące wymagań funkcjonalnych i niefunkcjonalnych (jakościowych, wydajnościowych). Wraz z utworzonymi diagramami tworzą one bazę wiedzy obejmującą każdą funkcję w systemie.

1.0 Aktualności

Jako uzupełnienie opisujemy też mikrointencje, często korzystając z linków do własnych animacji.

Każdy formularz jest rozkładany na szczegółowe elementy w formie gotowej do wdrożenia.

Nazwa procesu, etykieta, typ, wymaganie, placeholder, podpis, tooltip, komunikaty błędu i sukcesu, interakcje, zakres danych, specjalne formatowanie, limit znaków ze spacjami, komentarze. W ten sposób opisujemy każde pole formularza.

Opcjonalnie, w zależności od zakresu naszej odpowiedzialności, rekomendujemy podstawowe parametry dla różnych widoków w ramach procesu: struktura URL, Tag Title, Tag Desc, OG: title, OG: description, OG: image.

Krótko mówiąc

W naszym odczuciu dopiero ten zestaw informacji stanowi wystarczającą bazę wiedzy, umożliwiającą zewnętrznemu zespołowi sprawne działanie. Podsumowując:

Etap discovery Karta projektu Karta produktu Badania Analiza konkurencji Etap ideacji Mapa procesów Diagramy procesów Mapa widoków Wymagania procesów

Etap projektowania Makiety Klikalny prototyp Projekt graficzny UI Kit Animacje Fonty Assety Mamy nadzieję, że wielu Project Managerów i deweloperów będzie klnąć z nutą satysfakcji na widok tego i myśleć sobie „ci z Autentika znają się na… robocie". A u ciebie? W jakiej formie dostałeś ostatnio materiały do projektu, przy którym pracowałeś?

W Autentika nazywamy siebie zespołem UX UI Design & Custom Development. Od prawie 17 lat tworzymy aplikacje webowe i strony internetowe, aplikacje mobilne i systemy e-commerce.

Jeśli planujesz realizację projektu software'owego dla swojej firmy w najbliższej przyszłości, zapoznaj się z naszymi kompetencjami i skontaktuj się z nami.