Prowadzenie odpowiednio stworzonej i czytelnej dokumentacji jest nieodłączną częścią pracy UX i UI Designerów. Sposób przekazania i jakość przekazywanej dokumentacji wpływa bezpośrednio na efekt pracy kolejnych wykonawców, czyli deweloperów, którzy mogli w szybki i sprawny sposób wytworzyć dany produkt, jego poszczególne funkcje i elementy właśnie dzięki podanym wytycznym. Przekazanie dopracowanej dokumentacji jest niezbędne do uzyskania oczekiwanego efektu naszej pracy.
Specyfikacja stworzona przez designerów – czym jest?
Specyfikacja to wytyczne, które przekazujemy kolejnym wykonawcom. Dzięki nim jesteśmy w stanie przedstawić projekt w odpowiedni i wygodny sposób, dzięki któremu praca kolejnych osób nad produktem czy funkcją zostanie skierowana w dobrą stronę. Równocześnie specyfikacja pomaga odpowiedzieć na wszelkie możliwe pytania i nieścisłości, mogące pojawić się na etapie programowania.
Dlaczego projektanci uciekają od dokumentacji?
Projektanci często są kreatywni, kochają tworzyć i projektować, lubią procesy twórcze, w których praca idzie do przodu, a oni mogą oglądać jej efekty. Dlatego większa niechęć do wykonywanych obowiązków jest widoczna w momencie, w którym trzeba stworzyć dokumentację i przedstawić dokładny projekt osobom, które będą kontynuowały pracę nad produktem.
Przekazywanie specyfikacji
To etap, który jest bardzo ważny, a zarazem bardzo trudny, ponieważ wymaga od projektantów dokładności i rzetelności, a źle zrealizowany może rodzić ogrom pytań i błędów. Sam zespół designerów rozumie nomenklaturę, rozumie to, skąd biorą się kolejne rozwiązania, a także to, jak istotne są poszczególne z nich, które są kluczowe, a które tylko wspierające. Zespół projektowy jest w stanie również ocenić, które rozwiązania są konieczne, a z których można zrezygnować, aby użytkownik mógł otrzymać optymalny interfejs.
W jaki więc sposób można właściwie przekazać niezbędne dane, czyli wykonać tzw. handover dla zespołu deweloperskiego?
Eksportowanie plików dla programistów
Designerzy pracujący na przeróżnych oprogramowaniach typu Adobe XD, Sketch, Figma doskonale zdają sobie sprawę, że istnieje możliwość wyeksportowania odpowiednich plików, które umożliwiają deweloperom sprawdzenie parametrów każdego elementu. Programy te dają możliwość pobrania stylów CSS, czyli ustawień dotyczących typografii czy wyglądu poszczególnych elementów, choć konsumpcja tych danych jest stosunkowo trudna i żmudna.
Systematyzacja wytycznych
Przekazanie danych prosto z programów dla designerów wymusza na deweloperach wiele dodatkowej pracy, bo muszą oni sprawdzać każdy element osobno. Przechodzą wówczas przez każdy layout i design tak, aby na końcu móc stworzyć np. pełną bibliotekę CSS, która będzie wykorzystywana do sterowania wszystkimi elementami. Dlatego warto traktować te narzędzia jako dodatek do dobrze stworzonej specyfikacji, który pomoże deweloperom wybiórczo sprawdzić poszczególne elementy. Dzięki odpowiedniemu przygotowaniu wytycznych i ich usystematyzowaniu designerzy są w stanie stworzyć taką specyfikację, która będzie łatwa i zrozumiała w odbiorze oraz pomoże uniknąć wielu pytań i niejasności.
Tabela jako sposób systematyzacji danych
Odpowiadając na pytanie, jak najlepiej i przede wszystkim najczytelniej przedstawić specyfikację, sugeruję stworzenie tabeli. Tabela zawiera w sobie mnóstwo informacji, które od razu są usystematyzowane. Dzięki temu rozwiązaniu jesteśmy w stanie podlinkować elementy w odpowiednich miejscach bez obaw, że pewne rozwiązania nałożą się na siebie, i możemy w jasny sposób przedstawić deweloperom złożoność projektu i jego rozwiązania.
Poniżej załączam kilka przykładowych specyfikacji, które zawierają w sobie podsumowanie. To, co jest zaletą tych rozwiązań, to to, że elementy są reużywalne, a dzięki nim łatwiej jest zrozumieć zamysł projektowy.
Tworzenie biblioteki design system
Kolejną rzeczą, na którą powinniśmy zwrócić uwagę, jest zebranie w jednym miejscu wszystkich stylów, nagłówków, kolorystyki oraz elementów jednostkowych naszego UI, czyli stworzyć tzw. design system. Nie musi być on wysoce zaawansowany, chodzi o przygotowanie zbiorczych wytycznych, które (dzięki zgrupowaniu) możemy wyeksportować jako link deweloperski, umożliwiający sprawdzenie wszystkich parametrów. Co ważne, te elementy również możemy opisać w tabeli, jednak wymaga to dodatkowego nakładu pracy ze strony projektanta, równocześnie jednak zmniejsza liczbę zapytań i kontaktów ze strony zespołu deweloperskiego, który może szybciej uzyskać parametry każdego elementu z osobna.
Tworzenie tabeli w dedykowanym oprogramowaniu
Wiemy już, dlaczego tabele są niezbędnym narzędziem wykorzystywanym w pracy UX i UI Designerów, więc przyszedł moment, aby podać przykładowe narzędzie i sposoby tworzenia tabeli. Najlepszym rozwiązaniem jest Confluence, w którym możemy w swobodny sposób zamieścić mnóstwo informacji, dzięki którym specyfikacje, jakie dostarczymy, będą bardzo czytelne. Confluence zapewnia nam również opcję version control, a tej opcji nie posiadają narzędzia takie, jak Adobe XD czy Figma – w przypadku tych programów aktualizacje wiążą się z tworzeniem nowego linku lub jego aktualizacją (w momencie, w którym zdecydujemy się na update linku, nie będziemy w stanie powrócić do poprzedniej wersji i nie będziemy mieć mozliwości sprawdzenia wcześniejszej specyfikacji). Confluence daje możliwość cofnięcia projektu do każdego momentu edycji, bez względu na to, kto był jej autorem. Robiąc tabelę w tym oprogramowaniu możemy również dodać wireframe, design oraz podlinkować prototypy.
Kolejnym bardzo dobrym rozwiązaniem, które znajduje się w Confluence, są automatyczne powiadomienia. Powiadomienia dotyczą wszystkich, którzy zaczęli już pracować nad danym taskiem i dzięki nim w łatwy sposób możemy poinformować deweloperów o tym, że dokonaliśmy zmian. Jednak pamiętajmy, że takie zmiany powinny być raczej drobnymi poprawkami albo uzupełnieniami – duże zmiany powinny być przedyskutowane z Product Ownerem, z którym omawiamy także, w którym momencie powinny zostać wprowadzone (czy dopiero po następnym sprincie, czy po releasie, czy będą traktowane jako improvement).
Co zrobić z przygotowaną dokumentacją?
Po przygotowaniu dokumentacji należy zorganizować spotkanie z zespołem deweloperskim. Podczas takiego spotkania powinniśmy opowiedzieć o wymaganiach, dokładnym sposobie funkcjonowania poszczególnych elementów, o ich zachowaniu oraz interakcjach. Oczywiście spotkanie to nie jest ostatecznym momentem przekazania dokumentacji, gdyż rola designera polega na tym, żeby w każdym momencie, w którym jest potrzebny, odpowiadał na pytania deweloperów, aby projekt podążał we właściwym kierunku.
Specyfikacja oraz właściwie przeprowadzone przekazanie przynoszą wymierne korzyści. Ponieważ skracają liczbę zapytań kierowanych do zespołu projektantów, przyspieszają czas realizacji projektu, a na dodatek stanowią dokumentację, dzięki której możemy wracać w latach do rozwoju produktu, aby móc zrozumieć jego architekturę czy też strukturę.
Jakie problemy generuje handover?
Musimy być świadomi, że problemy związane z przekazywaniem informacji będą się pojawiać, bo nigdy nie uda nam się w 100% omówić wszystkich informacji w taki sposób, aby nie było żadnych pytań. Równocześnie rynek oprogramowania, znając problemy związane z przekazywaniem specyfikacji, stara się dostarczać rozwiązania, które ułatwią pracę projektantom i deweloperom. Jednym z ciekawszych rozwiązań jest Invision Specks, dzięki któremu możemy wrzucić gotowe, interaktywne designy do przestrzeni, w której łączymy je z gotowym taskami w Jirze. Jira natomiast to przestrzeń, z którą kompatybilny jest wspomniany Confluence i w której deweloper może współpracować z projektantem i menadżerem.
Każdy ma inne potrzeby
Czy rozwiązania, które proponuję, są potrzebne wszystkim projektantom? Niekoniecznie – choć dla wielu będą to rozwiązania, które się sprawdzą, dla innych wciąż mogą być niewystarczające. Wszystko zależy od sposobów pracy, tak zwanych „ways of working”, oraz tego, jak skomplikowany jest produkt i jak często dokonujemy w nim gruntownych zmian. Musimy pamiętać, że rozwiązanie, które wybieramy, należy zawsze dobierać adekwatnie do indywidualnych potrzeb zespołu i projektu.