Azure Boards’ta Markdown Düzenleyici Neden Daha Sakin Oldu?

⏱️ 6 dk okuma📅 5 Nisan 2026👁️ 4 görüntülenme

Bak şimdi, Geçen hafta bir müşteride, Azure Boards içindeki uzun açıklamaları okurken istemeden edit moduna düşme meselesi yüzünden ekip bayağı sinirlenmişti. Hani “sadece bakacaktım” diyorsun, bir anda alan düzenlenmeye başlıyor… iş akışı da orada çat diye kırılıyor. İşte Microsoft’un son dokunuşu tam bu can sıkıcı noktaya el atıyor.

İşin aslı şu ki, Markdown desteği work item alanlarına geldiğinden beri güzel şeyler oldu. Kullanım tarafında ufak bir sürtünme vardı. Ben AZ-104 ve AZ-305 hazırlıkları sırasında bile kendi notlarımı Azure Boards’a benzer yapılarda tuttuğum için bu tip küçük kullanıcı deneyimi detaylarının ne kadar önemli olduğunu çok net gördüm. Kağıt üstünde minik bir fark gibi duruyor; pratikte işe insanın gününü değiştiriyor.

Durun, bir saniye.

Asıl problem neydi?

İlginç olan şu ki, Markdown editör ilk çıktığında amaç belliydi: büyük metin alanlarında daha okunur. Düzenli içerik sunmak. Fena fikir değildi, hatta bayağı işe yarar bir adım oldu. Ama kullanıcıların çoğu aynı şeyi söyledi: Okumak isterken yanlışlıkla düzenleme moduna girmek gereksiz yere dikkat dağıtıyordu.

Mesela de çift tıklama gibi alışkanlıklarla edit moda geçmek, bazı senaryolarda “niye şimdi yazmaya başladı bu alan?” hissi veriyordu (şaşırtıcı ama gerçek). Bir de düşünün, denetim yapan biri ya da proje yöneticisi sadece gereksinimleri kontrol ediyor; yanlış dokunuşla içerik değişmeye başlıyor. Küçük startup’ta belki tolere edilir ama enterprise tarafta bu iş ciddi bir güven ve izlenebilirlik konusu oluyor.

Bu tür arayüz sorunları bazen teknik borç gibi görünmez ama ekiplerin günlük ritmini bozar. Benim sahada gördüğüm şey şu: İnsanlar sistemi değil, sürprizi sevmiyor.

2019’da İstanbul’daki bir finans kurumunda buna benzer bir durum yaşamıştık. Doküman ekranı çok “zeki” davranıyordu; kullanıcı nereye tıklasa farklı mod açılıyordu. Sonuç? Destek talebi yağdı. O zaman da şunu anlamıştım: Kullanıcıya azıcık fazla akıllı davranan arayüz, bazen en pahalı hataya dönüşüyor.

Neler değişti?

Yeni yaklaşım oldukça net: Varsayılan olarak alanlar preview modunda açılıyor. Yani önce rahatça okuyorsun, inceleyebiliyorsun, kontrol ediyorsun. Düzenlemek istiyorsan da üstteki edit ikonuna basıp bilinçli şekilde edit moda geçiyorsun. Bu kadar basit… ve açık konuşayım, çoğu zaman iyi tasarım zaten budur.

Hmm, bunu nasıl anlatsamdı…

Bu değişiklik bana hep otomobildeki manuel vites hissini hatırlatıyor. İstersen aracı sürersin ama geri vitese kendiliğinden geçmez; karar sende olur. Burada da mantık aynı: Okuma ile yazma ayrılmış durumda. Az önce X dedim ama aslında Y daha doğru olabilir; burada esas kazanım hız değil, kontrol.

💡 Bilgi: Preview mode varsayılan olunca yanlışlıkla düzenleme riski azalıyor; edit icon ile bilinçli geçiş işe özellikle denetim ve onay süreçlerinde işleri toparlıyor.

Bir de çıkış kısmı var tabii. Düzenlemeyi bitirince tekrar — ki bu tartışılır — preview moda dönmek kolaylaşıyor (inanın bana). Yani ekran artık “ben seni sürekli editör sanmıyorum” diyor resmen (ve doğrusu da bu). Kâğıt üzerinde küçük görünse de günlük kullanımda bayağı rahatlatıcı. Daha fazla bilgi için Diff Satırlarını Hızlandırmak: Büyük PR’larda Sınır Nerede? yazımıza bakabilirsiniz.

Küçük ekipte etkisi

Küçük startup’larda genelde herkes her şeyi hızlıca halletmek ister. Orada bile bu güncelleme iş görüyor çünkü kimse vakit kaybetmeden not okumak istiyor; yanlışlıkla düzenlemeye girip sonra geri çıkmak kimsenin hoşuna gitmiyor. Bu konuyla ilgili Visual Studio’da Copilot Mart 2026: Ajan Devrimi yazımıza da göz atmanızı tavsiye ederim.

Hani, Bana göre küçük ekiplerde en büyük fayda şu olacak: Yeni gelen biri ekrana baktığında neyin okunur neyin düzenlenebilir olduğunu hemen anlıyor. Bu konuyla ilgili Entra External ID’de Sosyal Giriş: Native Auth GA Oldu yazımıza da göz atmanızı tavsiye ederim.

Büyük organizasyonda etkisi

Bak şimdi, Enterprise tarafta işe mesele biraz daha sertleşiyor. Onay süreçleri, denetim kayıtları, görev açıklamaları… hepsi tek yerde dönüyor ve en ufak yanlış etkileşim bile kafa karıştırabiliyor.

Logosoft’ta geçen sene bir telekom müşterisinde bunu test ederken gördük; kullanıcılar özellikle uzun incident açıklamalarını incelerken istem dışı değişikliklerden rahatsız oluyordu.

Senaryo	Eski Davranış	Yeni Davranış
Kullanıcı sadece okumak istiyor	Edit moduna yanlışlıkla girme riski var	Preview mode ile daha güvenli okuma
Düzenleme yapmak istiyor	Bazen nerede başladığı belli olmuyor	Edit ikonu ile açık ve net geçiş
Ekip inceleme yapıyor	Sürpriz etkileşimler can sıkıyor	Daha öngörülebilir deneyim sağlıyor
Büyük kurum kullanımı	Daha fazla hata ihtimali var	Daha kontrollü akış veriyor

Neden bu kadar önemli?

Neyse uzatmayalım; burada ana mesele sadece UX değil, güven hissi de var (evet, doğru duydunuz). Kullanıcı aracı her açtığında neyle karşılaşacağını biliyorsa sisteme olan güven artıyor.
Bu çok klasik gibi durabilir. Sahada klasik olan şeyler genelde en değerlisidir.

Doğrusu, Ben Azure DevOps danışmanlığı yaptığım projelerde hep şunu söylerim: “İyi araç = az sürpriz.” Mesela de DevOps kültüründe akışın kesilmemesi lazım.
Copilot ya da başka AI destekli araçlarda da aynı dersi gördük; otomasyon güzel ama nerede devreye girdiği anlaşılmalı. OpenAI Neden Bir Medya Şirketi Satın Aldı: TBPN yazımızda bu konuya da değinmiştik.

Daha az yanlış tıklama riski
Daha net okuma/düzenleme ayrımı
Daha az destek talebi
Daha yüksek kullanıcı memnuniyeti
Daha temiz iş takibi
Ekip içinde daha tutarlı kullanım

Açık konuşayım, bu tarz iyileştirmeler bazen manşete çıkmaz. Ama ürünü her gün kullanan kişi için etkisi büyüktür. Hatta bazı projelerde tam tersine “küçük” görünen düzeltmeler asıl farkı yaratır — özellikle yoğun operasyon ortamlarında.

Sahada bunu nasıl değerlendiririm?

Eğer siz de Azure Boards’u yoğun kullanıyorsanız benim önerim şu olur:
önce rollout’un tamamlanmasını bekleyin. Birkaç kritik work item türünde deneyin.
Mesela epic açıklamaları, security bug kayıtları ya da müşteri eskalasyon notları… Bunlar uzun olur ve sürprizi sevmez.

Bence burada Microsoft doğru yönde gidiyor (bizzat test ettim). Hâlâ ufak cilalar gerekebilir.
Mesela erişilebilirlik tarafında ikonların anlamı ilk bakışta yeterince net mi,
mobilde nasıl hissettiriyor,
klavye kısayolları yeterince sezgisel mi…
bunlar henüz tamamen pişmiş değil gibi geliyor bana. Bu konuyla ilgili GPT-5.1 Codex Modelleri Emekli Oldu: Ne Yapmalısınız? yazımıza da göz atmanızı tavsiye ederim.

{
"previewMode": true,
"editModeTrigger": "explicit icon click",
"userGoal": [
"read content safely",
"edit only when intended",
"exit back to preview"
]
}

Nerede çok işe yarar?

Eh, Süreç odaklı ekiplerde fena değil.
Mesela release notlarıyla bağlı çalışma yapan takımlarda iş görüyor çünkü herkes aynı sayfaya bakarken yanlışlıkla içerik oynanmıyor.

Nerede yetmeyebilir?

Eğer takımınız aşırı hızlı içerik üretip tüketiyorsa ve herkes sürekli metin üzerinde çalışıyorsa,
bir iki ek kısayol beklenebilir.
Yani çözüm iyi ama sihirli değnek değil.

Kendi gözümden kısa değerlendirme

2024’ün sonunda bir kamu projesinde markdown tabanlı not yapısını yeniden tasarlarken benzer tartışmalar yaşamıştık.
Orada ekipten biri demişti ki:
“Okumayı kolaylaştıran şey aslında yazmayı da koruyor.”
O cümle kulağa basit geliyor ama bence olayın özeti o.

Microsoft’un yaptığı değişiklik tam olarak bunu yapıyor. Kullanıcının niyetini merkeze koyuyor. Edit modu artık gizlice gelmiyor; çağrılmayı bekliyor — Böyle düşününce insana biraz tuhaf geliyor. Iyi anlamda tuhaf…

Not: Eğer organizasyonunuzda yoğun onay süreçleri varsa bu güncellemeyi hemen pilotlamak mantıklı olurdu.Mesela operasyon ekibiyle ürün ekibini ayıran kurumlardabulut üstünde yapılan en küçük UX iyileştirmesi bile bilet sayısını azaltabiliyor.

Sıkça Sorulan Sorular

Azure DevOps Markdown editör nedir?

Azure DevOps içindeki büyük metin alanlarını Markdown ile biçimlendirmeye yarayan düzenleyicidir.Preview ve edit akışıyla hem okumayı hem yazmayı destekler.