Web sitesi kapsamını hedef, kullanıcı akışı, içerik, entegrasyon ve kabul ölçütleriyle hazırlayın. Ajans görüşmesinde kullanabileceğiniz kapsam tablosu.
“Modern bir web sitesi istiyoruz” tasarım yönünü konuşmaya açar, ancak proje kapsamını belirlemez. Ziyaretçi ne yapacak, içerikleri kim hazırlayacak, formdan gelen bilgi nereye gidecek ve ekip yayından sonra neyi değiştirebilecek? Bu sorular cevaplanmadan yalnızca sayfa sayısına göre alınan teklifler birbirinden farklı işleri fiyatlandırır. Kullanışlı bir kapsam, fikrinizi görünüm, işlev, içerik ve yönetim sorumluluklarıyla birlikte tarif eder. Böylece tasarım kararları da işin amacına dayanır.
1. İş hedefini ziyaretçinin yapacağı işe bağlayı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.
2. Sayfa sayısının arkasındaki içerik yapısını açın
“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.
3. Her özelliği başlangıç, sonuç ve istisnayla tarif edin
“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. |
4. Tasarım beklentisini somut davranışlarla anlatın
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.
5. Bitti denebilmesi için kabul ölçütleri yazın
Kabul ölçütü, işin nasıl kontrol edileceğini anlatır. “Form çalışacak” yerine “Başarılı gönderimden sonra kullanıcı sonucu anlayacak, ilgili ekip kaydı görecek ve başarısız gönderim anlaşılır biçimde bildirilecek” yazılabilir. Aynı yöntem arama, ürün seçimi, içerik güncelleme ve dil geçişi için de kullanılabilir.
Örnek senaryo: Bir eğitim kuruluşunun ziyaretçisi programa göre başvuru yapıyor. Tasarım onaylanmış olsa bile seçilen program bilgisi ekibe ulaşmıyorsa temel akış tamamlanmamıştır. Bu örnek, estetik kontrol ile işlev kontrolünün neden birlikte gerektiğini gösterir. Gerçek müşteri başarısı iddiası değildir. Kabul listesinde yalnızca ana sayfayı değil, bu kritik yolun tüm adımlarını doğrulayın.
6. Onayları, değişiklikleri ve yayın sonrasını kapsamın içine alın
İç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ı?