Web sitesi proje kapsamı, sayfa listesinin yanında kullanıcının yapacağı işleri, gerekli içerikleri, entegrasyonları ve yayın öncesi testleri açıklamalıdır. “İletişim formu olsun” yerine formun hangi bilgiyi alacağını, nereye göndereceğini ve başarısız gönderimde ne yapacağını yazın. Böylece teklif edilen iş gerçekten karşılaştırılabilir olur.
Sitenin yapacağı işi tanımlayın
Önce sitenin işletme içindeki rolünü yazın. Hizmetleri anlatan bir kurumsal site, teklif toplayan bir ürün kataloğu, satış yapan bir mağaza ve müşterinin işlemlerini takip ettiği bir portal aynı kapsam değildir. Bir projede birden fazlası bulunabilir; hangi işin ilk sürümde öncelikli olduğunu açıkça belirtin.
Ardından ziyaretçinin tamamlaması gereken temel akışı tarif edin. Örneğin bir satın alma sorumlusu uygun ürünü bulacak, teknik özelliklerini inceleyecek ve ilgili ürün bilgisiyle teklif isteyecek. Bu akış; arama, filtreleme, ürün sayfası, form ve satış ekibine bilgi aktarımı gerektirebilir. Kapsam, bu bağlantıları gösterdiğinde tasarım yalnızca güzel ekranlar üretmekten çıkar ve kullanıcının işini tamamlamasına yardım eder.
Sayfaları ve içerik türlerini listeleyin
“Yirmi sayfa” ifadesi yirmi farklı tasarım anlamına gelmeyebilir. Hizmet sayfaları ortak bir şablonla yönetilebilir; ürün kataloğu ise aynı şablona rağmen çok sayıda veri alanı içerebilir. Teklifte sayfa türlerini, her türün temel alanlarını ve başlangıçta taşınacak içerik miktarını ayrı belirtin. Metin yazımı, çeviri, fotoğraf seçimi ve veri temizliği kendiliğinden dahil sayılmamalıdır.
Mevcut siteniz varsa korunacak, güncellenecek ve birleştirilecek içerikleri listeleyin. Eski bağlantıların yeni yapıda nasıl karşılanacağı da geçiş işinin parçasıdır. Çok dilli projelerde yalnızca dil sayısını değil, hangi sayfaların hangi dilde hazırlanacağını ve sonraki güncellemeyi kimin yapacağını yazın. Yayında eksik kalacak sayfaları önceden fark etmek, son hafta çeviri beklemekten daha yönetilebilirdir.
Özellikleri davranışlarıyla anlatın
“CRM entegrasyonu” gibi bir başlık, hangi bilginin nereye gideceğini açıklamaz. Form gönderildiğinde oluşturulacak kaydı, aktarılacak alanları, eşleştirme kuralını ve aktarım başarısız olursa ne yapılacağını belirtin. Bir işlevin yalnızca başarılı durumunu konuşmak yeterli değildir; eksik bilgi, yanlış giriş ve geçici bağlantı sorunu da kapsamda düşünülmelidir.
Özel geliştirme ihtiyacı varsa bunu peşinen belirli bir altyapıya bağlamayın. Önce kullanıcı akışı, yönetim ihtiyacı ve sistem bağımlılıklarını tarif edin; teknik çözüm bu gereksinimlere göre değerlendirilsin. Hazır bir platform yeterli olabilir ya da özel modül gerekebilir. Kararın gerekçesi, gelecekte yapmayı beklediğiniz değişikliklerle birlikte anlaşılır olmalıdır.
| Kapsam başlığı | Belirsiz ifade | Daha kullanışlı tarif |
|---|---|---|
| Teklif formu | Bir iletişim formu olsun. | Seçilen ürün bilgisiyle talep oluşsun; kullanıcı sonucu görsün; satış ekibi kaydı alabilsin. |
| İçerik yönetimi | Kolay güncellenebilsin. | Yetkili editör hizmet metni ve görselini tasarımı bozmadan değiştirebilsin. |
| Entegrasyon | CRM'ye bağlansın. | Alanlar eşleşsin, yinelenen kayıt davranışı ve aktarım hatasının sorumlusu belli olsun. |
| Dil yapısı | İki dil olsun. | Yayınlanacak sayfa çiftleri, çeviri sahibi ve güncelleme akışı tanımlansın. |
Tasarım beklentisini örnekleyin
Beğendiğiniz örneklerde neyi beğendiğinizi ayırın: tipografi, görsel yoğunluk, renk dağılımı, hareket, anlatım sırası veya ürün gösterimi. Bir referansın tamamını kopyalamak yerine bu tercihlerin markanızın mesajına nasıl hizmet edeceğini konuşun. Hareketli bir açılış alanı istiyorsanız metnin okunma süresi, mobil yerleşim ve hareketi azaltma davranışı da tasarım kararının parçasıdır.
Erişilebilirliği proje sonunda tek bir kontrol kutusuna bırakmayın. W3C'nin planlama kaynakları bu sorumluluğu tasarım, içerik ve geliştirme sürecine yaymak için kullanılabilir. Kapsamda erişilebilirlik hedefi, değerlendirilecek kullanıcı akışları ve doğrulama yöntemi açık olsun. “Mobil uyumlu” ifadesini de menü, formlar, uzun başlıklar ve gerçek içerikle test edilecek ekranlar şeklinde somutlaştırın.
Yayın için kabul testleri yazın
Örnek kabul testi: Ziyaretçi ürün sayfasından teklif formunu açtığında ürün adı otomatik gelmeli. Eksik zorunlu alan gönderimi durdurmalı ve hatayı ilgili alanın yanında açıklamalı. Doğru gönderimde kullanıcı onay görmeli; satış ekibi de ürün adıyla birlikte tek kayıt almalı.
Aynı testi telefonda ve masaüstünde yürütün. Bağlantı kesildiğinde, gönder düğmesine tekrar basıldığında ve kullanıcı hatayı düzelttiğinde ne olacağını kontrol edin. “Form tasarlandı” yerine bu senaryoların sonuçlarını teslim kontrolüne yazın.
- Başarılı gönderim: Kullanıcı onayı ve ekip kaydı eşleşiyor.
- Eksik alan: Anlaşılır hata mesajı var; önceki girişler korunuyor.
- Tekrar tıklama: Kullanıcıya işlem durumu gösteriliyor; yinelenen kayıt kontrol ediliyor.
- Mobil kullanım: Klavye, sabit menü ve sohbet düğmesi alanları örtmüyor.
İçerik, onay ve yayın sonrası işleri belirtin
İçerik, tasarım ve işlev onaylarını kimin vereceğini belirleyin. Birden fazla kişinin çelişen geri bildirimleri varsa bunları tek karara dönüştürecek bir sorumlu olsun. Proje sırasında yeni ihtiyaç çıkması doğaldır; yeni isteğin mevcut işe etkisini, ek bedel gerektirip gerektirmediğini ve önceliğini değerlendirecek bir yöntem yazın.
Yayın sonrasında alan adı, barındırma, yönetici hesapları, kaynak dosyaları ve kullanım eğitiminin nasıl teslim edileceğini netleştirin. Hata düzeltmesi, bakım ve yeni özellik geliştirmesi aynı iş değildir; kapsam ve süreleri ayrı tanımlansın. Son olarak ilk sürümden sonra hangi kullanım verilerinin ve kullanıcı geri bildirimlerinin inceleneceğini belirleyin. Site, yayın günü tamamlanan bir görselden çok işletmede kullanılacak bir araçtır.
- Temel kullanıcı akışı ve ilk sürüm önceliği belli mi?
- İçerik üretimi, taşıma ve çeviri sahipleri atanmış mı?
- Entegrasyonların veri akışı ve hata davranışı tarif edilmiş mi?
- Tasarım ve işlev için kontrol edilebilir kabul ölçütleri var mı?
- Onay, yeni istek ve yayın sonrası sorumluluklar yazılı mı?