Geçen ay bir sabah, İstanbul’da otobüs beklerken Ola web arayüzüne göz atıyordum ve açık konuşayım — ilk hissettiğim şey tam anlamıyla “bu kadar mı?” oldu. Harita var, çalışıyor, rota görünüyor… ama ekranın minicik bir köşesine sıkıştırılmış halde. Ne tam açma düğmesi var, ne de insanı rahatlatacak bir büyütme seçeneği. Hani yazılım dünyasında bazen en sinir bozucu şey sistem çökmesi değildir ya — bazı şeyler tam da öyle, sessizce rahatsız eder.
Ben bu tür şeylere yıllardır takılırım. 2023’te kendi küçük yan projemde benzer bir durum yaşamıştım; panelde her şey düzgün görünüyordu. Kullanıcılar kritik bilgiyi görmek için sürekli kaydırmak zorunda kalıyordu. Teknik olarak sistem çalışıyordu, evet — — itiraz edebilirsiniz tabi — ama kullanım hissi? Biraz hırpalanmıştı. Ola örneği de bana tam bunu hatırlattı: küçük görünen UX boşlukları, nasıl oluyor da üretime bu kadar rahat sızıyor?
Neden Bu Kadar Can Sıkıyor?
İşin aslı şu: harita gibi temel bir bileşen dar alana sıkışınca kullanıcı zihninde gereksiz bir sürtünme noktası oluşuyor. Navigasyon, teslimat ya da araç çağırma gibi akışlarda harita sadece dekoratif bir süs değil; aksine doğrudan karar verme yüzeyi. Kullanıcı rotayı okumak istiyor, yaklaşan aracın nerede olduğunu görmek istiyor, belki çevredeki yoğunluğu anlamaya çalışıyor —. Ekranın yarısı boşa gidiyorsa o deneyim tökezliyor, basit.
Bir de şu var. İnsanlar çoğu zaman bu eksikliği hemen net biçimde tarif edemiyor. “Burası kötü” demiyorlar; sadece uygulamayı daha az kullanmaya başlıyorlar. Ben bunu 2024’te Kadıköy’de bir ürün demosunda birebir gördüm — test grubundaki biri hiçbir hata mesajı almadan uygulamayı kapattı ve “işimi kolaylaştırmıyor” dedi. Cümle kısa, etkisi büyük. Çünkü bazı problemler alarm çalmaz; usulca moral bozar işte.
Hani, Bu yüzden küçücük bir harita alanı bana göre teknik kusurdan çok tasarım körlüğü kokuyor. Tasarımcı kötü iş çıkarmış demiyorum ha — bazen ekran hiyerarşisi, bazen ürün öncelikleri, bazen de o meşhur “bunu sonra hallederiz” yaklaşımı oluyor mesele. Sonra o küçük erteleme üretimde kalıcılaşıyor. Hep böyle olur.
Şimdi gelelim işin can alıcı noktasına.
Kullanıcı neden hemen vazgeçiyor?
Çünkü iyi deneyim görünmezdir; kötü deneyim ise parmak ucuna batıyor gibi hissedilir. Haritayı genişletmek için uğraşmak zorunda kalan kullanıcı, farkında olmadan zihninde ekstra yük taşıyor. Bir tık daha, bir sürükleme daha… Bunlar tek tek bakınca önemsiz görünüyor, toplamda ise bayağı yorucu.
Bu tarz sürtünmeler özellikle mobil-web karışımı yapılarda çok daha belirgin hale geliyor. Ekran alanı zaten kısıtlıysa ve üst üste binmiş katmanlar söz konusuysa, ana işi yapan alan ister istemez küçülüyor. O anda ürün ekibi “ama fonksiyon çalışıyor” diyebilir… evet, çalışıyor — ama insanlar bununla ne kadar yaşayacak, göreceğiz.
Küçük Bir Bookmarklet’in Büyük Dersi
Bak şimdi, Ben böyle vakalarda önce şunu yapıyorum: çözülebilecek mi diye bakıyorum, ardından çözümü mümkün olan en küçük müdahaleyle test etmeye çalışıyorum. Bu olayda bookmarklet fikri tam buraya oturuyor. Yani tarayıcıya kurulan ağır eklentiler yok, izin karmaşası yok, kurulum derdi yok; sayfaya ufak bir betik enjekte edip işi yoluna koyuyorsun.
Editör masasında bu haberi okurken aklıma direkt eski bir Chrome denemem geldi — 2022’nin sonlarında ofiste kahve soğurken benzer biçimde DOM manipülasyonu ile birkaç iç araç düzeltmiştik (evet, bayağı yamalı bohça gibiydi o günler). Ama işe yaramıştı! Bookmarklet mantığı da biraz böyle: geçici ama etkili bir pansuman.
“Bazen ürünün tamamını yeniden yapmak gerekmez; ekranda tek bir alanı doğru boyuta getirmek bile kullanıcıyı geri kazanır.”
Şunu söyleyeyim, Yine de burada romantize edecek bir şey yok. Bookmarklet çözümü güzel ama ham kalabiliyor — kalıcı ürün çözümü yerine bana kalırsa geçmez. Kullanıcı tarafında işe yarar, tamam. Ama ekip tarafında “tamamdır” diye dosyayı kapatmak da yanlış olurdu. Çünkü asıl soru hâlâ ortada duruyor: Neden bu ihtiyaç ilk günden düşünülmedi?
Neden bookmarklet mantıklı?
- Kurulum istemiyor.
- Tarayıcı içinde anında çalışıyor.
- Ana uygulamaya dokunmadan deneme yapmayı sağlıyor. — bunu es geçmeyin
- Kullanıcının eline hızlı kontrol veriyor.
Aşağıdaki mini örnek de mantığın özünü gayet iyi gösteriyor aslında; basit bir DOM güncellemesiyle alanı büyütüp geri kapatabiliyorsun:
(function () {
const btn = document.createElement('button');
btn.textContent = 'Haritayı Genişlet';
btn.style.cssText = 'position:fixed;top:16px;right:16px;z-index:99999;';
document.body.appendChild(btn);
let expanded = false;
btn.onclick = () => {
const map = document.querySelector('.map-container');
if (!map) return;
expanded = !expanded;
map.style.width = expanded ? '100vw' : '';
map.style.height = expanded ? '100vh' : '';
map.style.position = expanded ? 'fixed' : '';
map.style.inset = expanded ? '0' : '';
btn.textContent = expanded ? 'Geri Al' : 'Haritayı Genişlet';
};
})();Neden Bu Tür Sorunlar Prod’a Kaçar?
Burada biraz dürüst olalım. Prod’a kaçan her küçük UX problemi için suçlu aramak kolaydır ama gerçek hayat öyle düz değil. Ürün takvimi baskı yapar, sprint biterken ekip çekirdek akışı bitirmeye odaklanır ve kenarda kalan konfor detayları geriye düşer. Mesela ödeme ekranı kusursuz olsun istenir ama harita panelinin rahatlığı ertelenir. Hep aynı hikâye.
Gel gelelim sorun şu ki kullanıcı açısından bu ikisi birbirinden kopuk değildir. Bir startup’ta çalışan arkadaşım geçen sene bana şunu söylemişti: “Biz feature yetiştiriyoruz diye kimseyi kırmıyoruz sanıyorduk… meğer sessiz sessiz kaçıyorlarmış.” Haklıydı tabi. Çünkü analitik paneller patlayan hataları gösterir ama sinir bozucu yarım çözümleri pek bağırmaz.
Bir dakika — bununla bitmedi. Masa Üstünde Kaymayan MagSafe: Vakumlu Çözüm İşe Yarıyor mu? yazımızda bu konuya da değinmiştik.
| Sorun tipi | Yakalanma ihtimali | Kullanıcı etkisi |
|---|---|---|
| Uygulama çökmesi | Yüksek | Anında fark edilir |
| Düğmenin yanlış çalışması | Orta-yüksek | Açıkça şikâyet edilir |
| Sıkışık harita / dar alan | Düşük | Sessizce rahatsız eder |
| Birkaç tıklama fazlalığı | Düşük-orta | Zamanla terk ettirir |
Bence en tehlikeli kategori de bu son satırlar zaten. Alarm vermeyen problemlere ekipler refleks geliştiremiyor. Oysa ölçülemeyen sürtünme diye ayrı bir mesele var — ve bayağı gerçek (en azından benim deneyimim böyle) Daha fazla bilgi için Apache Arrow Neden Önemli: Veri Taşımanın Gizli Vergisi yazımıza bakabilirsiniz. Bu konuyla ilgili Akıllı Telefon Serileri Neden Dağılıyor?: Android’de Büyük Düzeltme yazımıza da göz atmanızı tavsiye ederim.
Küçük startup ile enterprise aynı mı davranmalı?
Küçük startup tarafında hız baskısı yüksek olduğu için bazı pürüzler anlayışla karşılanabilir; tamamdır, ilk sürüm çıkarılır, sonra cilalanır denir. Ama enterprise tarafta işler farklıdır — kullanım ölçeği büyüdükçe o küçük eksiklik binlerce kişiye yayılır. Bir bankanın işlem ekranındaki minicik tasarım sorunu ile yeni kurulan iki kişilik girişimin ara sıra yaşadığı konfor eksikliğini aynı kefeye koyamazsın.
Yine de mazeretlerin bir sınırı olmalı. Eğer özellik kritikse — mesela harita üzerinden canlı yönlendirme — o zaman “sonra düzeltiriz” cümlesi biraz fazla rahat kaçıyor. Açıkçası.
Tasarım ile Gerçek Hayat Arasındaki Boşluk
Bilmem anlatabiliyor muyum, Ürün mockup’ları çoğu zaman steril görünür. Gerçek kullanım ise öyle değildir. Kullanıcının parmağı kayar, tarayıcı pencere boyutu değişir, sayfaya reklam bandı girer ya da sistem dili farklılaşır — bunların hepsi tabloyu değiştiriyor (ben de ilk duyduğumda şaşırmıştım). Ben bunu ilk kez masaüstü QA sürecinde çok net fark etmiştim; Fenerbahçe civarında yapılan dahili testte herkes dizüstünde mutlu görünüyordu. Dışarıda güneşte telefondan açınca aynı ekran adeta büzüşmüştü.
Ha, bu arada şunu da ekleyeyim: tasarım dosyasının temiz olması bizi kandırmamalı. Figma’da nefis duran yapı gerçek kullanıcıda bazen hafif sakil duruyor (ben de ilk duyduğumda şaşırmıştım). Bakın şimdi burada mesele estetikten çok mekân yönetimi — haritanın kullanılabilir kısmını daraltırsanız kullanıcıya aslında şunu demiş oluyorsunuz: “Evet bakabilirsin. Rahat etmen şart değil.” Bu da iyi hissettirmiyor işte.
Peki Böyle Şeyleri Nasıl Azaltırız?
Lafı gevelemeden söyleyeyim: her şeyi sıfırlayamazsınız ama riski ciddi biçimde düşürebilirsiniz. Ben kendi projelerimde artık üç şeyi rutin hale getiriyorum — ekran boyutu testi, hızlı kalite kontrol turu ve birkaç gerçek kullanıcı senaryosu simülasyonu. Bunlar pahalı şeyler değil; sadece disiplin istiyor.
Birkaç pratik alışkanlık:
- Kritik akışlarda farklı ekran ölçülerini mutlaka test edin.
- Ekranın ana görevini yapan bileşeni gizlemeyin ya da sıkıştırmayın.
- Kullanıcıdan gelen “ufak rahatsızlık” geri bildirimlerini not alın.
- Tasarımı sadece mockup olarak değil canlı kullanım olarak değerlendirin.
İnanın, Açık konuşayım, bazı ekipler bunu lüks sanıyor ama değil yani. Mesela SaaS tarafında küçük UX iyileştirmeleri dönüşümü artırabiliyor veya destek taleplerini azaltabiliyor — görünmeyen kazançların en sevilen hali bu. Geçen yıl Maslak’taki bir müşteri toplantısında buna benzer ufak düzenlemelerin destek yükünü %18 azalttığını duymuştum; inanması kolay değildi. Metrik yalan söylemiyordu.
Benden Kalan Notlar
Bu hikâyede beni asıl düşündüren şey bookmarklet’in kendisi değildi doğrusu. Asıl mesele şu: küçücük görünen tasarım açıkları nasıl oluyor da bu kadar uzun süre yaşamaya devam ediyor? Ve açıkçası bu soru hâlâ güncel.
Bir dakika — bununla bitmedi. Veri Etiketleme Altın Madeni: Handshake ve Mercor Patlaması yazımızda da bu konuya değinmiştik. Pixel Referral Program Geri Döndü: 10% İndirim, 50$ Kredi yazımızda da bu konuya değinmiştik.
Bir ürün teknik olarak sağlam olabilir ama deneyim tarafında çatlak veriyorsa kullanıcı onu yine zayıf hatırlar. Bunun tersine de çok rastladım — iyi düşünülmüş mikro etkileşimlerin insanları ürüne nasıl bağladığını bizzat gördüm. Ciddi fark var.
Bakın, Özetle, haritanın dar olması sadece dar alan meselesi değil; önceliklerin nerede durduğunu gösteren minik bir ayna gibi. E tabi, her şirketin kaynağı sınırsız değil (yanlış duymadınız). Ama bazen gerçekten tek gereken şey şu soruyu sormak: “Bunu biz kullansak hoşumuza gider mi?”
İnanın, Cevap hayırsa… orada durup tekrar bakmak gerekiyor.
Sıkça Sorulan Sorular
Bookmarklet nedir?
Bookmarklet, tarayıcı yer imine kaydedilen küçük JavaScript kodudur. Tek tıklamayla sayfadaki davranışı değiştirebilir veya sayfaya ufak araçlar ekleyebilir.
Küçük UX sorunları neden önemli?
Çünkü çoğu zaman hata üretmezler ama kullanıcıyı yorarlar. Bu tür sürtünmeler sessizce terk oranını artırabilir ve destek yükünü yükseltebilir.
Böyle sorunlar QA aşamasında neden yakalanmaz?
Bazen test senaryoları yalnızca işlevselliğe odaklanır.Konfor seviyesi ya da görsel hiyerarşi ikinci plana atılınca dar alan gibi problemler gözden kaçabilir.
Küçük ekipler bu tip UX iyileştirmelerine nasıl yaklaşmalı?
Kritik akışları önceleyip hızlı prototiplerle deneme yapmak iyi başlangıçtır.Her şeyi mükemmel yapmak zorunda değilsiniz; önemli olan en can sıkan noktaları erken görmek.
Kaynaklar ve İleri Okuma
Ola Web Bookmarklet GitHub Sayfası
MDN — Document Object Model (DOM)
MDN — WebExtension Temelleri ve Mimari Notları
Tuhaf ama, Nielsen Norman Group — UX Friction Yazıları
>
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
