Un director financiar deschide pentru a treia oară săptămâna aceasta dashboard-ul comandat în primăvară. Are 18 vizualizări pe trei tab-uri, indicatori cu valori roșii pe care nu îi întreabă nimeni niciodată, și un slicer pentru perioada anterioară pe care nu îl folosește pentru că oricum afișează doar luna curentă. Îl închide și deschide un Excel.

Scena se repetă în mii de companii. Nu pentru că oamenii sunt încăpățânați, ci pentru că dashboard-ul nu rezolvă întrebarea pe care ei o au în cap. Iar asta nu e o problemă de tool. E o problemă de design.

Articolul ăsta enumeră șapte greșeli design dashboard care apar în 80% dintre rapoartele business pe care le-am văzut în ultimii cinci ani, indiferent că vorbim de Power BI, Tableau, Looker sau o foaie Excel pretențioasă. Nu greșeli estetice — greșeli funcționale care fac dashboard-ul inutil.

design dashboard: 1. Prea multe KPI-uri pe ecran

Cea mai frecventă greșeală. Și cea mai ușor de evitat. Dar se face în continuare.

Un dashboard executiv tipic în 2026 conține între 12 și 20 de indicatori afișați simultan. Acest număr nu vine dintr-o decizie strategică. Vine din faptul că fiecare departament a cerut „să fie și KPI-ul nostru acolo" și nimeni n-a avut autoritatea să spună nu. Rezultatul: o pagină pe care ochiul cititorului nu știe unde să se oprească. În practică, dashboard-urile încărcate cu 12 KPI sunt aproape întotdeauna semnul că nimeni nu a hotărât ce contează.

Un dashboard executiv eficient are între 4 și 7 KPI-uri principale. Restul intră în drill-down sau în tab-uri secundare. Regula empirică: dacă un decident vede dashboard-ul și nu poate spune în 10 secunde dacă lucrurile merg bine sau prost, dashboard-ul a eșuat.

Soluția nu e estetică. E politică. Cineva trebuie să decidă, înainte de design, care sunt cele 5 numere care contează cu adevărat la nivelul cititorului-țintă. Dacă acea conversație nu se întâmplă, nimic în Power BI sau Tableau nu o să o repare.

2. Aceeași informație, formate diferite, fără justificare

A doua greșeală e mai subtilă. Aceeași metrică — vânzări lunare, de exemplu — apare pe același dashboard ca line chart, ca bar chart, ca KPI card și ca tabel detaliat. Toate patru.

Argumentul tipic e „pentru flexibilitate". Realitatea e că cititorul nu știe pe care din ele să se uite și ajunge să nu se uite pe niciuna. Fiecare vizualizare ar trebui să răspundă la o întrebare distinctă: tendința peste timp e pentru linie, comparația între segmente e pentru bare, totalul curent e pentru card. Dacă două vizualizări răspund la aceeași întrebare, una dintre ele e zgomot.

Există însă o capcană aici. Câteodată, redundanța intenționată e bună — un KPI mare pentru atenție rapidă plus un line chart pentru context. Diferența între redundanță utilă și zgomot stă în întrebare. Dacă poți articula clar care întrebare distinctă rezolvă fiecare element, ai redundanță utilă. Dacă nu poți, ai zgomot.

3. Culorile fără sens semantic

Roșu pentru ceva, verde pentru altceva, albastru pentru altceva și galben pentru încă altceva. Plus un rând de portocaliu, pentru că ce-ar fi un dashboard fără portocaliu.

O paletă cu 7-8 culori pe un singur ecran sparge complet capacitatea cititorului de a procesa rapid informația. Culorile în BI trebuie să aibă semnificație consistentă: roșu = problema sau ținta nerespectată, verde = OK, gri = informație neutră. Diferențele de culoare aleatorii pe categorii — un departament e mov, altul e turcoaz, altul e maro — nu adaugă nimic și obosesc.

Regula simplă: maxim 3-4 culori pe un dashboard, și fiecare să aibă sens semantic. Dacă vrei diferențiere între categorii, folosește tonuri ale aceleiași culori, nu culori distincte. Tableau și Power BI au teme native care fac asta corect. Recomand să le folosești în loc să improvizezi paleta.

4. Lipsa contextului numeric

Un dashboard arată „Vânzări luna curentă: 142.000 lei" și se oprește acolo. E mult? E puțin? E mai bine decât luna trecută? Cititorul trebuie să se gândească singur, ceea ce înseamnă că dashboard-ul nu și-a făcut treaba.

Orice număr afișat fără context comparativ e un număr orfan. Pentru fiecare KPI principal ar trebui să existe cel puțin un element de context — față de luna trecută, față de același trimestru anul trecut, față de țintă. Asta înseamnă că un KPI card pe un dashboard executiv arată minim trei lucruri: valoarea curentă, variația față de un punct de referință, și direcția trendului.

Lipsește unul dintre ele, KPI-ul nu funcționează. Cititorul are de făcut muncă în plus, și de cele mai multe ori nu o face.

5. Drill-down-uri care se pierd în neant

Designer-ul a construit o ierarhie de cinci nivele: Țară → Regiune → Județ → Oraș → Magazin. Beautiful. Cititorul intră, ajunge la nivelul Oraș, vede ceva interesant și — încearcă să se întoarcă. Nu există buton de back. Nu există indicator vizual al ierarhiei. Trebuie să închidă raportul și să-l deschidă din nou.

Drill-down-urile sunt utile când există o regulă clară: de unde am pornit, unde am ajuns, cum mă întorc. Fără asta, sunt o capcană. Power BI are breadcrumb-uri native; Tableau are tooltips cu butoane de navigare. Le folosești sau drill-down-ul devine un labirint.

O practică sănătoasă: maxim 3 niveluri de drill-down. Sub asta, riscul de a-l pierde pe cititor crește exponențial. Echipele care construiesc rapoarte de tip enterprise cu 5-6 niveluri trebuie să recunoască faptul că au de-a face cu un alt tip de tool — un explorer interactiv, nu un dashboard.

6. Filtre și slicer-e care nu se sincronizează

Slicer-ul de perioadă filtrează doar trei din cele opt vizualizări. Restul afișează „toate datele". Cititorul setează o perioadă, vede inconsistențe între grafice, începe să-și pună întrebări despre integritatea datelor.

E o greșeală tehnică care apare la rapoarte construite de mai multe persoane, sau la cele crescute organic peste ani. Soluția e disciplină: toate vizualizările principale pe același dashboard trebuie să răspundă la aceleași filtre globale. Excepțiile (de exemplu, un grafic care arată evoluția istorică indiferent de filtrul de an) trebuie etichetate explicit cu un titlu de tipul „Trend pe 36 de luni — nu este afectat de filtrul de perioadă".

Mai mult — slicer-ele care permit selecții multiple pe câmpuri cu sute de valori (de exemplu, slicer pe SKU pe un raport retail) sunt în 99% din cazuri inutile. Cititorul nu va selecta 17 produse manual. Dacă filtrarea fină e necesară, mecanismul corect e drill-through, nu slicer.

7. Lipsa unui take-away clar

Ultima greșeală e cea mai gravă, și ironic, cea mai puțin discutată. Dashboard-ul afișează date. Foarte multe. Dar nu spune nimic.

Un raport business bun nu e o colecție de grafice. E o narațiune. La nivel macro, dashboard-ul ar trebui să transmită un mesaj — implicit, prin design, nu prin text — într-un singur cuvânt: „OK", „problemă", „investighează".

În practică, asta înseamnă că dashboard-ul are o ierarhie clară: cel mai important indicator e cel mai mare și sus-stânga. Eventualele alerte sunt vizibile fără să cauți. Restul e context pentru cititorul care vrea să sape mai departe.

Dashboard-urile fără take-away sunt cele despre care toată lumea spune „arată bine", dar nu le folosește nimeni. Sunt obiecte de prezentat în ședințe trimestriale, nu instrumente de management. O echipă care vrea ca dashboard-urile ei să fie folosite trebuie să-și pună întrebarea brutală: ce ar trebui să facă un cititor diferit după ce vede acest raport, comparativ cu înainte? Dacă răspunsul e „nimic specific, doar să fie informat", dashboard-ul nu e un instrument, e decor.

Tema se leagă natural de discuția despre dashboard folosit, unde am intrat în detaliu pe pattern-urile pe care le observăm în piață. Pentru actualizări și detalii suplimentare, Tableau Blog rămâne sursa principală pe acest subiect. În fond, design dashboard nu e doar un concept tehnic — este o decizie de business cu impact direct pe productivitatea echipei.

Cum se evită toate șapte în practică

Niciun dashboard mare nu se construiește dintr-o singură iterație. Greșelile de mai sus apar în mod natural în prima versiune, indiferent cât de experimentat e analystul. Diferența între un raport prost și unul bun e numărul de iterații cu cititorul real, nu cu cel imaginar.

O practică care funcționează: înainte de a deschide Power BI sau Tableau, schițează dashboard-ul pe hârtie. Discută schița cu cel puțin doi cititori-țintă. Întreabă-i ce întrebare răspunde fiecare element. Dacă unul dintre elemente nu răspunde la o întrebare clară, nu îl construiești.

După ce dashboard-ul e gata, mai stai o săptămână fără să publici. Revii cu mintea proaspătă. Aproape garantat — vei elimina 2-3 elemente.

Echipele care lucrează în această disciplină au rapoarte mai puține, dar folosite. Restul produc decoruri pentru ședințe. Diferența nu e în tool, e în răbdarea de a separa ce contează de ce arată bine. Iar răbdarea asta e, până la urmă, ceea ce diferențiază un BI specialist serios de un constructor de pagini frumoase.

În practică, design dashboard a trecut de la subiect de roadmap la prioritate operațională pentru echipele care livrează rezultate de business — exact tipul de tracțiune pe care o vedem reflectată în deciziile reale de buget. Pentru cititorii care lucrează zilnic cu design dashboard, articolul rămâne deschis pentru update-uri pe măsură ce piața evoluează.