Dashboard özgürlüğü neden her zaman iyi UX değildir?

Ürün tasarlarken kulağa neredeyse her zaman iyi gelen bazı fikirler vardır. Bunlardan biri: kullanıcı istediği gibi özelleştirebilsin.

Mantıklı. Hatta kullanıcı dostu gibi görünüyor. Kartları taşısın, boyutlarını değiştirsin, dashboard’u istediği gibi kursun, widget eklesin, widget çıkarsın, sütun sayısını değiştirsin, kendi sistemini yaratsın. Sonuçta herkes farklı çalışıyor, değil mi?

Ben de uzun süre buna yakındım. Ordovia’nın günlük komuta merkezini tasarlarken kullanıcının dashboard üzerinde ciddi özgürlüğe sahip olması gerektiğini düşünüyordum. Sonra temel bir problem fark ettim: dağınıklığı azaltmak için geliştirdiğimiz ürün, kullanıcıya kendi dağınıklığını tasarlama aracı vermeye başlıyordu.

1const designPrinciple = "freedom within constraints";

Kısıtların içinde özgürlük.

Ordovia’nın çözmeye çalıştığı problem ne?

Ordovia’yı yalnızca bir yapılacaklar listesi olarak düşünmüyorum. Temel amaç, dağınık çalışan bir insanın gün boyunca neye odaklanması gerektiğini daha görünür hale getirmek.

• görevler
• alışkanlıklar
• notlar
• projeler
• takvim
• günlük odak
• kişisel bilgi

Bunların hepsini yalnızca tek uygulamaya koymak problemi çözmüyor. Çünkü tek uygulamanın içinde de kaos yaratabilirsiniz. Asıl problem bilgi depolamak değil; doğru bilgiyi doğru anda göstermek.

Bir üretkenlik sisteminin değeri, ne kadar çok bilgiyi tuttuğundan çok, doğru anda ne kadar az şey gösterdiğiyle ilgilidir.

İlk cazip fikir: tamamen özelleştirilebilir dashboard

Teoride tamamen özgür bir dashboard çok çekici. Kullanıcı kartları taşıyabilir, yeniden boyutlandırabilir ve kendi düzenini kaydedebilir.

1interface DashboardCard {2  id: string;3  x: number;4  y: number;5  width: number;6  height: number;7}8
9move(card);10resize(card);11hide(card);12show(card);13saveLayout();

Teknik açıdan yapılabilir. Ürün demosunda da etkileyici görünür. Ama ürün tasarımında tehlikeli bir soru var: yapabiliyor olmamız, yapmamız gerektiği anlamına geliyor mu?

Özelleştirme bedava değildir

Kullanıcıya bir seçenek verdiğinizde yalnızca özgürlük vermiyorsunuz; bir karar da veriyorsunuz. Bu kart nerede olmalı? Büyük mü küçük mü? Bu kart gerekli mi? Bugün görünmeli mi? Her seçenek küçük görünür ama toplamda yeni bir zihinsel yük üretir.

1userFreedom = capability - decisionCost;

Sınırsız capability her zaman daha fazla gerçek özgürlük üretmiyor. Çünkü decision cost da büyüyor. Özellikle zihinsel yükü azaltmayı vaat eden bir üründe bu maliyet tasarımın merkezinde olmalı.

Dashboard yönetmek yeni bir iş haline gelebilir

Esnek araçların büyük avantajı, çok farklı çalışma biçimlerine uyabilmeleri. Aynı esneklik bazı kullanıcılar için problemin kendisine dönüşebiliyor. Bir noktada kullanıcı artık işini yönetmek yerine çalışma sistemini yönetmeye başlıyor.

1Bugün ne yapmalıyım?2        ↓3Dashboard'umu nasıl düzenlemeliyim?4        ↓5Yeni template deneyeyim.6        ↓7Bu görünümü biraz daha değiştireyim.

Bir saat sonra productivity sistemi daha iyi görünebilir ama gerçek iş hâlâ yapılmamış olabilir. Ordovia’nın bunu teşvik etmesini istemiyorum.

Özellikle dikkat problemi yaşayan kullanıcılar için

Ordovia’nın önemli kullanıcı gruplarından biri odağını sürdürmekte, öncelik seçmekte ve farklı sorumluluklar arasında geçiş yapmakta zorlanan insanlar. Bu kullanıcı için dashboard’un görevi seçenek üretmek değil, seçenekleri anlamlı biçimde azaltmak.

Bir ekran açıldığında 17 eşit önemde kart görüyorsanız tasarım aslında hiçbir şeye öncelik vermemiştir.

1if (everything.priority === "high") {2  nothing.priority = "high";3}

Günlük komuta merkezinin bir hiyerarşisi olmalı. Kullanıcının her sabah bu hiyerarşiyi yeniden kurmasını istemek, ürünün çözmesi gereken problemi tekrar kullanıcıya vermektir.

Sabit olmak ile katı olmak aynı şey değil

Diğer uç da yanlış. Bütün kullanıcılara tamamen aynı dashboard’u verirsek sistem kullanıcı için değil, kullanıcı sistem için çalışmaya başlar. Bir kullanıcı alışkanlık modülünü kullanmıyor olabilir. Başka biri takvimi yoğun kullanabilir. Bir başkası notları günlük ekranında görmek istemeyebilir.

Çözüm tamamen sabit bir yapı değil. Aynı şekilde tamamen özgür bir yapı da değil. Arada üçüncü bir model var: sistem hiyerarşiyi belirler, kullanıcı görünürlüğü seçer.

Seçilebilir ama taşınamaz kartlar

Ordovia için vardığımız model kabaca şöyle:

1interface CommandCenterCard {2  id: string;3  approved: true;4  visible: boolean;5  position: "system-defined";6  movable: false;7  resizable: false;8}

Kullanıcı hangi onaylı kartların görünmesini istediğini seçebilir.

1setVisible("habits", false);2setVisible("calendar", true);3setVisible("notes", true);

Ama ürünün bilgi mimarisini yeniden tasarlamaz. Kartları serbestçe taşıyamaz, resize edemez ve keyfi bir dashboard layout’u oluşturamaz. Kullanıcı ne görmek istediğini seçer; sistem bunun nerede ve hangi hiyerarşide gösterileceğini belirler.

Dashboard builder değil, filtre

Bu ayrım için kullandığım zihinsel model dashboard builder değil, filtre. Dashboard builder dediğinizde kullanıcı “sistemimi tasarlıyorum” diye düşünür. Filtre dediğinizde “şu anda bana yararlı olanları gösteriyorum” der. İkinci model çok daha hafif.

1const visibleCards = {2  focus: true,3  tasks: true,4  habits: true,5  calendar: true,6  notes: false,7  library: false,8};

Kullanıcının grid koordinatlarını, kart ölçülerini veya breakpoint davranışlarını yönetmesine gerek yok. Özelleştirme ürün kullanımı sırasında doğal bir filtreleme davranışına dönüşüyor.

Desktop’ta neden üç sütun?

Web ve desktop için üç sütunlu grid benimsememizin nedeni yalnızca ekran genişliğini doldurmak değil. Üç sütun doğal bir bilgi hiyerarşisi yaratıyor: yön ve odak, bugünün işi, bağlam ve destek.

1const desktopHierarchy = {2  left: "orientation",3  center: "execution",4  right: "context",5};

Bu her pikselde katı bir kural olmak zorunda değil. Ama ekranın temel ritmini belirliyor. Böylece komuta merkezi yalnızca kart koleksiyonu olmaktan çıkıp anlaşılır bir akış kazanıyor.

Neden timeline omurgasından vazgeçtik?

Bir ara günlük komuta merkezinde dikey bir kılavuz veya timeline omurgası fikrini değerlendirdik. Görsel olarak güçlüydü ama ürün modelini gereğinden fazla zaman çizgisine bağlıyordu. Timeline “gün saatlerden oluşur” mesajı veriyor. Oysa her görev saat bazlı değil, her alışkanlık takvim etkinliği değil, her not zaman çizgisine ait değil.

Grid bu açıdan daha nötr. Farklı bilgi türlerini tek bir hiyerarşi içinde tutuyor ama hepsini aynı zaman metaforuna zorlamıyor.

Mobilde desktop grid’ini küçültmek neden yanlış?

Responsive tasarımda klasik hata desktop tasarımı daraltıp mobile demek. Üç sütunlu komuta merkezini telefonda tek sütuna çevirmek tek başına yeterli değil. Çünkü mobilde temel problem alan değil, dikkat.

Desktop’ta kullanıcı aynı anda daha fazla bağlam görebilir. Mobilde ise sıra ayrı bir ürün kararı olmalı; CSS grid’in doğal wrap sonucu olmamalı.

1const mobilePriority = [2  "todayFocus",3  "criticalTasks",4  "habits",5  "schedule",6  "supportingContext",7];

Bu sıralama kullanıcının küçük ekranda neyi önce görmesi gerektiğini ürün seviyesinde tanımlar. Mobil deneyim desktop’ın sıkıştırılmış hali değil, aynı sistemin daha dar dikkat bütçesine uyarlanmış halidir.

Kısıt neden bazen güven verir?

İyi tasarlanmış bir ürün kullanıcıya “bunun nasıl çalışacağını benim çözmeme gerek yok” hissini verir. Bir kamera uygulamasını açtığınızda önce sensör ayarlarını, bir navigasyon uygulamasını açtığınızda harita render algoritmasını seçmek istemezsiniz. Productivity sisteminde de her kullanıcının kendi bilgi mimarisini tasarlaması gerekmemeli.

1bad constraint → frustration2good constraint → relief

İyi kısıtlar kullanıcıdan iş alır. Kötü kısıtlar ise kullanıcıyı ürünün varsayımlarına mahkûm eder. Tasarımın işi bu ikisi arasındaki çizgiyi doğru kurmaktır.

Kullanıcıların farklı olduğunu yine de kabul etmek gerekiyor

Kısıtların içinde özgürlük modelinin ikinci yarısı burada. Bir kullanıcı için günlük ekran Focus, Tasks ve Calendar olabilir. Başka biri Focus, Habits, Tasks ve Notes isteyebilir. İki durumda da sistem aynı ürün olmaya devam eder.

Dashboard farklılaşır ama bilgi mimarisi parçalanmaz. Kullanıcı sistemi kişiselleştirir; ürünü yeniden tasarlamaz.

Teknik avantaj: support ve test yüzeyi küçülüyor

Tamamen customizable dashboard yalnızca UX karmaşıklığı yaratmıyor. Teknik ve operasyonel karmaşıklık da yaratıyor. “Takvim kartım görünmüyor” gibi bir bug’da hangi layout, hangi sütun, hangi boyut, hangi custom configuration ve hangi breakpoint kullanıldığını anlamanız gerekir.

Kısıtlı sistemde state yüzeyi çok daha küçük.

1type CardState = "visible" | "hidden";

Daha az edge case, daha az test kombinasyonu, daha az layout corruption, daha kolay migration ve daha güvenilir mobil davranış. Bunlar görünmez teknik ayrıntılar gibi duruyor ama sonunda ürün kalitesine geri dönüyor.

Power user itirazı

Doğal itiraz şu: “Ben power user’ım. Neden istediğim gibi düzenleyemiyorum?” Geçerli bir soru. Ama her ürün herkese maksimum esneklik sunmak zorunda değil. Bir ürünün görüşü olabilir.

Ordovia’nın günlük komuta merkezi sürekli tasarlanan bir alan değil, kullanılan bir alan olmalı.

Power user için derin özelleştirme filtrelerde, etiketlerde, proje yapısında, kayıt yöntemlerinde veya otomasyonlarda olabilir. Ana günlük akışın kendisinin stabil kalması ise sistemin karakterini korur.

Daha büyük ürün prensibi: daha fazla seçenek her zaman daha iyi ürün değildir

Modern yazılımda sık kullanılan varsayım daha fazla seçeneğin daha iyi ürün anlamına geldiği. Ben buna giderek daha az inanıyorum. Bazen daha iyi ürün, daha az karar demek.

1more options ≠ better product2fewer unnecessary decisions = better flow

Bir productivity uygulamasının başarı metriği kullanıcının dashboard’u ne kadar detaylı özelleştirdiği olmamalı. Daha önemli soru şu: kullanıcı yapması gereken şeyi daha kolay yaptı mı?

Bir özelleştirme kararını test etmek için kullandığım soru

Bu seçenek kullanıcının gerçek işini yapmasını mı kolaylaştırıyor, yoksa ürünü yönetmesini mi?

“Alışkanlıklar kartını gizle” gerçek işi kolaylaştırabilir. “Alışkanlıklar kartının border radius’unu seç” büyük olasılıkla ürün yönetimidir. Aradaki çizgi her zaman bu kadar net değil ama soru iyi bir filtre.

Kısıtlar yaratıcılığın düşmanı değil

Bu prensip yalnızca UX için değil, ürün geliştirme için de değerli. “Her şeyi yapabiliriz” kulağa güçlü geliyor ama ürün açısından korkunç bir başlangıç noktası olabilir. İyi constraint ürünün hangi problemi hangi şekilde çözeceğini söyler ve geri kalan onlarca ihtimali bilinçli biçimde reddeder.

Ordovia’nın komuta merkezi kararı bunun küçük ama önemli bir örneği. Serbest dashboard geliştirmek teknik olarak mümkün. Yapmamak ise bilinçli ürün kararı.

Sonuç

Kullanıcı özgürlüğüne karşı değilim. Ama özgürlük ile sorumluluğu kullanıcıya devretmeyi aynı şey olarak görmüyorum. Eğer kullanıcıya “istediğin sistemi kendin kur” diyorsak bazen aslında “biz doğru sistemi tasarlamaya karar vermedik” diyor olabiliriz.

Ordovia’da farklı bir yol tercih ediyorum. Sistem temel hiyerarşiyi belirliyor. Kullanıcı ihtiyaç duymadığı şeyleri çıkarıyor. Ama her sabah kendi productivity sistemini yeniden tasarlamak zorunda kalmıyor.

1const ordovia = {2  structure: "fixed",3  visibility: "personal",4  chaos: "optional",5};

İyi bir günlük komuta merkezinin amacı kullanıcıya daha fazla kontrol paneli vermek değil, kontrol etmek zorunda olduğu şeylerin sayısını azaltmaktır.