Dashboard plný čísel nestačí: ako navrhnúť prehľad, podľa ktorého ľudia konajú

01Jedna obrazovka má slúžiť konkrétnej práci

Napíšte krátku situáciu: vedúci podpory začína rannú zmenu, potrebuje nájsť rizikové požiadavky a upraviť ich pridelenie. Z tohto zadania vyplýva priorita, pracovná fronta a prístup k detailu. Nevyplýva z neho potreba zobraziť každý údaj, ktorý aplikácia dokáže spočítať.

Microsoft pri návrhu dashboardov odporúča vychádzať z publika a zvýrazniť informácie potrebné na rozhodovanie. Pre vlastnú aplikáciu to znamená aj rozlíšenie rolí. Pracovník potrebuje vlastné úlohy, vedúci riziká tímu a majiteľ súvislosti naprieč prevádzkou.

Pripravte tri bežné situácie a jednu výnimočnú. Napríklad začiatok zmeny, kontrolu oneskorených úloh, hľadanie príčiny nárastu a výpadok dát. Pri každej určte potrebné informácie a očakávaný krok. Tento zoznam neskôr poslúži na prevzatie riešenia.

Ak používateľ potrebuje pravidelne inú agendu, zvážte samostatný pohľad. Rozbaľovacie nastavenie s desiatkami volieb nemusí vyriešiť nesprávne zadanie hlavnej obrazovky.

02KPI potrebuje význam, obdobie a hranicu

Číslo bez definície môže viesť k nesprávnemu záveru. „Otvorené požiadavky“ môžu zahŕňať aj prípady čakajúce na zákazníka. „Priemerný čas riešenia“ sa mení podľa toho, či počítate kalendárny čas, pracovný čas alebo iba čas aktívneho spracovania.

Prahová hodnota musí vychádzať z pracovného procesu. Ak požiadavka prekročí termín, má byť jasné, ktorý termín a kto ho určil. Nastavenie červeného stavu podľa ľubovoľného čísla môže vytvárať dojem naliehavosti bez užitočného dôvodu.

Ukážte aj rozsah údajov. Prehľad jedného tímu sa nemá tváriť ako výsledok celej firmy. Pri filtrovaní jasne označte, čo sa zmenilo a či sa filter vzťahuje na všetky zobrazené metriky.

Pri percentách vysvetlite aj základ výpočtu. Podiel oneskorených požiadaviek sa dá počítať zo všetkých otvorených prípadov alebo len z tých, ktorým už uplynul termín. Dve správne spočítané hodnoty tak môžu odpovedať na rozdielne otázky. Pri malej vzorke doplňte absolútny počet, aby výrazné percento nezakrývalo niekoľko záznamov. Ak sa definícia metriky zmení, označte to aj v historickom porovnaní. Používateľ nemá zameniť zmenu metodiky za skutočnú zmenu prevádzky.

03Najprv priorita, potom kontext a detail

V hornej časti zvýraznite to, čo používateľ potrebuje posúdiť ako prvé. Nižšie môže nasledovať trend a pracovná fronta. Detail patrí tam, kde pomáha rozhodnutie overiť. Veľkosť prvku má vyjadrovať jeho význam, nie počet dostupných polí.

Nasledujúca ukážka je ilustratívna. KPI 12 predstavuje modelový počet požiadaviek po termíne. Trend 18, 24, 21 a 30 zobrazuje modelové počty uzavretých požiadaviek v štyroch týždňoch. Nejde o výsledky zákazníka ani o tú istú metriku. Pracovná fronta používa označenia 001 a 002 a vlastníkov A a B.

Vedúci z ukážky zistí, že má riešiť oneskorené prípady, a otvorí ich detail. Týždenný trend mu poskytne širší kontext, ale sám nevysvetlí príčinu oneskorenia. Rozhranie má umožniť prejsť k relevantným záznamom, bez straty zvoleného obdobia a tímu.

04Filtre a čerstvosť údajov musia byť viditeľné

Predvolené filtre majú zodpovedať bežnej práci. Používateľ má vedieť, ktoré obdobie, tím alebo prevádzku práve sleduje. Aktívne obmedzenia ukážte aj vtedy, keď je panel filtrov zatvorený. Pri zdieľaní odkazu alebo exporte určte, či sa tento kontext zachová.

Čas „aktualizované o 09:15“ má označovať úspešné získanie relevantných údajov. Pri viacerých zdrojoch môže byť potrebné ukázať odlišné časy alebo spoločný stav. Prehľad s dnešným nadpisom a včerajšími objednávkami je pre operatívnu prácu nebezpečne nejednoznačný.

Oddeľte prázdny výsledok od chyby. Počet nula môže znamenať, že žiadna požiadavka nie je po termíne. Môže však znamenať aj nesprávny filter alebo nedostupný zdroj. Pri výpadku ponechajte posledné údaje iba s jasným označením ich veku a obmedzení.

Pri obnovení údajov neresetujte bez dôvodu rozpracovanú úlohu ani zvolený výber. Ak sa záznam zmenil alebo zmizol, vysvetlite, čo sa stalo. Dynamický dashboard má byť predvídateľný aj počas práce, nie iba pri prvom načítaní.

05Graf vyberajte podľa otázky

Trend v čase potrebuje čitateľnú časovú os. Porovnanie kategórií má umožniť ľahko porovnať ich hodnoty. Keď používateľ potrebuje presné údaje alebo následnú akciu pri každom zázname, často mu lepšie poslúži tabuľka.

Mierka nesmie vytvárať zavádzajúci dojem. Stĺpcový graf spravidla potrebuje začiatok na nule, aby dĺžka stĺpca verne vyjadrovala hodnotu. Pri časovej krivke s obmedzenou osou jasne ukážte jej rozsah a zvážte, či detail pomáha otázke. Porovnateľné grafy majú používať zrozumiteľné a konzistentné mierky.

Pri veľkom množstve dát nezmenšujte všetko na nerozoznateľné body. Zvoľte vhodnú agregáciu a umožnite zistiť presné údaje. Používateľ má vedieť, či bod znamená jednu udalosť, súčet za deň alebo priemer. Zmena agregácie môže výrazne zmeniť dojem z výsledku.

Nepridávajte ďalší typ grafu iba pre vizuálnu pestrosť. Každý nový spôsob čítania stojí používateľa pozornosť. Pomôže konzistentné označenie metrík, jednotiek a obdobia, aj keď sú viaceré pohľady postavené na odlišných údajoch.

06Prístupnosť a oprávnenia patria do návrhu

Červená a zelená samy nestačia. WCAG vysvetľuje použitie farby tak, aby farba nebola jediným nositeľom významu. Stav doplňte názvom, symbolom alebo iným zrozumiteľným rozlíšením. Myslite aj na kontrast a čítanie pri zväčšení.

W3C pri zložitých grafoch odporúča textové sprístupnenie podstatných informácií. V dátovej aplikácii môže pomôcť tabuľkové zobrazenie a stručný opis trendu. Presné čísla nemajú byť dostupné iba pri prejdení myšou.

Otestujte filtre a akcie klávesnicou. Princíp ovládania klávesnicou sa týka aj interaktívnych dátových prvkov. Pri obnovení alebo filtrovaní má používateľ dostať zrozumiteľnú informáciu o výsledku; stavové správy sa riešia aj pre pomocné technológie.

Oprávnenia musia platiť pre podkladové údaje, detail aj export. Skrytie karty v rozhraní samo osebe nepredstavuje ochranu. Zamestnanec bez prístupu k osobným údajom nemá dostať tieto údaje cez stiahnutý súbor alebo odkaz na detail. V teste preto použite účty odlišných rolí.

07Prevezmite dashboard na konkrétnych úlohách

Nechajte budúceho používateľa pracovať s realistickou vzorkou. Požiadajte ho, aby našiel prioritný problém, overil jeho podklad a vykonal ďalší krok. Sledujte, kde váha, čo si zle vysvetľuje a či musí údaje prepisovať mimo aplikácie. Zistenia porovnajte medzi rolami.

1. Vyberte používateľa a jeho rozhodnutie. Spíšte bežné úlohy aj výnimku.
2. Dohodnite definície, obdobia a zdroje. Určte pravidlá pri neaktuálnych dátach.
3. Navrhnite prioritu, kontext a cestu k detailu. Preverte ovládanie a oprávnenia.
4. Otestujte úlohy, opravte nejasnosti a overte rovnaké výsledky v exporte.

Pri rozsiahlej tabuľke overte vyhľadávanie, poradie, stránkovanie a správanie po zmene filtra. W3C odlišuje tabuľku od interaktívnej mriežky; konkrétny spôsob ovládania má zodpovedať funkcii. Používateľ nemá hádať, či kliknutie otvorí detail, označí riadok alebo zmení údaj.

Pred spustením skúste aj pomalé načítanie, výpadok jedného zdroja a záznam, ktorý medzičasom upravil kolega. Pre prevádzkovú obrazovku sú tieto situácie rovnako dôležité ako ideálna ukážka. Zistenia zapíšte ako konkrétne opravy, ktoré sa dajú znovu preveriť.

Otestujte aj zariadenie, na ktorom sa prehľad používa. Vedúci v kancelárii môže pracovať s veľkým monitorom, pracovník v teréne potrebuje na telefóne rýchlo nájsť konkrétnu úlohu. Mobilná verzia preto môže ukázať prioritu a frontu skôr než celý súbor grafov. Zachovajte rovnaké definície a stav filtrov, ale poradie prispôsobte práci. Pri teste si všimnite aj situáciu, keď človek otvorí detail a vráti sa späť. Obrazovka má zachovať kontext, aby nemusel znovu hľadať rovnaký záznam.

Dohodnite, čo má obsahovať export: všetky oprávnené záznamy alebo iba aktuálny filtrovaný výber. Uveďte obdobie, čas vytvorenia a použitú definíciu metriky. Súbor odoslaný kolegovi potom zostane zrozumiteľný aj mimo obrazovky, z ktorej vznikol.

08Najčastejšie otázky o dizajne dashboardov