Dashboard tasarımı nasıl yapılır?

Kısaca

Page Laubheimer (NN/g) dashboard'u, tek sayfada bir araya getirilmiş veri görselleştirmeleri diye tanımlar. Amacı, kullanıcıya bir bakışta bilgi verip hızlı harekete geçmesini sağlamaktır. Laubheimer'e göre dashboard serbest keşif için tasarlanmaz.

Türkçede panel, yönetim paneli ya da admin panel de denir. Bu sayfada hepsini aynı kalıp olarak anlatıyorum: kullanıcı ekrana bakar, bir soruya cevap arar ve karar verir.

Audit'lerde en sık gördüğüm dashboard sorunu fazlalıktır. Ekip elindeki her metriği ekrana koyar, kullanıcı aradığı tek sayıyı bulamaz. Aşağıdaki canlı örnekte bu farkı kendi sürenizle ölçebilirsiniz.

Önce kitle ve karar

Dashboard tasarımına grafikle değil, bir soruyla başlarım. Bu ekrana kim bakacak ve baktıktan sonra hangi kararı verecek? Cevabı yazamıyorsanız ekranda neyin olacağına da karar veremezsiniz.

Laubheimer iki tür dashboard ayırır. Operasyonel dashboard, zamanın önemli olduğu işlerde kritik bilgiyi hızla verir. Sunucu durumu ya da hasta değerleri gibi sürekli değişen veriler buna örnektir.

Analitik dashboard ise daha az acil kararlar içindir. Hangi konuyu daha fazla düşünüp incelemek gerektiğini gösterir. İki tür aynı ekranda karışınca ikisi de zor okunur.

Kate Moran (NN/g) grafik seçimini de aynı soruyla başlatır: amacınız ne? Moran'a göre bir sayı bağlam olmadan anlamsızdır, onu yorumlamak için başka bir sayıyla karşılaştırırız. Moran'ın örneklerinde bu karşılaştırma geçmiş yıllar, başka bir özellik ya da başka bir kullanıcı grubudur.

İşe başlamadan kısa bir liste yazarım:

• Bu ekrana kim bakıyor, ne sıklıkla bakıyor? Elinizde bir persona varsa ondan başlayın.
• Baktığında hangi soruyu soruyor? "Bu ay hangi bölge hedefin altında?" gibi tek bir cümleyle yazın.
• Cevabı gördükten sonra ne yapıyor? Birini mi arıyor, bir kaydı mı açıyor? Belki de hiçbir şey yapmıyor.
• Her sayıyı neyle karşılaştırıyor? Hedefle, geçen dönemle ya da başka bir grupla.

Admin panelde soru biraz değişir. Yönetici çoğu zaman bir sayıya bakmaz, bir kaydı bulup üzerinde işlem yapar. Kurumsal ürünlerde ürünü alan ile kullanan kişinin neden ayrıştığını B2B ve B2C UX farkı yazısında anlattım.

Öncelik: en önemli bilgi nerede durur

Ekranın en görünür yeri, kitlenin sorusunun cevabına ayrılır. Kalan her şey ondan sonra gelir ya da başka bir sayfaya taşınır.

Kate Kaplan (NN/g) karmaşık uygulamalar için sekiz ilke yazar. Sonuncusu önemli bilgiyi öne çıkarmakla ilgilidir. Kaplan'a göre bunun için vurgu eklemek yetmez, gereksiz öğeleri çıkarmak gerekir.

Kaplan'ın örneğinde sayıların yanına para temalı ikonlar konmuş bir dashboard var. Kaplan bu fazladan grafiklerin görsel aramayı zorlaştırdığını, sade sayı kartlarının veriyi bulmayı kolaylaştırdığını yazar. Aşağıdaki kalabalık paneldeki renkli ikonlar da bu türden.

Uyarılarda da aynı kural geçerli. Laubheimer, büyük veri yığınlarını izleyen dashboard'ların dikkati kritik değerlere yönlendirmesi gerektiğini söyler. Önceliklendirilmeden art arda gelen uyarılar bunun tersini yapar.

Benim kullandığım sıra şöyle:

1. En üstte sorunun cevabı: tek cümle ya da tek sayı, karşılaştırmasıyla birlikte.
2. Altında cevabı açıklayan grafik.
3. En altta ya da bir tıkla açılan ayrıntı: tablo, döküm, geçmiş.

Kaplan ayrıntıyı ana ekrandan çıkmadan göstermeyi de önerir. Grafikteki bir noktanın üstüne gelince kesin değeri bir ipucu kutusunda göstermek buna örnektir. Seçenek sayısının karar süresine etkisini Hick yasası sayfasında ayrıca anlattım.

Canlı örnek: aynı veri, iki panel

Aşağıda bir satış ekibinin aylık paneli var. İki halde de veri aynı. Kalabalık halde cevap bir halka grafik, bir lejant ve ayrı bir hedef tablosuna dağılmış. Sade halde cevap en üstte yazıyor, altındaki grafik de onu gösteriyor.

Önce kalabalık halde görevi deneyin, sonra sade halde. İkinci denemede cevabı bildiğiniz için hızlanırsınız, bunu hesaba katın. Yine de farkın büyük kısmının tasarımdan geleceğini bekliyorum.

Aynı veri, iki panel

Kalabalık hali

Dönem: Bu ay Kanal: Tümü Tutar: bin TL Güncelleme: 09.00 Karşılaştırma: geçen ay

Toplam satış

1.135 bin TL

Geçen aya göre +%2

Ziyaret

48.210

Geçen aya göre −%3

Dönüşüm oranı

%2,4

Geçen aya göre +0,1 puan

Sepet ortalaması

612 TL

Geçen aya göre +%1

İade oranı

%3,1

Geçen aya göre −0,4 puan

Aktif müşteri

9.874

Geçen aya göre +%5

Bölgelere göre satış payı

• Akdeniz 168
• Ege 236
• İç Anadolu 198
• Karadeniz 121
• Marmara 412

Toplam hedefe ulaşma

%103

Bölge hedefleri (bin TL)

Bölge	Hedef	Geçen ay
Marmara	380	395
Ege	250	241
İç Anadolu	190	185
Akdeniz	160	171
Karadeniz	120	118

Uyarılar (7)

• Stok: 14 ürün kritik seviyede
• Ege: yaz kampanyası sona erdi
• Sunucu yanıt süresi arttı
• Yeni müşteri yorumu: 23
• Akdeniz: geçen aya göre düşüş
• Fatura entegrasyonu gecikmeli
• Haftalık rapor hazır

Sade hali

Filtre: Bu ay, tüm kanallar. Tutarlar bin TL.

1 bölge hedefin altında: Ege. Hedefin %94'ünde, 14 bin TL eksik.

Bölgelere göre satış ve hedef, hedefe en uzak bölge üstte

• Ege 236 / 250, %94 Hedefin altında

• Karadeniz 121 / 120, %101 Hedefte

• İç Anadolu 198 / 190, %104 Hedefte

• Akdeniz 168 / 160, %105 Hedefte

• Marmara 412 / 380, %108 Hedefte

Bu ayki satış Hedef

Toplam satış

1.135

Hedef 1.100

Hedefe ulaşma

%103

5 bölgenin toplamı

Hedefteki bölge

4 / 5

Yalnızca Ege hedefin altında

Veriler uydurmadır, iki panelde de aynıdır. Görevi başlatın, cevabı bulunca alttan bölgeyi seçin; süreniz kaydedilir. Sonra öbür hali seçip tekrar deneyin. JavaScript kapalıysa iki panel alt alta görünür.

Kalabalık halde cevabı bulmak için iki ayrı yerdeki sayıları aklınızda birbirinden çıkarırsınız. Akdeniz'in geçen aya göre düştüğünü söyleyen uyarı da dikkati yanlış bölgeye çeker. Akdeniz düşmüştür ama hâlâ hedefin üstündedir.

Sade halde hedefin altındaki bölge üç ayrı yoldan görünür: yazıyla, etiketle ve çizgili desenle. Renkleri ayırt edemeyen biri de cevabı yazıdan ve desenden okuyabilir.

Grafik seçimi

Grafik seçerken kendime şunu sorarım: kullanıcı bu grafikte neyi karşılaştıracak? Laubheimer, insanların uzunlukları ve iki boyutlu konumu oldukça doğru tahmin ettiğini yazar. Alanı ve açıyı ise kötü tahmin ederler.

Bu yüzden sayısal karşılaştırmanın temel araçları çubuk ve çizgi grafiktir. Çubuk grafik uzunluğu, çizgi ve dağılım grafiği konumu kullanır.

Kullanıcının sorusu	Grafik	Not
Hangisi daha büyük?	Çubuk grafik	Çubukları sıralayın. Etiketler uzunsa Moran yatay çubuk önerir.
Zamanla nasıl değişti?	Çizgi grafik	Moran, verinin toplandığı noktaların işaretlenmesini önerir.
Hedefe ne kadar yakın?	Bullet chart (hedef çizgili çubuk)	Laubheimer bunu kadranlı göstergenin yerine önerir.
İki şey birlikte mi değişiyor?	Dağılım grafiği	Noktalar çizgiyle bağlanmaz.
Tek bir sayı ne durumda?	Büyük sayı	Yanına hedefi ya da geçen dönemi yazın.

Kaçındığım grafikler de belli:

• Pasta ve halka grafik. Laubheimer pasta grafiği çoğu iletişim işinde zayıf bulur. İstisnası, bir parçanın açık ara büyük olduğu durumdur. Halka grafik, ortadaki boşluk yüzünden daha da zor okunur.
• Kadranlı gösterge. Araba göstergesine benzeyen yuvarlak kadranlar açıyla çalışır ve çok yer kaplar. Laubheimer'e göre doğrusal grafiklerden daha zor okunurlar.
• 3B grafik. Üç boyut şekilleri ve hizayı bozar. Laubheimer'e göre 3B çubukta tepenin hangi değeri gösterdiğini ve kılavuz çizgilerle nasıl hizalandığını görmek çok zorlaşır.
• Yığılmış çubuk. Moran, aynı noktadan başlamayan parçaların zor karşılaştırıldığını yazar. Bunun yerine her sonuç için ayrı bir çubuk grafik önerir.
• Ağaç haritası (treemap). Laubheimer'e göre karmaşık bir veri alanına küçük bir alanda toplu bakış verir. Basit ve eyleme dönük bir dashboard'a ise uymaz.

Rengi de büyüklük göstermek için kullanmam. Laubheimer'e göre rengin doğal bir sırası yoktur. Renk tonu ya da doygunluğu ise ikinci bir gruplama işareti olarak işe yarar.

Boş, yükleme ve hata durumları

Dashboard'un en çok ihmal edilen halleri, verinin olmadığı ya da henüz gelmediği anlardır. Tasarım dosyasında her kart doludur. Gerçek hesapta ise yeni kullanıcının paneli boştur ya da bir sorgu sonuç döndürmez.

Boş durum

Kaplan'a göre boş bir panel kullanıcıyı belirsizlikte bırakır. Sistem hâlâ çalışıyor mu, bir hata mı oldu, yoksa filtre mi yanlış? Kaplan'ın önerisi, boş alana kısa bir durum mesajı yazmaktır: "Seçilen tarih aralığında gösterilecek kayıt yok."

Kaplan iki adım daha önerir. Boş alan, oraya neyin geleceğini öğretebilir. Alanı dolduracak işe doğrudan bir yol da vermelidir. Kaplan'ın örneğinde boş bir uyarı panelinde bir "Oluştur" butonu durur.

Yeni hesabın boş ekranını onboarding tasarımı kalıbında ayrıca anlattım.

Yükleme

Kaplan'ın yükleme anı için de bir uyarısı var. İçerik hâlâ yüklenirken "Kayıt yok" yazmak yanıltıcıdır. Kullanıcı ya bekler ya güvenini kaybeder ya da içerik gelmeden sayfadan çıkar.

Samhita Tankala (NN/g) bekleme süresine göre şu ayrımı yapar:

• 1 saniyenin altında: iskelet ekran ya da dönen simge gerekmez.
• 2–10 saniye: tek bir kart için dönen simge, sayfanın tamamı için iskelet ekran.
• 10 saniyenin üstünde: süre tahmini veren bir ilerleme çubuğu.

Dashboard'da kartlar çoğu zaman ayrı ayrı yüklenir, bu yüzden her kartın kendi yükleme halini çizerim. Tankala'nın uyarısını da hesaba katarım. Parlayan ya da nabız gibi atan iskeletler dikkat dağıtabilir ve erişilebilirlik sorunu çıkarabilir.

Hata

Tim Neusesser ve Evan Sunwall (NN/g), hata mesajının sorunun çıktığı yere yakın durmasını ister. Dashboard'da bu yer, veriyi getiremeyen karttır. Mesajı sayfanın tepesine değil, o kartın içine yazarım.

Mesaj sade dille yazılır ve bir çözüm önerir. "Hata 503" yerine "Satış verisi şu an gelmiyor. Birkaç dakika sonra yeniden deneyin." yazmak buna örnektir. Yazarlara göre hata yalnızca renkle ya da animasyonla gösterilmemelidir.

Bir kart hata verdiğinde öbür kartlar çalışmaya devam etmeli. Tek bir sorgu yüzünden bütün panelin bir hata ekranına dönmesi, çalışan veriyi de kullanıcıdan saklar.

Filtreler

Laubheimer veri tablolarında filtrelerin kolay bulunmasını, hızlı ve güçlü olmasını ister. Dashboard filtreleri için de aynısını düşünürüm. Kullanıcı tarih aralığını ya da bölge seçimini aramak zorunda kalmamalı.

Daha önemli kural şu: filtre açıksa ekran bunu açıkça söylemeli. Laubheimer, filtrelerin etkin olduğunu gösteren net bir görsel işaret ister. Bu işaret yoksa kullanıcı filtrelenmiş sayıyı toplam sanır.

Audit'lerde sık gördüğüm bir tuzak var. Kullanıcı geçen hafta bir bölge filtresi seçmiştir, panel bunu hatırlar ve bugün bütün sayılar düşük görünür. Ekranın üstünde "Filtre: Ege, son 7 gün" gibi bir satır bu karışıklığı önler.

Kaplan, dashboard düzenlenirken değişikliğin anında önizlenmesini de örnek gösterir. Kullanıcı sonucun niyetine uyup uymadığını görmek için işin sonunu beklemez. Az kullanılan seçenekleri de yalnızca gerektiklerinde gösterin; Kaplan buna aşamalı gösterim der.

Erişilebilirlik: renge dayanmayan grafik

Grafik bilgiyi yalnızca renkle veriyorsa bazı kullanıcılar onu okuyamaz. Laubheimer, genel nüfusun %4,5'ine kadarında bir tür renk körlüğü olduğunu yazar. Renk körlüğü erkeklerde kadınlardan çok daha yaygındır.

WCAG 2.2'deki 1.4.1 Rengin kullanımı ölçütü (A düzeyi), rengin bilgiyi göstermenin tek görsel yolu olmamasını ister. W3C'nin yeterli teknikleri arasında grafikler için iki tanesi öne çıkar. Biri renkle birlikte desen kullanmaktır (G111). Öbürü renkle verilen bilgiyi metinde de vermektir (G14).

1.4.11 Metin dışı kontrast ölçütü (AA), grafiğin anlamak için gereken parçalarına yanındaki renge karşı en az 3:1 kontrast ister. W3C'nin örneğine göre çizgi grafikteki çizgiler bu kurala girer. Pasta dilimlerinin değerleri ayrıca uygun biçimde verildiyse, dilimler anlamak için gerekli sayılmaz.

Pratikte şunları yaparım:

• Her çubuğun yanına adını ve değerini yazarım. Kimse lejanta bakıp renk eşleştirmek zorunda kalmaz.
• Hedefin altındaki değeri renkten başka bir işaretle de ayırırım: desen, ikon ya da "Hedefin altında" etiketi.
• Grafiğe ekran okuyucunun okuyacağı bir metin karşılığı veririm. Renkle verilen bilgi bu metinde de yer alır.
• Çizgi ve çubuk renklerini kontrast hesaplayıcıda zemine karşı ölçerim.

Ölçütlerin tamamını ve seviyeleri WCAG rehberinde anlattım.

Mobilde dashboard

Telefonda yan yana duran kartları alt alta dizerim. Sıra masaüstündeki önceliği izler: sorunun cevabı en üstte kalır. Yukarıdaki örneği dar bir ekranda açarsanız kartların dikey dizildiğini görürsünüz.

Geniş tabloları telefona sığdırmak için yazıyı küçültmem. Her satırı bir karta çeviririm ya da yalnızca en önemli iki sütunu gösteririm. Dokunma hedeflerinin boyutunu da Fitts yasası sayfasındaki mantıkla ayarlarım.

Yayından önce kontrol listesi

• Ekranın kitlesini ve verdiği kararı tek cümleyle yazdım.
• En üstteki bilgi, bu kararın cevabı.
• Her sayının yanında bir karşılaştırma var: hedef, geçen dönem ya da benzer grup.
• Süs ikonlarını ve 3B efektleri çıkardım.
• Pasta, halka ve kadranlı göstergenin yerine çubuk ya da bullet chart kullandım.
• Her kartın boş, yükleme ve hata hali çizildi.
• Etkin filtre ekranda yazıyla görünüyor.
• Grafikler renk olmadan da okunuyor.
• Telefonda kartlar öncelik sırasıyla alt alta diziliyor.

Son kontrolü gerçek kullanıcıyla yaparım. Panelin asıl sorusunu sorar, cevabı ne kadar sürede bulduğuna bakarım. Bunu nasıl kurduğumu kullanılabilirlik testi rehberinde anlattım.

Benim notum

Bir dashboard'un iyi olup olmadığını anlamak için tek bir test kullanıyorum. Ekrana bakan kişiye asıl sorusunu sorarım ve cevabı kaç saniyede bulduğunu sayarım. Süre uzunsa sorun neredeyse her zaman fazlalıktır.

Ekipler kart eklemeyi kolay, kart çıkarmayı zor bulur. Her kartın bir sahibi vardır ve kimse kendi metriğinin silinmesini istemez. Bu yüzden silmek yerine taşımayı öneririm: ayrıntı bir alt sayfaya gider, ana ekranda karar kalır.

Bir de şunu isterim: dashboard'u tasarım dosyasındaki temiz veriyle değil, gerçek ve dağınık veriyle çizin. Uzun bir bölge adı, sıfır değer ya da eksik bir ay ekranı bozuyorsa, bunu yayından önce görmek istersiniz.