UX LEAD VAKA ÇALIŞMASI · KARAR SİSTEMLERİ · OLAY OPERASYONLARI
Fintech on-call için karar yetkisinin yeniden tasarımı. Triyaj süresi yarıya indi. Mühendislik ve hukuk aynı modeli kabul etti.
Baskı Altında
Karar Yetkisi
Yüksek riskli SaaS olay operasyonlarında kim, ne zaman karar verir — bunu yeniden tasarladım.
DOMAIN
Fintech
ROLE
UX Lead
YEAR
2025
STATUS
Yayında
02:47 — Kimsenin Vermek İstemediği Karar
Saat 02:47. Ödeme gateway'inde "Latency Degraded" alarmı çalıyor. Nöbetçi mühendis yalnız. Müşteri hizmetlerinden ses yok — henüz ticket gelmemiş. Ama dashboard yanıt sürelerinde %12 sapma gösteriyor — otomatik paging eşiğinin hemen altında.
Mühendis seçmek zorunda. — Eskale et, olası veri kaybını engelle ama yanlış alarm riski al. — Sus, ekibi yorgunluktan koru ama gerçek bir kesinti riski al. Sistem, bir insanın yetersiz veriyle belirsiz bir sinyali çözmesini istiyor.
TL;DR
- Problem:Dağıtık doğru + belirsiz yetki = sabah 3'te karar felci.
- Çözüm:Triyaj sırasında log'u susturan bir konsol + risk bazlı eskalasyon yetkisi.
- Ana içgörü:Affordance ≠ izin. Veriyi gizlemek paranoya değil, özen olabilir.
Process
TIMELINE — Çok aylı süreç — tasarım, sonra yayına alma
STAKEHOLDERS
- — Yönetim sponsoru
- — Mühendislik liderliği (önce karşı, sonra savunucu)
- — Etkilenen takımdan günlük kullanıcılar
- — Nöbet rotasyon lideri — doğrulama partneri
- — Alt-süreç operasyonu paydaşı
- — Compliance / regülasyon danışmanı
DECISION POINTS — 3 CRITICAL
- Triyaj sırasında ham logları gizle — önce tartışmalıydı, veri ile doğrulandı
- Yetki tier'ı risk bazlı, kıdem bazlı değil — org şeması risk yüzeyiyle örtüşmüyordu
- Dispute ve postmortem akışını birleştir — dispute ile otomatik tetiklenir
Asıl Problem
Olay yönetimi genelde ChatOps'a indirgeniyor — bir alet sorunu olarak. Ama aletler asıl çatışmayı çözemez: dağıtık doğru. Metrikler, müşteri raporları ve mühendislik logları birbiriyle uyuşmazsa, sistem insanın baskı altında gerçekliği bir araya getirmesini ister. Bu imkansız bir bilişsel yük.
Nöbetçi mühendisin sabah 3'teki gerçek işi olayı çözmek değil. Bu olayın ne tür olduğuna karar vermek — ve bu karar üzerine kimin harekete geçme yetkisi olduğunu bilmek.
Decisions
ADOPTED
- Triyaj sırasında ham loglar gizli (incelemede açılır)
- Bağlam bazlı yetki tier'ı (risk × müşteriye dönük × veri bütünlüğü)
- Dispute / postmortem birleşik, paydaşlar otomatik eklenir
- İki binary karar sorusu sadece triyaj fazında görünür
- Yetki tier'ı Postgres row-level policy olarak da yansıtılır — UI ve backend aynı model
REJECTED
- Daha iyi log filtreleme — yamalama, kök sebebi çözmez
- Kıdem bazlı eskalasyon listesi — bağlam riskini kaçırır
- Ayrı dispute ve postmortem akışları — yineleme
- Daha düşük eşikte otomatik paging — yorgunluk sarmalı
Görsel Akış
Üç hi-fi ekran, scroll'a göre. Her adım = sistemin sıradaki durumu.
Alarm dashboard
İlk yüzey — alarm önceliği, müşteri etkisi, karar tier'ı ipucu. Desktop'ta mühendis satırı tarar; mobile'da aktif olay ekranı kaplar, diğerleri katlanır.
Desktop · 1280+
Mobile · 375
Desktop her alarm için 3-kolonlu meta strip kullanır; mobile baskın bir kart + katlanmış kardeşlere döner. Nöbetçi mühendisin cep görünümü liste değil karar odaklı — bildirimden triyaja tek dokunuş.
Triyaj konsolu — loglar gizli
Triyaj sırasında ham loglar katlanmış. Desktop'ta iki binary soru aynı anda görünür; mobile'da sırayla — ekranın kısıtı bilişsel adımın da kısıtı.
Desktop · 1280+
Mobile · 375
Desktop iki soruyu yan yana gösterir (deneyimli operatöre hızlı). Mobile 1-of-2 wizard'a böler progress dotları ile — soru başına yavaş ama daha odaklı. İkisi de aynı şekilde kayıt eder; sadece ritim farklı.
Karar yetkisi tier'ı
Neden önemli: sabah 3'te net yetki yoksa eskalasyon politik bir mesele olur. Matrix kararı tartışılmaz hale getirir — risk bazlı, kıdem bazlı değil — ve row-level Postgres policy ile denetlenir.
Ekipten sesler
“Logları gizlemeye karşı çıkmıştım. Sonra triyaj süresinin düştüğünü gördüm.”
“İlk defa nöbet bana göre tasarlanmış gibi hissettim.”
“Sistem benden kahraman olmamı istemekten vazgeçti.”
Etki
My Role
KEŞİF
12 paydaş mülakatı, 30+ ticket retrospektifi, nöbet gözlem.
TANIM
Nesne modeli, durum makinesi, karar yetkisi tier taksonomisi.
TASARIM
Wireframe → hi-fi → triyaj geçişleri için motion grameri.
TESLİM
Eng takımıyla 4 hafta günlük standup, XState handoff.
YAYIN SONRASI
90 günlük ölçüm, tier-4 üzerinde iterasyon (kaldırıldı).
Reflection
What I'd do differently
Dört karar yetkisi tier'ı yayına aldık — pilotda ikisi hiç ateşlenmedi. Şimdi geriye dönüp bakınca, iki tier ile başlayıp üçüncüyü veriyle kazanmalıydık. Tasarımcının karmaşıklık önyargısı: doğru taksonomiyi sezgiyle değil kanıtla seçmek. Artık her durum modeline minimum viable taksonomi ile başlıyoruz.
Behind the scenes · for engineering readers
Karar tier taksonomisi dört sinyalden hesaplandı: bağlam riski × müşteriye dönük × veri bütünlüğü × günün saati. Durum makinesi XState ile modellendi, mühendislik takımı üretilen state-chart'ı UI dokümanına direkt yapıştırdı. Yetki tier'ı Postgres row-level policy olarak da yansıtıldı — herhangi bir non-UI yüzey (CLI, dahili script) aynı izin modelini devralır.
Tech stack: XState · TypeScript · Postgres RLS · Datadog incident integration
Bigger picture
Yetki için tasarlamak, belirsizliğin rahatlığını kaldırmak demek. Ekibi kendi bozuk süreçleriyle yüzleşmeye zorluyor. Bu sistem sadece UI'ı temizlemedi; olay yönetiminin politik güç dinamiklerini de açığa çıkardı ve düzeltti.