Dobry projektant aż się pali do roboty. Projektowanie produktów jednak jest niezwykłym wyzwaniem w erze różnych urządzeń. Nie chcę powtarzać wyświechtanych frazesów o zegarkach, telefonach, desktopach, bo zapewne już o tym wiesz. Jak więc poprawnie projektować interfejsy na różne urządzenia i platformy oraz jak przygotowywać pliki mając na uwadze przyszłe zmiany? Dowiesz się z tego artykułu także jak oszczędzić czas i pieniądze w fazie projektowania produktów, ich wytwarzania i testowania.
Style guide – z czym to się je?
Mówiąc w skrócie Style guide to żywy dokument opisujący jak powinny wyglądać poszczególne elementy interfejsu, aby zachować spójność wizualnej komunikacji. Przez „żywy dokument” rozumiem tutaj fakt, że style guide ciągle ewoluuje i zmienia się w trakcie życia produktu. Warto też odnotować, że w świecie druku definiowanie komunikacji wizualnej jest znane od kilkudziesięciu lat. Warto więc opracowywać Style guide w nawiązaniu do księgi identyfikacji wizualnej (która służy kreowaniu wizerunku marki firmy na rynku, zawiera m.in. logo, typografię, kolorystykę).
Co powinno zawierać Style guide
- logo (ale nie interesuje nas, jak wygląda logo na długopisie)
- typografia (może być różna na stronie www, inna w aplikacji na Androidzie, inna na iOS)
- grid (najważniejsze break pointy powinny być pokazane)
- paleta kolorów (ale nie same kolorki podane bez kontekstu!)
- przyciski
- najczęściej używane elementy interfejsu (menu, formularze, stopka itp.)
Spójność z perspektywy firmy
Projektowałem dla bardzo różnych firm. Mam doświadczenie w pracy dla małych startupów, jak i ostatnio dla międzynarodowej firmy AirHelp, której udało się odnieść sukces i szybko urosnąć.
Praca w międzynarodowej firmie bywa nie lada wyzwaniem. Zespoły pracują nad różnymi produktami. Problemy komunikacyjne, niepełny przepływ informacji między poszczególnymi działami w firmie, a nawet wewnątrz danego działu (np. między Product Managerem a Designerem), a także rozproszenie odpowiedzialności skutkuje niewłaściwymi decyzjami w kwestiach rozwoju produktów i ich interfejsów, frustracją pracowników i niezadowoleniem kadry zarządzającej. Na tym oczywiście ostatecznie tracą klienci oraz sam przychód i wizerunek firmy.
Gdzie bym jednak nie pracował, zawsze spotykałem się z tym samym problemem – brakiem spójności w szeroko rozumianym designie.
Dla frontendowca Style guide stanowi punkt wyjścia do napisania ustandaryzowanego CSSa (Cascaded Style Sheet). Plik CSS powinien być możliwie mały, aby szybko ładował się na stronie.
Warto, aby Designerzy i Developerzy dogadywali się ze sobą i uzgadniali np. czy dany moduł na pewno musi się różnić od innych, istniejących już modułów.
To samo dotyczy też działu marketingu. Materiały reklamowe powinny być spójne. Nie powinno się w danej firmie czy organizacji patrzeć na działy czy departamenty jako osobne wyspy. Stwierdzenia typu: “A to sobie wymyślił marketing, oni mają swojego grafika” nie powinno mieć miejsca. Wszyscy pracują dla jednej firmy, grają do jednej bramki.
Designerzy po fazie tworzenia pomysłów na interfejs, podczas której generują wiele propozycji, powinni wziąć sobie do serca zasadę, jaką kierują się Developerzy, czyli DRY (Don’t Repeat Yourself). Chodzi więc o to, aby nie wymyślać koła ciągle na nowo.
Deweloperzy wymyślili koncepcję Living Style Guide, żeby się skupić na tym, co jest w rzeczywistości. Polecam przegląd narzędzi do tworzenia do Living Style Guide: link do Githuba
Bez współpracy między Designerami i Developerami żadne Style Guide nie pomoże. Projektanci muszą mieć swoje „reużywalne” elementy graficzne, a Deweloperzy swoje. Dobra komunikacja pomiędzy zainteresowanymi jest wskazana.
Moduły opracowane na podstawie style guide pozytywnie wpływają też na późniejze testowanie. Skoro dany moduł został przetestowany poprzednio i jest niezależnym modułem od innych, to jest większe prawdopodobieństwo, że nic się nie popsuje w międzyczasie, a nawet jeśli się popsuje to jeden fix rozwiąże problem na każdej stronie, gdzie dany moduł został użyty.
Style guide przydaje się też dla nowo zatrudnionych Designerów. Gdy firma się rozrasta, jeden Designer już nie wystarcza. Jeśli pracujecie w różnych miastach lub państwach, to spójny design ułatwia również komunikację.
Są też sytuacje, gdy Designer odchodzi. Jeśli nikt nie interesował się jego plikami, to nowy Designer ma często spory kłopot, bo dostaje w spadku bałagan. Nazwy plików nic mu nie powiedzą, a jak już znajdzie plik, to zobaczy mnóstwo niepotrzebnych warstw i nie będzie wiedział, która wersja ich kopii jest prawidłowa. Niestety Designerzy często muszą wymyślać wiele koncepcji, pracują pod presją i nie mają czasu, aby na końcu zadbać o porządek w swoich plikach.
Spójność z perspektywy użytkownika
„Consistency is one of the most powerful usability principles: when things always behave the same, users don’t have to worry about what will happen. Instead, they know what will happen based on earlier experience.” – Jakob Nielsen
Źródło
Spójność buduje zaufanie do brandu. Użytkownik przełączając się pomiędzy widokami lub różnymi aplikacjami jednej firmy, powinien zawsze czuć ten sam styl, znać kolorystykę i specyfikę interfejsu. Poprawna spójność pomiędzy produktami tej samej organizacji przekłada się wyższą konwersję użytkowników.
Gdy nie masz stylu
Wiele razy pracowałem na czyichś makietach oraz projektach graficznych i brak spójności jest rzeczą niestety powszechną. Potem przekłada się to oczywiście na plik CSS, w którym zamiast jednego rodzaju buttonu mamy kilka przycisków, gdzie nawet odcienie koloru są niewłaściwe. W takiej sytuacji wydłuża się zarówno czas wytwarzania produktu.
Myślicie, że na Waszej stronie wszystko jest spójne? Zdziwilibyście się 😛
Nie osądzajcie innych za szybko, bo być może sami macie coś do poprawienia 🙂
Brak style guide zmienia style sheet w style shit.
Z własnego podwórka
Posłużę się teraz przykładem możliwe najprostszym, czyli kolorami. Często tzw. „brand colors” choć są zdefiniowane, to niektórzy designerzy nie zawsze z nich korzystają. Odcienie różnią się między sobą i dochodzi do sytuacji, że mamy kilkanaście podobnych wersji danego koloru.
Z odcieniami szarości jest jeszcze gorzej, bo mało kto na to zwraca uwagę.
Podam przykład ze swojego podwórka. Jednym z moich pierwszych zadań po zatrudnieniu w AirHelp było ujednolicenie styli na stronie www (i wzięcie pod uwagę projektów aplikacji mobilnych, panelu pracownika, klienta i innych produktów).
Zebrałem więc elementy UI, ikonki, elementy wektorowe, jakie tylko udało mi się znaleźć w zbiorach… I co się okazało? Zamiast trzech zdefiniowanych odcieni zielonego mieliśmy ich blisko dwadzieścia, a odcieni szarości kilkadziesiąt.
Nawet projekt jednej i tej samej strony posiadał kilka nieprawidłowych odcieni zielonego. Jak się domyślacie bardzo się ucieszyłem, że wdepnąłem w… to nie lada ciekawe wyzwanie 😉
Kto może skorzystać?
Miejcie proszę na uwadze, że ten problem nie dotyczy tylko UI designerów, ale i innych, jak chciażby frontendowców, testerów czy PM’ów. Jeśli jesteś PM, to pomyśl, że ujednolicenie styli to nowy ficzer poprawiający web perfomance. Weźmy za przykład firmę Trulia.
Ujednolicenie styli spowodowało:
– wzrost liczby Page view o 11%,
– redukcję HTMLa o 48%,
– szybsze ładowanie strony o 21%,
– usunięcie nieużywanych CSSa o 135kB.
Src: https://www.youtube.com/watch?v=lsaG-EJcu88
Spotkałem się też kiedyś z informacją, że style sheet skrócił czas produkcji nowych stron o 300%. Mam prośbę – jeśli będziecie wprowadzać style guide to podzielcie się ze mną metrykami sprzed i po ich wprowadzeniu.
Kiedy każda podstrona jest inna, to może jest to fajne dla Designera (bo się nie nudzi tylko wymyśla za każdym razem coś nowego), ale nie dla użytkownika, ani frontendowców, którzy muszą zakodzić wszystko od nowa. Nie jest to fajne dla firmy, która traci przecież zasoby ludzkie i czas.
Modułowość i „reużywalność”
Mając ujednolicony i opisany design, możemy wykorzystywać te same moduły, a czas ich “produkcji” jest śmiesznie mały. Zamiast kilku tygodniu przeznaczonych na projekt, wdrożenie kodu i przetestowanie mamy co najwyżej kilka dni. Oczywiście Style guide nie może i nie powinno zabijać ducha kreacji wśród projektantów i tu trzeba umieć zachować zdrowy balans. Nie każda podstrona ma być kopią poprzedniej, tylko ma służyć potrzebom użytkowników. Jednak wszędzie tam, gdzie można użyć tego samego elementu lub modułu – użyj go.
Atomowy design
Tę sekcję zacznę od pytania: czym jest YouTube? Stroną internetową? Serwisem? Aplikacją mobilną?
Ja bym powiedział, że YT jest skomplikowanym systemem łączącym Użytkowników oglądajacych filmiki, Reklamodawców i Autorów filmików. Wszyscy oni korzystają z różnych platform i urządzeń (komórki, komputery, tablety) i mają odmienne potrzeby (Użytkownik oglądający: „Chcę obejrzeć coś śmiesznego siedząc na kibelku”, Reklamodawca: „Chcę, żeby mój produkt obejrzeli ludzie mające poczucie humoru, bo moja reklama jest zabawna”, Autor filmików: „Chcę pokazać jak mój pso-pająk przestraszył ludzi.”). Oglądający filmiki chcą być zaskakiwani przez Autorów filmików lub Reklamodawców, ale nie chcą być zaskakiwani przez dziwaczny interfejs. Ich nie obchodzi, że dla właścicieli YouTube składa się z kilku produktów, nad którym pracuje inny zespół ludzi. Dla użytkowników YouTube jest jeden. Dlatego YT musi mieć spójne style, aby użytkownicy łatwo z niego korzystali niezależnie od urządzenia i platformy. To takie oczywiste, kiedy to czytasz, ale czy jesteś w stanie dostrzec analogię do firmy, w której pracujesz? 😉
Ciekawą metodologię skupiającą się na projektowaniu systemów opartych na „reużywalnych” elementach, modułach i templatkach przedstawił Brad Frost w 2013 r. Metodologię tę nazwał Atomic Design. http://atomicdesign.bradfrost.com/
Brad przy projektowaniu znalazł analogię do świata chemii (pierwsze trzy poziomy), a dwa ostanie poziomy pochodzą ze świata
1. Atomy
Atomy są podstawowym budulcem wszechświata (neutrony i protony zostały tu świadomie pominięte). Mamy więc tutaj takie składowe jak: inputy, buttony, labels, paragraphs, kolory, fonty czy animacje.
2. Molekuły
Atomy tworzą molekuły. Przykładem molekuły są takie elementy jak labels, pole wyszukiwarki + przycisk – po połączeniu tych elementów mamy do czynienia z molekułą wyszukiwarki.
3. Organizmy
Organizmy są bardziej rozbudowanymi elementami interfejsu złożonymi z grup molekuł czy nawet innych organizmów. Przykładem organizmów są sekcje, czy moduły na stronie, jak np. belka nawigacyjna zawierająca logo, menu i pole wyszukiwarki.
4. Templatki
Templatki to makiety low-fidelity zbudowane z wielu organizmów. Część elementów będzie wysokiej jakości, a nowe elementy dopiero powstaną. Posiadając templatkę stakeholderzy widzą, co zamierzamy zbudować.
5. Strony
Strony są to po prostu makiety hi-fidelity, czyli wysokiej jakości/szczegółowości. Tutaj kończy się beztroskie projektowanie i zaczynają się schody z interesariuszami 😉
Podsumowanie
Przyznam otwarcie, że nie wyobrażam sobie rozpoczęcia nowego projektu bez stworzenia style guide.
A Ty co myślisz o konieczności zachowania spójności? Czy korzystasz z style guide w swojej firmie? A może powinieneś krytycznie spojrzeć w lustro? Napisz proszę komentarz o swoich doświadczeniach, obawach lub pomysłach.
W każdym razie, zachęcam Cię do zmierzenia się z tym problemem i rozwiązania go na korzyść użytkowników Twoich produktów oraz własnych. W przyszłym tygodniu czeka Cię druga część artykułu „Na ratunek spójności”. Tym razem pokażę, jak zastosować do tworzenia style guide jedno z ulubionych przez Designerów narzędzi, jakim jest Sketch. Atomic design w praktyce!
Edit: Powstała również kontynuacja tego artykułu, w której opisuję jak ze spójnością „radzi” sobie tvn24, allegro, o2 i co wspólnego z Atomic design ma Putin! LINK
Jeśli podobał Ci się artykuł podziel się nim na Facebooku 🙂
Ciekawy artykuł – Dzięki. SPÓJNOŚĆ w projektowaniu jest szalenie ważna, zachowując ją ułatwiamy użytkownikowi korzystanie z produktu.
Bardzo ciekawy artykuł. Już wiem, czym się kierować, jeśli będę współpracować z grafikiem. Dziękuję!
Jako frontend developer od dwóch lat tworzę projekty w oparciu o style guide i nie wyobrażam sobie dużej aplikacji czy serwisu bez niego.
Bardzo ciekawy artykuł nawet dla początkujących i w przyjazny sposób napisany. Dziękuje 🙂