Dashboard już drugi raz pojawił się jako temat zadania Idź Pan w UI. W związku z tym tu i tam trochę o dashboardzie miałam okazję pogadać. Brakowało mi jednak na blogu takiego wpisu-podsumowania, gdzie zebrałabym najważniejsze informacje o dashboardach. A poniżej nagranie ze spotkania podsumowującego:
Czym jest dashboard w projektowaniu UI?
To ekran aplikacji (natywnej, webowej, mobilnej czy desktopowej), który jest szybkim podglądem najważniejszych informacji. Niekiedy pełni rolę rozprowadzenia użytkowników po produkcie, pozwalając na dodatkowy sposób przejścia do różnych obszarów aplikacji. Najczęściej to pierwszy ekran całego produktu lub ekrany wprowadzające np. do większych modułów (tak, dashboardów może być kilka). W polskich tłumaczeniach możecie spotkać się również z określeniami kokpit i pulpit. Jestem fanką angielskiego określenia, więc pozwolę sobie je w dalszej części wpisu używać.
Dashboard w swoim założeniu powinien oszczędzać czas użytkownika – ma na celu pokazać najważniejsze, istotne dane na pierwszy rzut oka. Dlatego projektujmy go tak, by pomagał użytkownikom w zwiększeniu wydajności.
Ale jak ustalić, co jest wystarczająco istotne, aby wyświetlać się na dashboardzie? Przyjrzyjmy się np. dashboardom w samochodach. Deska rozdzielcza samochodu służy do wyświetlania informacji istotnych do prowadzenia samochodu – prędkości, pokonanego dystansu, obrotów silnika, pozostałego paliwa i ostrzeżeń, gdy coś nie działa poprawnie. Nie spodziewamy się za to, że na desce rozdzielczej samochodu będą wyświetlane informacje o nowościach, lokalnych interesujących miejscach lub nadchodzących terminach (czegokolwiek), ponieważ jakkolwiek interesujące są te informacje, nie są istotne w chwili prowadzenia pojazdu. Wręcz mogłyby w wykonaniu tego zadania przeszkadzać.
I podobnie jest z dashboardami produktów cyfrowych. W przypadku większości dashboardów aplikacji użytkownicy skorzystają z informacji o ich bieżącym statusie, a także wszelkich pilnych informacji lub ostrzeżeń, z którymi muszą sobie poradzić.
Typy dashboardów
Tak jak wiele mamy typów produktów, tak trudno mówić o jednym typie dashboardu. Myślę, że korzystając z różnych produktów mieliście okazję również na różnorodne dashboardy trafiać. Te bardziej lub mniej przydatne, rozbudowane i minimalistyczne, a także takie, które możemy swobodnie dopasowywać do swoich potrzeb.
Szukając informacji o dashboardach, klasycznie możecie spotkać się z różnym podziałem. Podział, który występuje dość często to ten na:
- Dashboardy operacyjne – pomagają użytkownikowi zobaczyć, co się teraz dzieje (informacje dynamicznie się zmieniają).
- Dashboardy analityczne – dają użytkownikom jasny obraz trendów wydajności i potencjalnych problemów
- Dashboardy strategiczne – pozwalają użytkownikom śledzić ich główne cele strategiczne
Ale nie ma się co spinać. Jak wspomniałam – z UI (komponentami i wzorcami) jest tak, że podziały, nazwy, kategorie są tworzone raz na jakiś czas nowe. Trochę jak się piszącym napisze, tak wychodzi. Zdarza się, że ich opisy są tak ogólne, że w sumie wszystko da się pod to podpiąć. Czasami się wykluczają. Nie trzymajcie się więc kurczowo również tego powyższego podziału – bardziej chodzi o zwrócenie uwagi na cele takich dashboardów. A bardziej – elementów, które na te dashboardy wrzucacie.
Jaki jest cel dashboardu w waszym produkcie?
Klasycznie przy projektowaniu czegokolwiek warto sobie zadać pytanie – po co to robimy? Czy nasi użytkownicy potrzebują jakiejś formy podsumowania naszego produktu? Czy bardziej robimy dashboard dla zasady „no bo nasza konkurencja ma”?
Żeby dobrze odpowiedzieć sobie na te pytanie, trzeba odpowiedzieć na jeszcze jedno – czego potrzebują wasi użytkownicy? Czy wszyscy będą potrzebować tego samego? Czy będą tu różne role, a co za tym idzie – różne cele takiej osoby? To ma dość duże znaczenie przy rozbudowanych systemach zakładających różny stopień „specjalizacji” użytkowników. Załóżmy, że mamy system do zarządzania dużym, internetowym sklepem. Na inne rzeczy zwróci uwagę ktoś z obsługi klienta, a na inne osoby związane z marketingiem.
Dodatkowo inaczej będzie z produktu korzystać ktoś, kto dopiero się uczy – może potrzebować np. podpowiedzi, widocznego miejsca, gdzie znajdzie pomoc. Tymczasem bardziej zaawansowana osoba (jeśli damy taką możliwość) dopasuje sobie działanie aplikacji do swoich potrzeb i przyzwyczajeń. I na przykład chętniej skorzysta ze skrótów klawiaturowych.
Jak to przełożyć na interfejs?
Wiedza na temat tego jak użytkownicy korzystają z naszego produktu pozwoli na utworzenie konkretnych rekomendacji. Jeśli wiemy np. że najczęstszym zadaniem, po które użytkownicy wchodzą do produktu, jest sprawdzenie przychodzących wiadomości, odpowiedź na nie lub wysłanie informacji, możemy stworzyć ekran główny, który będzie odzwierciedleniem tych opcji. Wyświetli np. wszystkie nowe wiadomości w formie listy czy da możliwość natychmiastowej odpowiedzi bez potrzeby przechodzenia do kolejnych podstron. Może się okazać, że będzie to dużo bardziej przydatna opcji niż wyświetlenie na dashboardzie informacji, że jest „7 nowych wiadomości” – bo istotniejsze dla użytkowników będą np. od kogo są to wiadomości, jaki mają temat, treść bądź o której przyszły.
W projektach koncepcyjnych (typu Dribbble) często widzę podobny zakres informacji i układ treści. Jest jakaś lista, jakiś kalendarz (najczęściej z miniaturowymi kropkami sugerującymi, że coś tam jest), jakiś piękny wykres i kilka wyciągniętych na wierzch danych. Warto jednak zastanowić się czy – tak mały wykres pokazuje w ogóle istotne z punktu widzenia odbiorcy informacje? Czy zamiast dziesiątek kropek nie wygodniej byłoby zobaczyć jakiego typu „eventy” są zapisane w kalendarzu, o której godzinie itd? Efekt? Kosztem zmieszczenia wielu, atrakcyjnych wizualnie komponentów, gubi się trochę sens całości.
Kiedy projektujemy dashboard?
To, co może również pomóc w budowaniu skutecznego dashboardu, to moment, kiedy zaczynamy go tworzyć. Wbrew pozorom nie zaczynałabym projektu produktu od dashboardu właśnie. Dlaczego? Z prostej przyczyny. Dashboard jest podsumowaniem tego co mamy w produkcie. Dobrze jest zatem wiedzieć co w produkcie jest, jak wygląda, jak działa i jakie w związku z tym mamy możliwości.
To istotne zwłaszcza w produktach gdzie operujemy na dużych ilościach danych i strony nie będące podsumowaniem informacji – typu dashboard – będą wyglądały zupełnie inaczej niż te listujące informacje (listy, tabele, wyniki wyszukiwań). Z tego względu (osobiście) lubię i zachęcam do tego by projektować bardziej złożone komponenty w pierwszej kolejności, a potem tworzyć ich uproszczenia na potrzeby dashboardów. To pozwoli nam też szybciej zweryfikować zakres informacji (i ich format), który możemy na takim ekranie pokazać. Bo po prostu wiemy jak zbudowane są poszczególne moduły produktu i jakim kosztem będziemy zaciągać ich fragmenty na główny ekran.
Gdzie szukać inspiracji do projektowania dashboardów?
Jeśli nic nie przychodzi nam do głowy, a przed nami do zaprojektowania dashboard, warto sięgnąć w pierwszej kolejności po konkurencję pośrednią i bezpośrednią. Zobaczyć po prostu jak inne firmy tego typu rozwiązują problem dashboardu. Co więcej – możecie nawet podjąć się testów takich rozwiązań z obecnymi użytkownikami (a potencjalnie waszymi przyszłymi). Nie z każdym produktem to się uda, nie z każdym będzie łatwo pozyskać grupę – ale obecne doświadczenia i bolączki konkurencyjnych produktów można przekuć na ciekawe, wygodniejsze rozwiązania w waszym produkcie.
Kolejne miejsce to oczywiście produkty, które dashboardy często mają:
- aplikacje finansowe, inwestycyjne, banki (konta firmowe czy indywidualne)
- aplikacje związane ze zdrowiem i sportem, trackujące nasze postępy treningowe czy stan zdrowia (np. wbudowana w iOS aplikacja „Zdrowie”)
- aplikacje do zarządzania zadaniami – miewają często formę podsumowania naszych trwających zadań i porównanie do tego jak innym idzie postęp w zamykaniu swoich zadań (np. Asana)
- aplikacje służące do planowania / śledzenia realizacji celu, aplikacje wspierające budowanie nawyków
Natomiast – to wciąż tylko inspiracje. Zanim podejmiemy decyzję co ostatecznie na nim umieścimy – pytamy naszych użytkowników i testujemy rozwiązanie.
O czym jeszcze trzeba pamiętać projektując dashboard?
Moim zdaniem jest kilka takich rzeczy, na które trzeba zwrócić uwagę, zwłaszcza gdy za projektowanie dashboardu zabieramy się pierwszy raz.
Dobór treści
Zasada jest prosta – umieszczamy tylko to, co jest niezbędne. Jeśli nie pokazujemy przydatnych informacji, nie ma znaczenia, jak je ułożymy – użytkownicy nie będą mieli potrzeby ich oglądać. A dashboard stanie się pośrednim ekranem między faktycznie przydatnymi podstronami.
Dostosowanie informacji
Niektóre aplikacje pozwalają użytkownikom na układanie treści w dowolnej kolejności, zmianę palety kolorów, ukrywanie niektórych z nich, po prostu dostosowanie zawartości do swoich potrzeb. To dobra praktyka w projektowaniu interfejsów, jednak wymaga przemyślanego projektu i czasu na wdrożenie.
Warto takie dostosowanie informacji przewidzieć gdy mamy kilka grup użytkowników i trudno założyć, które elementy sprawdzą się w takiej formie wspólnego dashboardu. Natomiast jeszcze raz zaznaczę czas, jaki jest potrzebny na wdrożenie, ale też zaprojektowanie takiego wariantu (a właściwie wielu wariantów i zachowywania się ich na różnych rozdzielczościach ekranów).
Kontekst danych
Co to za wykresy, co to za tabelki? Nie zapominajcie o kontekście! Wykres powinien mieć jakiś tytuł i pokazywać dane liczbowe (nie tylko obrazki!), tabela też dotyczy konkretnego zbioru danych. Projekty dribbblowe przyzwyczaiły nas do oglądania gradientowych wykresów i tabelek pozbawionych w zasadzie konkretnych informacji – więc zanim zaproponujemy zupełnie abstrakcyjną wizualizację informacji – trzeba zastanowić się co użytkownicy mają z tych danych wyciągnąć?
Wykresy bez efektu wow
Częstym elementem dashboardów są wspomniane już wykresy. Pamiętajcie, że chodzi w nich o to żeby szybko pokazać istotne informacje. Dlaczego o tym wspominam? W projektach do portfolio natykam się na wykresy z efektem wow – z cieniami, w 3d i innymi bajerami, które mogą zakłamywać prezentowane dane. Tu zasada – im prościej tym lepiej naprawdę może się sprawdzić. W dodatku podziękują wam za to osoby, które później ten projekt muszą wdrożyć.
Proste kompozycje
Porządek – to klucz do dashboardowego sukcesu. Najlepiej zaprojektowane treści nie będą czytelne w odbiorze jeśli całość nie zostanie dobrze zakomponowana. Projektując poszczególne komponenty zawsze oglądajcie je w kontekście całego ekranu. Świetnie zaprojektowana tabela może nie wyglądać tak seksi, gdy zestawi się ją z wykresem i drugą tabelą. Dlatego warto postawić na proste układy, które pozwolą wizualnie oddzielić od siebie prezentowane treści.
Osobne sekcje będą wymagać jasnego rozdzielenia – czy pokazania ich na osobnych tłach (w formie np. kafli) czy przez zwiększenie marginesów lub ramki. Te ostatnie są w gruncie rzeczy najtrudniejsze. Na ekranie wypełnionym komponentami, kiedy każdy z nich ma ramkę (jak jasna i delikatna by nie była), może zrobić się dość duże zamieszanie wizualne.
A może bez dashboardu?
Warto pamiętać, że dashboard wcale nie jest obowiązkowym elementem produktu. Czasami lepiej przekierować użytkowników od razu do głównych zadań – zwłaszcza, jeśli produkt nie jest bardzo rozbudowany. Podobną zasadę możemy stosować do właściwie wszystkiego w naszych produktach.
W pracy z klientami, często widzę próby dodawania kolejnych funkcji, niekoniecznie niezbędnych, tak dla zasady – bo inni mają, bo jest dużo wolnego miejsca, bo „coś tam”. Najlepiej zatrzymać się w tym momencie i spróbować walidować – czy jest sens poświęcać czas całego zespołu dla funkcji czy całych ekranów, których w sumie nikt nie potrzebuje.
