Kurumsal web sitesi yaptırma süreci, tasarım örneği seçmekten önce işletmenin ihtiyaçlarını tanımlamakla başlar. Site hangi bilgileri sunacak, hangi işlemleri tamamlatacak ve kim tarafından güncellenecek? Bu sorular netleşmeden alınan teklifler farklı kapsamları aynı başlık altında sunabilir. Sonuçta fiyat, süre ve teslim beklentileri karşılaştırılamaz hale gelir.
Bu rehber, hazırlıktan teslim sonrasına kadar kullanabileceğiniz bir çalışma sırası sunar. Her bölümün sonunda elde etmek istediğiniz çıktı bellidir: ihtiyaç listesi, içerik planı, teklif karşılaştırması, onaylı tasarım veya test kaydı. Böylece proje yalnızca “site yapılıyor” diye izlenmez; hangi kararın verildiği ve hangi işin tamamlandığı görülebilir.
1. İş hedefini ve kullanıcı görevlerini yazın
İlk toplantıda sitenin amacı tek cümleyle ifade edilmelidir. Şirketi tanıtmak, uygun teklif talepleri toplamak, bayi başvurusu almak veya ürün kataloğu sunmak farklı hedeflerdir. Birden fazla amaç bulunabilir; ancak öncelikleri belirlenmelidir. Ana sayfadaki bilgi sırası ve çağrılar bu önceliklere göre şekillenir.
Ardından ziyaretçinin yapacağı işleri listeleyin. Hizmet kapsamını öğrenmek, benzer projeleri görmek, ekibi tanımak, iletişim kurmak veya dosya indirmek gibi görevler yazılabilir. Her görev için gerekli bilgi ve ekran belirlenir. Bu yaklaşım, “rakipte var, bizde de olsun” taleplerini gerçek ihtiyaçla karşılaştırmayı sağlar. Gereksiz modüller ilk sürümden çıkarılabilir.
Çıktı olarak kısa bir proje özeti hazırlayın. Hedef kitle, temel amaç, başarılı sayılacak kullanıcı işlemleri ve kapsam dışındaki işler yer alsın. Bu belge teknik şartname kadar ayrıntılı olmak zorunda değildir. Sağlayıcının doğru soruları sormasına ve teklifleri ortak ihtiyaç üzerinden hazırlamasına yardımcı olması yeterlidir.
2. Mevcut siteyi ve hesapları envantere alın
Bir site yenileniyorsa alan adı, hosting, e-posta, analitik, reklam ve yönetim paneli erişimleri listelenir. Hesapların kimin adına açıldığı ve hangi kişinin yönetici olduğu belirlenir. Proje sonuna kadar beklenen erişim sorunları yayına geçişi geciktirebilir. Parolaları gelişigüzel mesaj gruplarında paylaşmak yerine uygun erişim yöntemi kullanılır.
Mevcut sayfalar ve önemli adresler de çıkarılır. Trafik alan içerikler, reklam hedefleri ve dışarıdan bağlantı verilen sayfalar işaretlenir. Yeni tasarımda adres değişecekse yönlendirme planı gerekir. Mevcut içeriğin hangisinin korunacağı, güncelleneceği veya kaldırılacağı belirlenmeden bütün siteyi baştan yazmak değerli bilgilerin kaybolmasına yol açabilir.
3. Site haritasını sayfa türleriyle birlikte hazırlayın
Site haritası yalnızca menü isimlerinden oluşmamalıdır. Hizmet listesi, hizmet detayı, iş listesi, iş detayı, blog listesi ve blog detayı gibi sayfa türleri ayrılır. Aynı şablonu kullanan kayıtlar ile özel tasarım isteyen sayfalar belirtilir. Böylece tasarım ve geliştirme kapsamı daha doğru hesaplanır.
Her sayfanın görevi yazılmalıdır. Ana sayfa ziyaretçiyi doğru alana yönlendirebilir; hizmet detayı kapsam ve süreç açıklar; iş detayı gerçek proje bilgilerini sunar. Bütün sayfalara aynı uzun şirket tanıtımını koymak bilgi mimarisi değildir. Kullanıcı hangi soruyu hangi sayfada yanıtlayacağını anlayabilmelidir. İç bağlantılar bu yapıyı tamamlar.
4. İçerik sorumluluğunu belirleyin
Metinlerin, görsellerin ve proje bilgilerinin kim tarafından hazırlanacağı yazılı olmalıdır. Müşteri mevcut bilgileri sağlayabilir, ajans düzenleyebilir veya kapsamlı içerik üretimi ayrıca planlanabilir. Bu üç model farklı iş yükleri içerir. “İçerik dahil” ifadesinin hangi sayfaları ve kaç revizyonu kapsadığı sorulmalıdır.
Bir içerik tablosunda sayfa, gerekli alanlar, sorumlu kişi ve teslim tarihi bulunabilir. Gerçek proje görselleri ve referans logoları için kullanım hakları kontrol edilir. Stok fotoğraflar gerçek ekip veya ofis gibi sunulmaz. İçerik eksikliği tasarımın son aşamasında fark edilmemelidir. Metin yazarlığı süreci tasarımla birlikte ilerlediğinde daha tutarlı sonuç verir.
5. Yönetim panelinin kapsamını tarif edin
Panelden nelerin değiştirileceğini alan bazında düşünün. Ana sayfa başlıkları, hizmet metinleri, referans logoları, videolar, blog içerikleri ve SEO alanları örnek olabilir. Yeni kayıt eklemek, mevcut düzeni tamamen değiştirmek ve özel sayfa oluşturmak farklı yeteneklerdir. Hepsinin “panel” başlığı altında aynı kabul edilmemesi gerekir.
Kullanıcı rolleri, revizyon, taslak ve zamanlanmış yayın gibi özellikler günlük ihtiyaca göre seçilir. Birden fazla kişi içerik girecekse yetki sınırları önem kazanır. Yanlışlıkla silinen veya değiştirilen içeriğin geri alınması nasıl yapılacak? Bu sorunun cevabı yalnızca yedek dosyası değil, kullanılabilir bir yönetim süreci olmalıdır.
6. Çok dilli içeriği baştan planlayın
İkinci dil ihtiyacı varsa içerik alanları ve adres yapısı başlangıçta düşünülmelidir. Menü, form mesajı, görsel açıklaması ve SEO bilgileri de çeviri kapsamındadır. Yalnızca ana metni çevirmek tam bir dil deneyimi oluşturmaz. Çeviriyi kimin hazırlayacağı ve güncelleyeceği belirlenir.
Eksik çeviri olduğunda kullanıcıya ne gösterileceği konuşulmalıdır. Türkçe metni İngilizce adres altında yayımlamak tutarlı bir çözüm değildir. Dil karşılığı hazır olduğunda ayrıca yayımlama veya açık bir dil geçişi düşünülebilir. Bir dilde yapılan değişikliğin diğerinde kontrol gerektirdiğini panelin göstermesi bakım sürecini kolaylaştırır.
7. Teklifleri aynı kapsamla karşılaştırın
Sağlayıcılara aynı ihtiyaç listesini gönderin. Tasarım, geliştirme, içerik, taşıma, test ve bakım kalemleri ayrı görülebilsin. Toplam bedelin yanında dahil olmayan işler de sorulsun. Böylece düşük ve yüksek teklif arasındaki farkın kapsamdan mı, yöntemden mi veya hizmet düzeyinden mi kaynaklandığı anlaşılır.
Örnek işlere bakarken yalnızca ana sayfa görüntüsünü değerlendirmeyin. Mobil kullanım, detay sayfaları ve içerik yönetimi hakkında soru sorun. Benzer sektör deneyimi yararlı olabilir; ancak aynı tasarımı tekrar kullanmakla uzmanlık aynı şey değildir. Sağlayıcının ihtiyaçları nasıl analiz ettiğini ve kararları nasıl açıkladığını gözlemleyin. Maliyet kalemleri web sitesi maliyeti yazısında ayrıntılı ele alınır.
8. Proje planında karar ve teslim noktaları olsun
Takvim yalnızca başlangıç ve bitiş tarihinden oluşmamalıdır. İçerik teslimi, tasarım onayı, geliştirme kontrolü ve yayına hazırlık gibi aşamalar belirlenir. Her aşamada kimden hangi kararın beklendiği yazılır. Müşteri tarafında bir karar sorumlusu bulunması dağınık geri bildirimleri azaltır.
Yeni taleplerin nasıl değerlendirileceği önceden konuşulur. Kapsam dışı bir özellik geldiğinde süre ve maliyet etkisi görünür hale getirilir. Sağlayıcının hatasını düzeltmesi ile yeni özellik talebi ayrılır. Proje planı değişiklikleri yasaklamak için değil, etkilerini yönetmek için kullanılır. Bu düzen iki tarafın da beklentisini korur.
9. Tasarımı gerçek içerikle değerlendirin
Örnek metinlerle çok dengeli görünen bir tasarım, gerçek uzun hizmet adı veya farklı görsel oranıyla bozulabilir. Bu nedenle onay aşamasında mümkün olduğunca gerçek içerik kullanılır. Ana sayfanın yanında en azından önemli detay şablonları görülmelidir. Mobil davranışlar da aynı aşamada değerlendirilir.
Tasarım geri bildirimi kişisel beğeninin ötesine geçmelidir. “Bu alan karışık” yerine “Hizmet kapsamı ile teklif düğmesi arasındaki ilişki anlaşılmıyor” gibi somut açıklama yapılabilir. Başlık hiyerarşisi, okunabilirlik, görsel odak ve çağrıların yeri incelenir. Markanın mevcut tasarım dili varsa kararlar bununla tutarlı tutulur.
10. Mobil ve erişilebilir kullanım kontrolü yapın
Responsive tasarım ekran görüntüsünün telefona sığmasından fazlasıdır. Menünün açılması, bağlantıların rahat seçilmesi, form alanlarının anlaşılması ve hata mesajlarının görünmesi gerekir. Uzun metinler, farklı ekran genişlikleri ve yatay kullanım kontrol edilir.
Klavyeyle gezinme, görünür odak, form etiketleri ve uygun kontrast gibi temel kullanım özellikleri de değerlendirilir. Görsellerin alternatif metinleri anlamlı olmalıdır. Dekoratif görsel ile bilgi taşıyan görsel aynı biçimde ele alınmaz. Testi yalnızca tasarımı hazırlayan kişinin yapmaması, belirsiz alanların görülmesini kolaylaştırabilir.
11. Teknik SEO için somut kabul ölçütleri koyun
Her önemli sayfanın doğru adresi, başlığı, açıklaması ve canonical bilgisi olmalıdır. Eski URL'ler uygun hedeflere yönlenmelidir. Site haritası ve tarama ayarları planlanan yayın durumuyla tutarlı olmalıdır. Test ortamında kullanılan noindex ayarı canlıya geçişte bilinçli olarak gözden geçirilir; henüz aramaya açılmayacaksa korunur.
301 yönlendirme, canonical ve robots.txt birbirinin yerine geçmez. Her biri farklı görevi çözer. Teknik SEO teslimi “Google'da ilk sıraya çıkacak” cümlesiyle değil, çalışan ve tutarlı kurulumla değerlendirilmelidir. İçerik ve rekabet çalışması ayrıca planlanır.
12. Form ve ölçüm akışını uçtan uca deneyin
Bir formda düğmeye basılması yeterli test değildir. Kaydın veri tabanına veya ilgili sisteme ulaştığı, bildirimin doğru kişiye gittiği ve kullanıcıya başarı mesajı gösterildiği doğrulanır. Eksik alan ve hatalı girişler de denenir. Spam korumasının gerçek kullanıcıyı gereksiz yere engellemediği kontrol edilir.
Ölçüm olayları başarı anıyla eşleşmelidir. Başarısız form gönderimi dönüşüm sayılmamalıdır. Aynı işlem tekrar sayılıyor mu, kaynak bilgileri uygun biçimde saklanıyor mu? Bu sorular reklam başlamadan yanıtlanmalıdır. Dönüşüm takibi rehberi test senaryolarını ayrıntılandırır. Çerez tercihi öncesi ve sonrası davranışlar da kontrol kapsamındadır.
13. Performansı gerçek sayfalarda test edin
Ana sayfa, hizmet detayı, blog ve form gibi farklı şablonlar seçilir. Görsel boyutları, dış medya yükleme biçimi ve sunucu yanıtı incelenir. Tek bir puan yerine hangi koşullarda test yapıldığı kaydedilir. Gerçek içerik eklendikten sonra ölçüm tekrarlanır; boş şablon testi teslim için yeterli değildir.
Optimizasyon sırasında tasarım ve işlev korunmalıdır. Bütün betikleri geciktirip menüyü bozmak veya ana görseli gereksiz ertelemek iyi sonuç değildir. Core Web Vitals ve kullanıcı görevleri birlikte değerlendirilir. Güvenli uygulama sırası site hızlandırma rehberinde açıklanır.
14. Yayına geçişi geri dönüş planıyla yapın
Yayından önce mevcut dosya ve veriler yedeklenir. Alan adı, DNS, e-posta ve sunucu değişikliklerinin etkisi değerlendirilir. Özellikle e-posta kayıtlarının yanlışlıkla bozulmaması önemlidir. Geçiş zamanı işletmenin yoğunluğuna göre seçilebilir. Sorun halinde hangi sürüme nasıl dönüleceği bilinmelidir.
Yayına alındıktan sonra gerçek alan adında temel kontroller tekrarlanır. HTTPS, formlar, yönlendirmeler, görseller ve panel girişleri doğrulanır. Test ortamında çalışan bir ayar canlı sunucuda farklı davranabilir. Bu yüzden “Dosyalar yüklendi” ifadesi geçişin tamamlandığı anlamına gelmez. Kısa bir canlı kontrol raporu hazırlanmalıdır.
15. Teslim dosyalarını ve erişimleri alın
Alan adı ve hosting hesapları, panel yöneticisi, gerekli kaynak dosyaları, lisans bilgileri ve yedekleme yöntemi teslim listesinde bulunabilir. Hangi varlığın işletmeye ait olduğu açık olmalıdır. Dış servise bağlı özellikler ve devam eden ücretler belirtilir. Hesapların yalnızca tek bir çalışanın kişisel erişimine bağlı kalmaması düşünülür.
Panel eğitimi gerçek işlemlerle yapılmalıdır. Bir blog eklemek, görsel değiştirmek, referans logosu yüklemek ve başvuru kaydını görmek gibi görevler birlikte denenebilir. Kullanım notları kısa ve uygulanabilir olmalıdır. Uzun teknik doküman yerine günlük işlerin nasıl yapılacağını gösteren açıklamalar işletme için daha faydalı olabilir.
16. Bakım ve geliştirmeyi ayırın
Bakım kapsamı, destek süresi ve yanıt düzeni yazılı olmalıdır. Hata düzeltme, güvenlik güncellemesi, içerik girişi ve yeni özellik geliştirme aynı iş değildir. Hangi talebin hangi kapsama girdiği örneklerle açıklanabilir. Böylece teslim sonrası ilişki belirsiz beklentilerle başlamaz.
İlk kullanım döneminde gerçek ekip ve müşteri geri bildirimleri toplanır. Gereksiz alanlar, anlaşılmayan metinler veya eksik raporlar ortaya çıkabilir. Bunlar önceliklendirilerek sonraki geliştirme listesine alınır. Her isteği hemen eklemek yerine iş etkisi ve bakım maliyeti değerlendirilir. Site, kullanılmaya başlandıktan sonra da yönetilen bir üründür.
Örnek ihtiyaç belgesi nasıl görünür?
Varsayımsal bir danışmanlık şirketinin ihtiyaç belgesinde üç temel kullanıcı grubu bulunabilir: hizmet arayan işletmeler, iş başvurusu yapacak adaylar ve mevcut müşteriler. İlk grup kapsam ve örnek iş ararken, adaylar kariyer sayfasına ulaşmak ister. Mevcut müşterilerin ihtiyacı yalnızca iletişim bilgisi olabilir. Ana sayfanın bütün gruplara eşit alan ayırması gerekmeyebilir; ticari öncelik belirlenir, diğer yollar erişilebilir tutulur.
Belgede on hizmet kaydı, dört sayfa şablonu ve iki form yer aldığı varsayılsın. Her hizmet kaydının başlık, kısa açıklama, kapsam, süreç, görsel ve ilgili işler alanları tanımlanır. Formlarda dosya yükleme gerekiyorsa tür ve boyut sınırları belirlenir. Başvurunun kime gideceği, panelde ne kadar tutulacağı ve silme yetkisinin kimde olacağı işletmenin veri yönetimi düzeniyle birlikte kararlaştırılır. Bu ayrıntılar geliştirmeye başlamadan görünür hale gelir.
Aynı belgede ilk sürüme alınmayan özellikler de yazılır. Örneğin müşteri girişi veya otomatik teklif hesaplama daha sonraki aşamaya bırakılabilir. Kapsam dışı listesi, özelliğin unutulduğu anlamına gelmez; bilinçli öncelik kararını gösterir. Sonradan eklenmek istendiğinde mevcut tasarımla ilişkisi ve geliştirme etkisi değerlendirilir. Böylece proje, her toplantıda yeniden tanımlanan belirsiz bir işe dönüşmez.
Son teslim kontrol listesi
- Önemli menü, kart ve detay bağlantıları doğru sayfalara gidiyor.
- Formlar başarılı ve başarısız senaryolarda doğru davranıyor.
- Mobilde gerçek kullanıcı görevleri tamamlanabiliyor.
- İçerik ve görseller gerçek, güncel ve kullanım hakkı uygun.
- Eski adresler planlanan hedeflere yönleniyor.
- Dil sürümleri ve SEO alanları tutarlı.
- Yedek, erişim ve bakım sorumlulukları belli.
- Performans ve ölçüm kontrollerinin sonucu kayıtlı.
Bu liste proje kapsamına göre genişletilebilir. Önemli olan kabulün yalnızca görsel beğeniye dayanmamasıdır. İşletmenin ihtiyaçları karşılanıyor, ekip içeriği yönetebiliyor ve ziyaretçi beklenen işlemleri tamamlayabiliyorsa teslim somut biçimde değerlendirilebilir. Eksik kalan maddeler açık bir iş listesiyle takip edilir.
