Teknik Karar Çerçevesi için Bir Web Sitesi Nasıl Oluşturulur

Amaçları, Hedef Kitleyi ve Kapsamı Netleştirin

Sayfaları tasarlamadan veya araçları seçmeden önce bu çerçeve sitesinin neden var olduğunu ve hangi kararları iyileştirmesi gerektiğini netleştirin. Teknik bir karar çerçevesi sitesi sadece “dokümantasyon” değildir; karar desteğidir. Yanlış amaç tanımlarsanız, insanlar göz atılan ama önemli anlarda kullanılmayan bir kütüphane elde edersiniz.

Amacı belirtin

Tüm ekibin tekrar edebileceği bir cümlelik amaç bildirisi yazın. Yaygın amaçlar şunlardır:

• Ekipler arasında seçimleri standartlaştırmak (kararlar karşılaştırılabilir olsun)
• İncelemeleri ve onayları hızlandırmak (işin tıkanmasını önlemek)
• Riski azaltmak (güvenlik, güvenilirlik, maliyet sürprizleri)

Hangi amaç için optimize ettiğinizi söyleyemiyorsanız, karar çerçevesi dokümantasyonunuz muhtemelen tutarsız olacaktır.

Hedef kitleleri ve kullanım anlarını belirleyin

Birincil hedef kitlelerinizi ve ihtiyaç duydukları anlık bilgileri listeleyin:

• Mühendisler: uygulanabilir kriterler, örnekler ve ödünleşimler
• Ürün: zaman/maliyet etkileri ve kısıtlar
• Güvenlik: gerekli kontroller, istisnalar ve kanıtlar
• Liderlik: görünürlük, tutarlılık ve risk duruşu

Bu, neyin ana yol üzerinde olması gerektiğini ve neyin “daha fazla bilgi” içeriğinde kalacağını belirlemenize yardımcı olur.

Site tarafından desteklenmesi gereken kararları tanımlayın

Spesifik olun: “satın al vs inşa et,” “araç seçimi,” “mimari desen seçimi,” “veri depolama seçeneği” vb. Her karar türü, uzun bir anlatı yerine açık bir akışa (ör. karar matrisi UI, karar ağacı veya kontrol listesi) eşlenmelidir.

Başarı metriklerini ve kısıtları seçin

Birkaç ölçülebilir çıktı seçin: benimseme (benzersiz kullanıcılar veya PRD'lerde referans), karar süresi, tekrarlayan tartışmaların azalması, geç aşama geri dönüşlerin azlığı.

Ardından kısıtları erken belgeleyin: uyumluluk gereksinimleri, dahili mi yoksa halka açık mı olacağı ve değişiklikler için onay iş akışı. Bu, yönetişimi ve çerçeve sürümlendirmesini şekillendirir ve maliyetli yeniden tasarımları önler.

Çerçeve için Bir İçerik Modeli Oluşturun

Amaçlar netleşince, teknik karar çerçevenizin “parça listesi”ni ve bu parçaların sitede nasıl görüneceğini tanımlayın. Bir içerik modeli, siteyi tutarlı, aranabilir ve kararlar/guidelineler geliştikçe bakımının kolay olmasını sağlar.

Çerçevenin bileşenlerini envanterleyin

Yayınlamayı beklediğiniz her yapı taşını listeleyerek başlayın:

• İlkeler (neye değer verdiğiniz ve neden)
• Kriterler (neyi değerlendirmeniz gerektiği)
• İstisnalar (kuralın uygulanmadığı durumlar)
• Örnekler (gerçek kararlar ve sonuçları)
• Şablonlar (PRD'ler, kontrol listeleri, RFC kabukları)

Envanteri somut tutun: birisi bunu karar dokümanına kopyala-yapıştır yapabilirse, o bir bileşendir.

Her bileşenin nasıl temsil edileceğine karar verin

Okuyucuların ne bekleyeceklerini bilmesi için her bileşene varsayılan bir format atayın. Örnek:

• İlkeler kısa sayfalar olarak
• Kriterler yeniden kullanılabilir “kartlar” olarak
• İstisnalar çağrı blokları olarak
• Örnekler vaka inceleme sayfaları olarak
• Şablonlar indirme veya kopyalanabilir kesitler olarak

Bu, benzer içeriklerin wiki sayfaları, PDF'ler ve rastgele tablolar karışımına dönüşmesini önler.

Gerekli meta verileri tanımlayın

Meta veriler, filtreleme, sahiplik ve yaşam döngüsü yönetimi için çalışır. En azından şu alanları zorunlu kılın:

• Owner
• Son güncelleme tarihi
• Sürüm
• Etiketler
• Durum (taslak/aktif/deprece edilmiş)

Bu alanları sayfada görünür yapın ki okuyucular tazeliği hızlıca değerlendirebilsin.

Yeniden kullanılabilir blokları planlayın

Tekrar eden UI/içerik bloklarını belirleyin (henüz tasarlamamış olsanız bile): kriter kartları, ödünleşim tabloları, sözlük terimleri, “ne zaman kullanılır / ne zaman kullanılmaz” bölümleri ve karar kayıtları. Yeniden kullanım, tanıdık bir okuma ritmi yaratır ve gelecekteki güncellemeleri hızlandırır.

Nelerin kapsam dışında olduğunu belgeleyin

Kısa bir “dahil değil” notu yazın (ör. satıcı karşılaştırmaları, ekip-özel çalışma talimatları, derin eğitimler). Net sınırlar, çerçeve sitesinin odaklanmasını sağlar ve genel bilgi tabanına dönüşmesini engeller.

Bilgi Mimarisi ve Gezinmeyi Planlayın

Teknik karar çerçevesi, insanların durumlarına uygun rehberliği hızla bulabildiğinde başarılı olur. Bilgi mimarisi (IA), “akıllı içeriği” özellikle projeye yarım kalmış kullanıcıların ihtiyaç duyduğu cevaba çevirir.

Niyetle eşleşen üst seviye gezinmeyle başlayın

Tahmin edilebilir birkaç giriş noktası kullanın. İyi bir varsayılan:

• Start here (yönlendirme, kimler için, nasıl kullanılır)
• Framework (uçtan uca süreç veya akış)
• Criteria (tanımlar, ödünleşimler, nasıl değerlendirilir)
• Examples (gerçek senaryolar, vaka incelemeleri, karşılaştırmalar)
• FAQs (yaygın kafa karışıklıkları, uç durumlar)
• About (sahiplik, güncelleme politikası, iletişim)

Etiketleri sade tutun. Hedef kitleniz zaten “Dimensions” kelimesini kullanmıyorsa, genelde “Criteria” daha iyidir.

İlk kez gelenler için bir “başlangıç” yolu tasarlayın

Yeni ziyaretçiler için Start here kısa ve eyleme dönük olsun: 2–5 dakikalık bir genel bakış ve ardından net sonraki adımlar (ör. “Bir senaryo seçin” veya “Hızlı kararı çalıştırın”). Canonical framework sayfasına ve bir veya iki örnek yürütmeye bağlantı verin.

Hem hızlı kararları hem de derin araştırmayı destekleyin

Birçok kullanıcı yalnızca önerilen varsayılanı ister; diğerleri kanıt ister. İki paralel yol sağlayın:

• Hızlı yol: önerilen bir seçenek ve “neden” ile biten karar ağacı veya kısa anket
• Derin yol: kriter bazlı rehberlik, genişletilmiş örnekler ve referanslar

Yolları değiştirmeyi kolaylaştırın; tutarlı eylem çağrılarına yer verin (“Need the full comparison? See /criteria”).

İnsanların anlayacağı bir taksonomi tanımlayın

Ekiplerin konuştuğu şekilde kategoriler, etiketler ve filtreler oluşturun: ürün adları, kısıtlar (“regüle”, “düşük gecikme”), takım bağlamı (“küçük ekip”, “platform takımı”) ve olgunluk (“prototip”, “kurumsal”). İç örgüt jargonundan kaçının.

İçerik büyüyecekse aramayı erken ekleyin

Bir avuç sayfadan fazla olacağını tahmin ediyorsanız, aramayı birincil gezinme aracı olarak ele alın. Üstte arama kutusu koyun, sonuçları “Framework”, “Criteria” ve “Examples” öncelikli olacak şekilde ayarlayın ve eşanlamlıları ekleyin (ör. “SLA” ↔ “uptime”).

Karar Destek UI Kalıplarını Seçin

Teknik karar çerçevesi sitesi uzun bir belgeye benzeyip üstünde “iyi şanslar” mesajı olmamalı. Ana sayfalarda kullanıcının ne yapabileceğini açıkça gösterin: seçenekleri yan yana karşılaştırmak, kısıtları kaydetmek, bir öneri görmek ve özeti dışa aktarmak.

Desene karara göre eşleştirin

Farklı kararlar farklı etkileşim modelleri gerektirir. Her karar türü için birincil bir kalıp seçin, ardından basit yardımcı bileşenlerle destekleyin.

• Karar ağacı: bir cevap birden fazla yolu ortadan kaldırdığında en iyi (“Çevrimdışı destek zorunluysa X’e gidin”). Adımları kısa tutun ve ilerlemeyi gösterin.
• Karar matrisi: birden çok seçeneği aynı kriterlere göre karşılaştırmak için en uygunu. Kullanıcıların ağırlıkları ayarlamasına ve sıralamaların nasıl değiştiğini görmesine izin verin.
• Skor kartı: geç/koşullu geç/kalma gibi net sonuç gerektiğinde uygundur. Yönetişim ağırlıklı kararlarda işe yarar.
• Kontrol listesi: hazır olma ve uyumluluk için faydalıdır (“Veri barındırma doğrulandı mı?”). Tutarlı incelemeleri sürdürmek için kullanın.

Girdileri, çıktıları ve uç durumları tanımlayın

UI tasarlamadan önce kullanıcıdan ne alınacağını (girdiler) ve kullanıcının ne alması gerektiğini (çıktılar) yazın. Girdiler: kısıtlar, öncelik ağırlıkları veya “olmazsa olmaz” gereksinimler olabilir. Çıktılar somut olmalı: sıralanmış liste, önerilen seçenek ve kısa açıklama.

Kenar durumlarını planlayarak kullanıcı güvenini koruyun:

• Eksik veri: “bilinmiyor”u açıkça gösterin ve bunun sonucu nasıl etkilediğini açıklayın.
• Beraberlikler: berabere kalan seçenekleri “neden berabere” notlarıyla ve önerilen eşik kırıcılarla gösterin.
• Belirsizlik: aralıklar (ör. maliyet tahmini) izin verin ve güveni/girdi hassasiyetini gösterin (“Eğer gecikmeye verilen ağırlık artarsa, Seçenek B kazanır”).

Yönlendirme vs. gerekçe gerektirme

Sistemin ne zaman öneri yapması gerektiğine (“Çoğu ekip … seçiyor”) ve ne zaman seçim için gerekçe metni zorunlu kılacağına karar verin (ör. güvenlik istisnaları, sıra dışı ödünleşimler). Kural olarak: seçim risk, maliyet veya uzun vadeli sahiplik etkiliyorsa gerekçe isteyin.

Sonuçları paylaşmayı kolaylaştırın

İncelemeler için yazdırılabilir ve paylaşılabilir bir sonuç sayfası ekleyin: seçilen seçenek, en önemli kriterler, temel varsayımlar ve kaydedilmiş gerekçe. Export to PDF, Copy summary veya Share link (uygun erişim kontrolleriyle) gibi eylemler ekleyin. Bu sonuç sayfası, insanların toplantılara getirdiği kanıt olur ve çerçevenizin gerçekten kararları kolaylaştırdığını gösterir.

Sayfa Şablonları ve Tel Çerçeveler Tasarlayın

Şablonlar, çerçevenizi sayfa yığını olmaktan tahmin edilebilir bir karar aracına dönüştürür. Renkleri ya da metni cilalamadan önce küçük bir çekirdek sayfa tipi seti ve paylaşılan bileşenlerini taslak olarak çizin.

Dört temel şablonla başlayın

Çoğu teknik karar çerçevesi sitesi şu şablonlarla kapsanabilir:

• Genel bakış sayfası: çerçeve nedir, kimler için, uçtan uca nasıl kullanılır
• Kriter sayfası: her kriter için ayrı sayfa (ör. maliyet, gecikme, ekip yeteneği) ve net puanlama rehberi
• Karşılaştırma sayfası: yan yana görünüm (genellikle karar matrisi UI) ile seçenekleri tartın
• Sonuç sayfası: “X’i seçtiyseniz, bundan sonra ne yapılır” — ödünleşimler ve uygulama notları dahil

Her şablonu kasıtlı olarak basit tutun: hedef, seçim yaparken bilişsel yükü azaltmaktır.

Hiç değişmeyen hiyerarşi kuralları belirleyin

Tutarlılık yaratıcılıktan daha önemlidir. Her sayfa türünde sabit bir sıra tanımlayın ve uygulayın:

1. Sayfa başlığı (spesifik ve taranabilir)
2. Bir paragraflık özet (bu sayfanın hangi karara yardımcı olduğu)
3. Ne zaman kullanılır / ne zaman kullanılmaz (kısa iki bölüm)
4. Adımlar (numaralandırılmış eylemler, uzun anlatı yerine)

Kullanıcı bir sayfanın “şekli”ni bir kez öğrendiğinde, diğerlerinde daha hızlı hareket eder.

Görsel işaretlerin tek bir anlamı olsun

Görsel işaretleri yalnızca tutarlı uygulandığında tanıtın. Yaygın örnekler:

• Risk seviyesi (Düşük/Orta/Yüksek) kriterlerde, karşılaştırmalarda ve sonuçlarda aynı şekilde gösterilir
• Zorunlu vs. isteğe bağlı kriterler farklı etiketlerle ayrılır (anlamları karıştırmayın)

Bu kuralları bileşen notlarında belgeleyin ki tasarım yinelemelerinden sonra da korunsun.

Öğreten bir “örnek” bileşeni tasarlayın

Örnekler çerçeveleri inandırıcı kılar. Tekrarlanabilir bir blok oluşturun:

• Bağlam (ne oluyor)
• Kısıtlar (bütçe, uyumluluk, zaman çizelgesi)
• Karar (ne seçildi)
• Gerekçe (neden)
• Sonuçlar (sonrasında ne değişti)

Gerçek kararlarla doğrulayın

Tel çerçeveleri, hedef kitlenizin gerçekten verdiği 3–5 gerçek karar üzerinde test edin. Kullanıcılardan sadece tel çerçevelerle bir kararı tamamlamalarını isteyin: nerede tereddüt ediyorlar, etiketleri yanlış mı anlıyorlar veya bir detay için “bir şey daha” mı istiyorlar? Önce yapı düzeltin; görsel cilaya sonra geçin.

Teknoloji Yığını ve Barındırmayı Seçin

Teknik seçimleriniz siteyi okumayı, güncellemeyi ve güvenilir bulmayı kolaylaştırmalı—sadece “modern görünmesini” sağlamak için değil. İçeriğin ne sıklıkla değişeceğini, kimlerin düzenleyeceğini ve değişiklikleri nasıl onaylayacağınızı haritalandırarak başlayın.

Statik vs dinamik: uyan en basit aracı seçin

Statik bir site (dosyalardan HTML’e derlenen) genellikle karar çerçevesi dokümantasyonu için idealdir: hızlı, ucuz ve sürümlenebilir.

Sık sık teknik olmayan kişilerden düzenleme gerekiyorsa, dinamik bir yaklaşım sürtünmeyi azaltabilir.

• Statik site jeneratörü (SSG): Markdown-öncelikli iş akışları ve öngörülebilir yayınlar için harika
• CMS veya headless CMS: editörlerin UI, taslaklar ve onaylar istediği durumlarda iyi
• Özel uygulama: gerçek kullanıcı hesapları, kaydedilmiş kararlar veya ileri düzey kişiselleştirme gerektiğinde

Eğer uzun bir geliştirme döngüsü istemiyorsanız, etkileşimli parçaları (karar matrisi UI veya karar ağacı akışı gibi) Koder.ai gibi bir platformla prototiplemeyi düşünün. Bu araç sohbet tabanlı bir spesifikasyondan React tabanlı bir web uygulaması oluşturabilir ve hazır olduğunuzda kaynak kodunu dışa aktarabilirsiniz.

Yığını düzenleme iş akışınıza göre eşleştirin

Kim düzenliyor ve nasıl gözden geçiriyorsunuz ona göre seçin:

• Markdown + Git: teknik ekipler için, güçlü inceleme geçmişi ve kolay geri alma
• Headless CMS + SSG: editörler için formlar, önizleme ve zamanlama gerektiğinde
• Wiki-benzeri araçlar: hızlı başlar ama gezinme, SEO ve uzun vadeli yapı konusunda dikkatli olun

Barındırma, dağıtımlar ve emniyet ağları

Güncellemeler sırasında güven için plan yapın:

• Her değişiklik için önizleme ortamları (inceleyiciler yayınlamadan önce tıklayabilsin)
• Tek tıkla geri alma (veya son iyi yapıyı yeniden dağıtın)
• Küresel izleyici için CDN destekli barındırma (hız ve güvenilirlik)

Aşırı mühendislik yapmadan UI araçları

Tutarlılık sağlıyorsa küçük bir tasarım sistemi veya bileşen kütüphanesi kullanın (tablolar, çağrı kutuları, akordeonlar, karar ağaçları). Ağır özelleştirmeler yerine güvenilir, basit araçları tercih edin.

“Neden”i yazın

Kısa bir “Mimari & Bakım” sayfası ekleyin: yığın, düzenlemelerin üretime akışı, sürümlerin nerede durduğu ve kimin neyi sahiplendiği. Gelecek bakımcılar size teşekkür edecek.

Yönetişim, Sahiplik ve Sürümlendirme

Karar çerçevesi sitesi, insanların bunun güncel, gözden geçirilmiş ve sahiplenilmiş olduğuna güvendikleri sürece işe yarar. Yönetişim komiteleri gerektirmez ama herkesin takip edebileceği açık kurallar olmalı.

Güncellemeler nasıl olacak?

Bir öngörülebilir güncelleme yolu seçin ve yayınlayın (ör. /contributing sayfasında). Yaygın, düşük sürtünmeli akış:

• Birisi değişiklik önerir (issue veya kısa talep formu)
• Bir taslak oluşturulur (pull request veya editörde düzenleme)
• Editoryal inceleme açıklık, tutarlılık ve terimleri kontrol eder
• Atanmış onaylayan (genelde domain sahibi) onay verir
• Değişiklik birleştirilir ve değişiklik günlüğünde notla yayınlanır

Teknik olmayan ekipler için aynı adımları CMS içinde benzer şekilde uygulayabilirsiniz: gönder → incele → onayla → yayınla.

Hafif bir yönetişim modeli oluşturun

Rolleri açık yapın ki kararlar takılsın:

• Owner (karar verici): rehberliğin doğruluğundan sorumlu
• Editors (uygulayanlar): sayfaları bakımını yapar, stil ve linkleri korur
• Approvers (onaylayanlar): risk, güvenlik veya uyumluluk gereksinimlerini kontrol eder

Küçük tutun: her ana konu için bir owner genelde yeterlidir.

Okuyucunun anlayacağı sürümlendirme

Çerçeveyi bir ürün gibi ele alın. Kararları etkileyen değişiklikler için semantik versiyon (ör. 2.1.0) veya düzenli yayınlar için tarihlendirilmiş sürümler (ör. 2025-03) kullanın. /changelog sayfasında ne değişti, neden ve kim onayladı açıklayın.

Her önemli sayfada Last updated ve Owner gösterin; bu güven oluşturur ve yanlış bir şey fark edildiğinde kiminle iletişime geçileceğini belirtir.

Güveni bozmayacak emekliye alma

Rehberliği emekliye alma planı:

• Eski sayfaları Deprecated olarak işaretleyin ve kısa bir neden ekleyin
• Yerine geçen sayfaya (veya yeni önerilen seçeneğe) bağlantı verin
• Eski rehberliğin artık kullanılmaması gereken bir son kullanma tarihi ekleyin

Emekliye alma başarısızlık değil; çerçevenin sorumlu şekilde evrildiğinin görünen bir taahhüdüdür.

Net UX Yazımı ve Terminoloji

Karar çerçevesi, insanlar baskı altındayken okudukları kelimeler kadar kullanışlıdır. UX yazımını sistem tasarımının bir parçası gibi ele alın: yanlış yorumlamayı azaltır, kararları hızlandırır ve sonuçları savunmayı kolaylaştırır.

Risk azaltıyormuş gibi yazın

Kısa cümleler kullanın. İç dil yerine yaygın kelimeleri tercih edin. Yeni bir fikir tanıtıyorsanız, sayfada ilk kullanımda tanımlayın ve aynı ifadeyi her yerde yeniden kullanın.

Hedefler:

• Paragrafta bir fikir
• Doğrudan talimatlar (“Bir seçenek seçin”) yerine dolaylı ipuçlarından kaçınmak
• Minimum jargon; kaçınılamazsa ilk kullanmada tanımlayın

Bir sözlük oluşturun (ve ona bağlantı verin)

Bazı terimler kaçınılmazdır: API, PII, SLO, “availability zone” vb. Bunları bir sözlükte toplayın ve bir sayfada (/glossary) tutun; sayfa içinde ilk kullanımda terime bağlantı verin.

Sözlük kısa, aranabilir ve sade dilde olmalı. Tek bir sayfa olarak koruyun ve sürümlendirilmiş, gözden geçirilmiş içerik olarak yönetin.

Kriter ifadelerini standartlaştırın

Tutarsız kriter ifadeleri tutarsız kararlara yol açar. Küçük bir etiket seti seçin ve matris, kontrol listesi ve ağaçlarda aynı şekilde kullanın.

Kolay taranan bir pattern:

• Must: zorunlu; karşılanmazsa karar ilerlememeli
• Should: güçlü tercih; karşılanmıyorsa gerekçe verin
• Nice to have: faydalı ama isteğe bağlı

Ayrıca her kriteri bir eylem fiiliyle başlatın (ör. “Veriyi dinlenirken şifrele”, “Denetim günlüğü sağlayın”, “Rol tabanlı erişim destekleyin”).

İstisnaları ve yükseltmeyi cezalandırmayan bir dille yönetin

İstisnalar olacaktır. Bu yolu normal ve güvenli hissettirecek şekilde yazın, yine de hesap verebilirlik talep edin.

İyi kalıplar:

• “Bir Must karşılanamıyorsa, durun ve istisna yolunu kullanın.”
• “Zaman kısıtlıysa, ödünleşimi belgeleyin ve takip tarihi belirleyin.”
• “Karar birden çok takımı veya üretim riskini etkiliyorsa [Owner/Team]'e yükseltin.”

Suçlayıcı dilden kaçının (“başarısızlık”, “ihlal”)—bunları sadece gerçek uyumluluk gereksinimlerinde kullanın.

Karar kayıtlarında kullanılabilecek kopya sağlayın

İnsanların kararları tutarlı şekilde belgelemeleri için kolay kopyalanabilir gerekçe şablonları sunun.

Decision: We chose [Option] for [Context].

Rationale: It meets all Must criteria and satisfies these Should criteria: [list].
Trade-offs: We accept [cost/limitation] because [reason].
Risks and mitigations: [risk] → [mitigation].
Exception (if any): We are not meeting [criterion]. Approval: [name/date].
Review date: [date].

Bu şablonu karar çıktısının yanına (ör. karar matrisi sonucundan sonra) koyun ki kullanıcılar aramak zorunda kalmasınlar.

Erişilebilirlik, Mobil ve Yazdırma Dostu Tasarım

Karar çerçevesi, insanların gerçekten okuyabildiği, gezinebildiği ve karar araçlarını kullanabildiği durumlarda işe yarar—toplantıda dizüstünde, olaylar arasında telefonda veya onaylar için yazdırılmış halde.

WCAG temellerini projeye dönüştürün

En yaygın hataları önleyen temellerle başlayın:

• Gerçek başlık yapısı (H2/H3/H4) kullanın; bölümler taranabilir ve ekran okuyucu dostu olur
• Metin, link ve durum etiketleri için yeterli renk kontrastı sağlayın; anlamı yalnızca renge bağlamayın
• Linkler, butonlar, filtreler ve sekmeler için görünür odak durumları sağlayın
• Tüm etkileşimli öğeler klavye ile erişilebilir olsun (Tab/Shift+Tab, Enter/Space)

Eğer “karar durumu” etiketleri, renkli şeritler veya skor çubukları kullanıyorsanız, metin eşdeğerleri (ikon + etiket veya görselde gizli metin) ekleyin.

Karar araçlarını ekran okuyucu ve klavye ile uyumlu yapın

Matrisler ve ağaçlar genelde erişilebilirlikte başarısız olur çünkü çok etkileşimlidirler.

• Matrisler gerçek tabloysa HTML tablo kullanın. Kolon/satır başlıkları ekleyin ve hücre içeriğini kısa tutun.
• Filtreler için yerel form kontrollerini tercih edin (select, checkbox). Sonuçlar sayfa yeniden yüklenmeden güncelleniyorsa aria-live bölgesi ile “3 seçenek eşleşti” gibi bildirim ekleyin.
• Karar ağaçlarında her adımın net bir soru, tek bir “şu anki adım” başlığı ve fare/dokunmaya bağlı olmayan buton/bağlantılar olmalıdır.

Karmaşık içeriğin mobilde okunabilirliği

Mobilde geniş tablolar ve uzun karşılaştırmalar kırılabilir. Yaygın çözümler:

• Geniş tabloları her seçenek için kartlara dönüştürün; ana özellikleri öne koyun
• Detaylar için açılır/kapanır bölümler kullanın (özet görünür kalsın)
• Yapışkan bir özet ekleyin (geçerli seçimleriniz, kısıtlar ve önerilen yol) ki kullanıcılar kaybolmasın

Onaylar ve toplantular için yazdırma/PDF çıktısı

Birçok karar onay gerektirir. Yazdırma stil sayfası sağlayın:

• Gezinme chrome'unu kaldırın, açılır içerikleri genişletin ve referanslar için tam URL'leri yazdırın
• Tabloların bölünmesini önleyin; kriterlerin ortasında sayfa kırılmasına dikkat edin
• Üstte kısa bir “Karar Özeti” bloğu olsun (bağlam, kısıtlar, öneri, tarih, sürüm)

En çok sorun çıkaranları yakalayan temel testler

Klavye-only navigasyon, bir ekran okuyucu (NVDA/VoiceOver) ve en az bir mobil tarayıcı ile test edin. Bunu bir yayınlama kapısı olarak ele alın.

Performans ve SEO Temelleri

Çerçeve sitesi işe yaraması için insanların doğru rehberi hızlıca bulabilmesi ve sayfaların yeterince hızlı yüklenmesi gerekir. Performans ve SEO sıkı bağlıdır: daha hızlı sayfalar taranması ve sıralaması daha kolay sayfalardır.

Sayfaları hızlı yapın (aşırıya kaçmadan)

Temel kazanımlarla başlayın:

• Görüntüleri optimize edin: modern formatlar (WebP/AVIF), görüntüleri maksimum gösterim boyutuna göre ölçekleyin ve katman altı görselleri lazy-load yapın.
• Scriptleri azaltın: çoğunlukla metin olan dokümantasyon için ağır client-side uygulamalardan kaçının; mümkün olduğunca az JavaScript gönderin.
• Agresif önbellekleme: statik varlıklar için tarayıcı önbelleklemesi ve küresel kitle için CDN kullanın.

Pratik hedef: metin hemen render olsun, etkileşimler gecikmesin. Çerçeve siteleri çoğunlukla okuma ve karşılaştırma içerir—ilk görünüm hızını önceliklendirin.

İnsanların nasıl aradığına uygun sayfa içi SEO

Karar-çerçeve sorguları genellikle spesifik olur (“analitik için veritabanı seçimi”, “API kimlik doğrulama seçenekleri”). Arama motorlarının her sayfayı anlamasına yardımcı olun:

• Temiz, stabil URL'ler kullanın (ör. /frameworks/api-auth/options), ve sürümler arasında slug değiştirmeyin
• Sorunun bağlamını içeren tanımlayıcı başlıklar yazın
• Okuyucunun sayfada hangi kararı vereceğini açıklayan meta açıklama ekleyin

Ayrıca başlıkların anlamlı olmasına dikkat edin (H2/H3 yapısı) ki hem insanlar hem tarayıcılar mantığı tarayabilsin.

Yapılandırılmış içerik: SSS, sözlük ve dahili linkler

Çerçevelerde tekrar eden terimler ve “insanlar ayrıca soruyor” soruları vardır. Bunları birinci sınıf içerik olarak ele alın:

• Yüksek niyetli sayfalarda SSS blokları ekleyin (ör. “Ne zaman seçenek X'ten kaçınmalıyız?”)
• Tutarlı terminoloji için sözlük oluşturun ve terimleri satır içi ilk kullanımda bağlayın
• Amaçlı dahili linkleme kullanın: “Önkoşullar”, “Alternatifler” ve “İlgili kararlar” bölümleri çıkmaz sokakları önler

İç bağlantıları göreli tutun (ör. /glossary, /frameworks/decision-trees).

Site haritaları, robots ve bulunabilirlik

Gerçekten indekslenmesini istediğiniz içeriği yansıtan bir site haritası oluşturun. Karışık erişimli siteler için yalnızca genel içeriği indeksleyin ve özel alanları robots.txt ile engelleyin (ve oturum açmanın arkasında tutun).

Son olarak, sitede bulunabilirlik için plan yapın: iyi arama, gerçek karar kriterlerini yansıtan etiketler ve ilgili kararları bir araya getiren küçük bir “Related” modülü.

Analitik, Geri Bildirim ve Sürekli İyileştirme

Çerçeve, insanlar gerçekten kullanırsa ve araçlar/standartlar değiştikçe güncel tutulursa işe yarar. Analitik ve geri bildirim, ne olduğuna dair hafif sinyaller verir ve içeriği aşırıya kaçmadan iyileştirmenizi sağlar.

Aşırı veri toplamadan kullanım izleyin

Pratik sorulara cevap veren birkaç sinyalle başlayın:

• Sayfa görüntülemeleri ve giriş sayfaları: hangi rehberler en çok ziyaret ediliyor, insanlar nereden başlıyor?
• Site içi arama terimleri: insanlar gezintiyle bulamadığı neyi arıyor?
• İndirmeler/dışa aktarımlar: PDF, CSV veya “kararı paylaş” özetleri alınıyor mu?

Gizliliğe duyarlı olun: tanımlayıcıları küçültün, hassas girdileri toplamaktan kaçının ve ne izlediğinizi kısa bir gizlilik notunda (ör. /privacy) belgeleyin.

Karar aracı etkileşimlerini ölçün

Etkileşimli araçlarınız varsa (karar matrisi, karşılaştırma tablosu, karar ağacı), basit etkinlik izleme ekleyin:

• Matris seçimleri (hangi kriterler kullanıldı)
• Filtre kullanımı ve “sıfırla” eylemleri
• Sonuç dışa aktarımları (kopyala/paylaş/indir)
• Akışı terk etme noktaları (kullanıcılar nerede akışı bırakıyor)

Bu veriler, kullanıcıların sonuca ulaşıp ulaşmadığını veya takılıp kalıp kalmadığını gösterir.

Benimseme panoları (konu/ekip bazında)

Gizliliğe dikkat ederek özet panolar hazırlayın:

• Konu alanına göre kullanım (ör. veritabanları, CI/CD, izlenebilirlik)
• Ekip bazlı kullanım ancak sadece toplu ve kimliksiz verilerle
• Lansman, eğitim veya politika değişikliklerinden sonra zaman serileri

Eyleme dönüşen geri bildirim döngüleri

Küçük bir “Bu faydalı oldu mu?” sorusu ve kısa bir talep formu ekleyin (ör. /request) ile şunları raporlamayı kolaylaştırın:

• Matrise eksik seçenekler
• Karışık terminoloji
• Güncelliğini yitirmiş öneriler

Güncelleme tetikleyicilerini tanımlayın: bir rehberde yüksek çıkış oranı, karar akışında düşük tamamlama, tekrarlayan arama terimleri veya tekrar eden geri bildirim temaları. Her tetikleyiciyi bir iş bileti, sahibi, son tarih ve net “done” tanımı ile yönetin—iyileştirme rutinin bir parçası olsun.

Güvenlik, Gizlilik ve Yayın Kontrol Listesi

Bir çerçeve sitesi, güvenli varsayılanlarla ve çalıştırması öngörülebilir olduğunda güvenilir olur. Güvenlik ve gizliliği operasyon işi değil ürün özelliği olarak ele alın.

Temel güvenlik

Her yerde HTTPS kullanın (dokümantasyon alt alanı dahil) ve HSTS etkinleştirin. Standart güvenli başlıkları ekleyin (CSP, X-Content-Type-Options, X-Frame-Options veya frame-ancestors, Referrer-Policy) tarayıcı tabanlı yaygın riskleri azaltmak için.

Editör erişimini en az ayrıcalıkla yönetin: yazarlar, inceleyiciler ve yöneticiler için ayrı roller; SSO veya güçlü MFA kullanın; birisi ekip değiştirince hesapları hemen kaldırın. Eğer çerçeveyi bir repo'da saklıyorsanız, main'e kimlerin merge yapabileceğini kısıtlayın ve inceleme zorunlu kılın.

Gizlilik ve veri işleme

Hangi içeriğin halka açık olacağı ve hangi içeriğin kimlik doğrulamaya alınacağını (ör. dahili satıcı değerlendirmeleri, maliyet modelleri veya olay incelemeleri) netleştirin. Eğer bazı bölümler gated ise, temel okuma için oturum açmayı zorunlu kılmadan oturum açmanın ne fayda sağladığını belirtin.

Formlarda hassas veri toplamayın. Geri bildirim formları gerekiyorsa asgari bilgi isteyin (örn. “Bu faydalı oldu mu?” + isteğe bağlı e-posta). Girişlerin yanına şu uyarıyı koyun: “Lütfen gizli anahtar, token veya müşteri verisi yapıştırmayın.”

Operasyonel hazırlık

Yedekleme (içerik deposu, veritabanı ve dosya varlıkları) planlayın ve geri yüklemeleri test edin. Hafif bir olay planı oluşturun: kimin aranacağı, düzenlemeyi nasıl devre dışı bırakacağınız ve durum güncellemelerinin nerede paylaşılacağı.

Bağımlılık güncellemelerini (CMS/eklenti, SSG, barındırma runtime) zamanlayın ve güvenlik duyurularına abone olun.

Lansman öncesi kontrol listesi

Duyurmadan önce son bir tarama yapın:

• Kırık linkler, eksik sayfalar ve arama indeksleme kuralları
• Eski URL'lerden yönlendirmeler (paylaşılan dokümanlarda 404'lerden kaçının)
• İzinler: kim görüntüleyebilir, kim düzenleyebilir, kim yayınlayabilir
• Analitik ve onay banner davranışı (kullanılıyorsa)
• Robots.txt, sitemap.xml ve kanonik URL'ler

Eğer bir kontrol listesi sayfanız varsa, bunu /about veya /contributing üzerinden bağlantılayın ki iş akışının parçası kalsın.