18 maja, 2022

Pracując przy wielu projektach, w rozbudowanych zespołach, wcześniej czy później spotkamy się z określeniem style guide. I tu pojawia się pytanie – czy jeśli do tej pory działaliśmy bez niego, to jest w ogóle potrzebny? Spróbuj sobie odpowiedzieć na pytania, czy:

  • projektujesz serwisy na różne urządzenia (w zasadzie musisz, bo zróżnicowanie odbiorców jest ogromne, prawda),
  • chcesz aby Twoje pliki były przygotowane na przyszłe zmiany i rozwój aplikacji,
  • chcesz zaoszczędzić czas (i pieniądze) w fazie projektowania,
  • pracujesz w rozbudowanym zespole projektantów, deweloperów, testerów,

Jeśli, chociaż na jedno z poniższych pytań odpowiedź brzmi TAK, to zdecydowanie style guide jest Ci potrzebny.

Czym jest style guide?

Style guide to dokument opisujący elementy interfejsu danej aplikacji, serwisu. Pomaga zachować wizualną spójność komunikacji. Warto wspomnieć, że w świecie druku komunikowanie identyfikacji wizualnej jest już znane od dawna. W produktach cyfrowych jest to nieco świeższy temat, ale na pewno wart bliższego poznania. Przede wszystkim style guide jest dokumentem “otwartym”, ciągle ewoluuje i zmienia się wraz z rozwojem serwisu.

Nigdy nie powinien to być dokument stworzony “dla sztuki”, bo “fajnie mieć”, “bo podobno inni mają”. Bez zrozumienia jego specyfiki, a przede wszystkim – bez zachowania ciągłości i jego aktualizacji – w zasadzie można go sobie odpuścić (czego zdecydowanie NIE POLECAM 😉 )

Co powinien zawierać style guide?

Jak wspomniałam, style guide to żywy dokument zawierający elementy, z których złożony jest serwis, dlatego powinien zawierać przede wszystkim:

  • logo – chodzi o jego wielkość, układ, ewentualne wariacje dla produktu cyfrowego (tzn. że nie powinieneś umieszczać w dokumencie wizualizacji logo na papierze firmowym 😉 )
  • grid (najważniejsze break pointy)
  • typografia
  • kolorystyka (ale zawsze w kontekście – jakie kolory dla typografii, przycisków, tła etc)
  • przyciski akcji – zarówno primary jak i secondary (warto wskazać jak mają wyglądać też linki w tekście czy wszystkie inne “klikalne” elementy
  • elementy interfejsu jak menu, formularze, select, input, radio buttony, checkboxy, tabele i wszystkie inne powtarzalne elementy, które zawiera Twoja aplikacja
  • ikony

Kiedy powinien powstać?

Co do zasady – im wcześniej tym lepiej. Ale nie ma tu twardych ram czasowych. Z doświadczenia wiem, że (niestety nierzadko) taki dokument pojawiał się w momencie “gaszenia pożaru”. W momencie, gdy brak spójności i wielkość projektu były już tak duże, że dalsze tworzenie interfejsu było uciążliwe i obarczone kolejnymi błędami. Z drugiej strony jeśli jesteśmy na początku projektu, w fazie wireframów, gdzie nasza aplikacja nie ma rozbudowanej identyfikacji wizualnej (logo, brand book), nie musimy na siłę tworzyć jednocześnie style guida. Warto aby powstał (czasami wystarczy w podstawowej wersji) przed etapem projektu UI (User Interface) i był na bieżąco aktualizowany, tak aby na etapie dewelopmentu, elementy, które zawiera projekt miały odzwierciedlenie w style guide.

Style guide w różnych perspektywach

Style guide to nie lek na całe zło, ale pewne aspekty naszej codzienności poprawia zdecydowanie. Praca w rozbudowanym zespole, gdzie każdy odpowiada za swoją część, problemy komunikacyjne (przy pracy zdalnej dodatkowo – konieczność nauczenia się pracy asynchronicznej), rozwój produktu czy zmiany kadrowe powodują, że produkt nad którym pracujemy, czasami – kolokwialnie mówiąc – zaczyna się “rozjeżdżać”. A to zawsze skutkuje frustracją, niezadowoleniem, w konsekwencji generując coraz większe koszty wytwarzanego produktu.

Jeśli jestem designerem…

Chętnie sięgam po style guide zawsze kiedy zaczynam pracę nad projektem. W zasadzie – odpalam dokument zanim jeszcze nazwę plik w programie 🙂 

Dzięki temu mam pewność, że nowa funkcja nad którą pracuję będzie spójna z resztą projektu. Jeśli korzystam z elementów, które już są w aplikacji, łatwo i szybko je kopiuje, co pozwala zaoszczędzić czas. Jeśli tworzę nowy element (w przypadku kiedy nie można zastosować obecnie dostępnych) – mam pewność, że zasada Don’t Repeat Yourself to nie frazes. 

Będąc nowym członkiem działu graficznego, mam łatwy i szybki dostęp do wszystkich elementów aplikacji, bez konieczności przeglądania wszystkich stworzonych plików.

Jeśli jestem deweloperem…

Style guide stanowi punkt wyjścia do napisania ustandaryzowanego CSSa. Jeśli widzę, że dany moduł nie istnieje w style guide, mogę zawsze upewnić się u designera czy na pewno musi się różnić od innych, istniejących już elementów. 

Jeśli jestem testerem…

Moduły opracowane na podstawie style guide zdecydowanie pozytywnie wpływają na testowanie. Jeśli dany moduł został przetestowany poprzednio i jest niezależnym modułem od innych, to jest spore prawdopodobieństwo, że nic się nie popsuje w międzyczasie. A jak już nawet się popsuje to szybki jeden fix rozwiąże problem na każdej stronie, gdzie dany moduł został użyty.

Jeśli jestem managerem, właścicielem, biznesem…

Aplikacje i serwisy, czy ogólnie – produkty cyfrowe, w sporej liczbie przypadków są komercyjne. Mają na siebie zarabiać. Style guide stosunkowo niewielkim nakładem pracy, potrafi zaoszczędzić sporo czasu (czyli: pieniędzy). Zarówno po stronie wytwarzania projektu, jak i późniejszego dewelopmentu. 

Wyobraźmy sobie taką sytuację…

  • biznes określa potrzebę wprowadzenia nowej funkcjonalności
  • nie mamy stule guide, bo nie było przestrzeni na jego stworzenie
  • zespół projektowy przygotowuje projekt zgodnie z wytycznymi biznesu
  • projekt jest wdrażany, ale okazuje się, że wdrożone moduły były już napisane w innej części aplikacji – dawno temu, plik obrósł pajęczynami i zespół projektowy po prostu nie pamiętał, że coś podobnego już stworzył (albo na tyle podobnego, że w danej sytuacji można byłoby skorzystać już z gotowego modułu bez wymyślania koła na nowo)
  • testerzy mają dwa moduły do testowania
  • przy kolejnej wdrażanej funkcjonalności pojawiają się pytania – który moduł wykorzystać. No i ta pokusa: “nie mamy gdzie sprawdzić czy taki moduł już istnieje, to może stworzymy coś od zera?” 😉
  • finalnie: frustracja u wszystkich zaangażowanych w projekt – “dlaczego tyle to kosztuje, skoro już coś podobnego mamy?”, “dlaczego projektujecie coś co już było zrobione?”, “nie jesteśmy w stanie pamiętać o każdym drobnym elemencie w serwisie” etc.

Pomnóżmy tą sytuację kilkukrotnie i mamy całkiem sporo dodatkowej pracy i bałaganu… który koniec końcem, dla dobra serwisu, trzeba będzie posprzątać. Zaczniemy od zgromadzenia narzędzi (style guide), zainwestujemy czas w przejrzenie aplikacji pod kątem elementów i zgodności z wytworzonym dokumentem, będziemy stopniowo wprowadzać zmiany, aby zachować spójność. A to będzie trwało. I kosztowało.

A mogło być tak pięknie….

  • biznes określa potrzebę wprowadzenia nowej funkcjonalności
  • mamy stule guide
  • zespół projektowy przygotowuje projekt zgodnie z wytycznymi biznesu w oparciu o wypracowane już elementy style guida
  • projekt jest wdrażany. Moduł istnieje już w aplikacji, więc jego implementacja w nowym miejscu przebiega sprawnie
  • testy przechodzą śpiewająco
  • przy kolejnej wdrażanej funkcjonalności – “super! Mamy to prawie gotowe!”
  • finalnie: radość i wieczna szczęśliwość u wszystkich zaangażowanych w projekt 🙂

Jeśli jestem użytkownikiem…

“Dlaczego formularz w tym miejscu wygląda i działa inaczej niż w tamtym?”

“Nie podoba mi się. Może to jakieś oszustwo? Lepiej to odinstaluje.”

Chociaż przytoczone przykłady są pewnym uproszczeniem, to doświadczenie z wieloma projektami pokazuje, że wcale nie takim dużym. Chodź jak wspomniałam, style guida nie jest odpowiedzią na wszystko i nie w każdym projekcie będzie miał takie samo znaczenie (przy mniejszych zespołach i mniejszym projekcie siłą rzeczy łatwiej jest “zapanować” nad wizualnym aspektem całości), to zdecydowanie warto zadbać o taki dokument. 

Można żyć bez stylu?

Można, ale co to za życie 😀 Przyznam, że trudno mi wyobrazić sobie rozpoczęcie nowego projektu lub wejście w istniejący bez style guide. Zdecydowanie zachęcam do podjęcia próby jego stworzenia (jeśli jeszcze nie masz go w projekcie), czy wskazania na zalety jego posiadania – jeśli dopiero zaczynasz. A jeśli już jest – to przede wszystkim KORZYSTANIA Z NIEGO :), co powinno wiązać się z koniecznością jego aktualizacji. 

Style guide nie powinien być odbierany jako hamulec kreatywności czy “bat na designera”, ale jako narzędzie, które pomaga i usprawnia nam pracę. Świat produktów cyfrowych jest wymagający i rozbudowany… dlatego może warto spojrzeć w lustro i zadać sobie pytanie: “Czy NA PEWNO potrzebuję kilkudziesięciu odcieni szarości w tej aplikacji?” 😉

Magdalena Ciołkowska

Inne artykuły tęgo autora

Magdalena Ciołkowska
18 maja, 2022
Magdalena Ciołkowska
9 lipca, 2021
Magdalena Ciołkowska
19 października, 2020