Bir web tasarım hizmetinin kapsamı, her işletmede aynı değildir. Sayfa türleri, içerik hazırlığı, özel işlevler, entegrasyonlar ve mevcut sitenin taşınması fiyatı etkileyebilir. Ziyaretçi ilk görüşmeden önce yaklaşık bütçe düzeyini anlamak istiyorsa, web sitesindeki bir hesaplayıcı doğru soruları sorup bağlayıcı olmayan bir tahmin aralığı sunabilir. Böyle bir araç yalnızca formun yanına eklenen sayı kutusu değildir. Hangi girdinin hangi kapsam kararını değiştirdiği, hesabın neyi kapsamadığı ve sonucun kesin teklif anlamına gelmediği tasarımın parçasıdır.

İstinye Web Tasarım kapsamında hesaplayıcıyı kullanıcı deneyimi ve teklif hazırlığının parçası olarak kurgulayın. Fiyatlama kurallarını işletme doğrulasın; tasarım ekibi bunları anlaşılır sorulara ve tutarlı sonuçlara dönüştürsün. Tahminin varsayımlarını ve kesin teklif olmadığını görünür kılın.

Hesaplayıcı hangi karara yardım edecek?

İlk önce aracın hedefini belirleyin. Kullanıcı başlangıç bütçesi mi arıyor, farklı kapsamları mı karşılaştırıyor, yoksa görüşme öncesi ihtiyaçlarını mı netleştiriyor? Bunlar farklı sonuç ekranları gerektirir. “Anında kesin fiyat” sözü vermek için gerçek kapsam, maliyet ve onay kurallarının önceden belirlenmiş olması gerekir. Bu kurallar yoksa hesaplayıcı yalnızca netleştirme aracı olarak sunulmalı ve sonucu tahmin aralığı olarak etiketlemelidir.

Her soru, fiyat veya kapsam kararında bir karşılığa sahip olmalıdır. Yanıt değiştiğinde tahmin neden yükseliyor ya da düşüyor, işletme bunu açıklayabilmelidir. Bir girdi sonucu değiştirmiyorsa formda yer kaplaması için sebep yoktur. Tasarım başlamadan önce ekip, soruları ve sonuç gruplarını bir belge üzerinde eşleştirsin; böylece hesaplama görünürde çalışan fakat gerçek teklif mantığıyla ilgisiz bir oyuncak olmaz.

Girdileri kapsam başlıklarından çıkarın

Başlangıç için sayfa türü ve sayısı, özel işlev ihtiyacı, içeriklerin kim tarafından hazırlanacağı, mevcut verinin taşınıp taşınmayacağı, dil seçenekleri ve üçüncü taraf bağlantıları gibi başlıkları değerlendirebilirsiniz. Bunları her projeye otomatik olarak sormayın. Sadece işletmenin fiyatını veya iş yükünü gerçekten değiştirenleri kullanın. “Kaç sayfa?” sorusu tek başına kapsamı açıklamayabilir; bir ürün detay sayfası ile özel arama veya üyelik işlevi farklı iş kalemleri doğurabilir.

Seçenekleri müşterinin anlayacağı ifadelerle yazın. “CMS entegrasyonu” gibi teknik bir terim gerekiyorsa yanında ne anlama geldiğini açıklayın. “Birden fazla dil” seçeneğinde içerik çevirisinin mi, teknik dil altyapısının mı fiyata girdiğini belirtin. İçerik girme, metin yazımı ve çeviri ayrı hizmetlerse tek seçenekte birleştirmeyin. Her satırda dahil olan işi ve ayrıca görüşülmesi gerekenleri ayırmanız, kullanıcının kapsamı doğru anlatmasına yardım eder.

Koşullu sorularla gereksiz adımı azaltın

Bir yanıt yalnız belirli bir işlevi açıyorsa, ilgili ayrıntı sorularını o seçimden sonra gösterin. Örneğin çevrim içi satış seçildiğinde ürün, ödeme veya kargo gereksinimleri sorulabilir; kurumsal tanıtım sitesi isteyen kullanıcıya bu sorular gösterilmez. Bu dallanma, hesaplayıcıyı kısa tutarken fiyatı etkileyen bilgiyi de kaybettirmez. Her kullanıcıya bütün seçenekleri art arda sunmak, daha doğru tahmin anlamına gelmeyebilir; yalnızca daha uzun bir form yaratabilir.

Dallanmanın geri alınabildiğini de sınayın. Kullanıcı satış seçeneğini kapatırsa, önceki yanıtların sonucu nasıl etkilediği görünür olmalı. Seçeneklerin toplam tahmine etkisini açıklamak için gerektiğinde “bu seçim ek geliştirme gerektirir” gibi bir özet kullanın. Hesaplayıcıya yalnız işletme ekibinin yorumlayabildiği teknik kodlar veya gizli puanlar koymayın. İleride ağırlıklar değiştiğinde bunları kim güncelleyecek, başlangıçta belirleyin.

Fiyatlama modelini işletme doğrulamalı

Arayüz ekibi fiyatı tahmin etmemelidir. Her kapsam kategorisinin hangi iş kalemlerine dayandığını, hangi koşullarda ek değerlendirme gerektiğini ve hangi dönem için geçerli olduğunu hizmeti sunan ekip belirler. Teklifte proje bedeli, barındırma, lisans, içerik üretimi ve devam eden bakım ayrı kalemlerse hesaplayıcı da bu ayrımı yansıtmalıdır. Vergi veya üçüncü taraf ücretleri için net bilgi yoksa kullanıcıya bunları içeriyormuş gibi gösteremezsiniz.

Sonuç için sabit bir sayı, aralık ya da başlangıç düzeyi seçmek işletmenin gerçek fiyatlama politikasına bağlıdır. Bu yazı belirli bir fiyat veya evrensel formül önermiyor. Seçilen model hangi iş kalemlerini kapsıyor, hangi koşullarında geçerli ve ne zaman yeniden gözden geçiriliyor; hepsi yazılı olmalıdır. Teklif yapısı değişirse hesaplama kuralının, sonuç metninin ve yardım açıklamalarının da aynı zamanda güncellenmesi gerekir.

Tahmini tekliften açıkça ayırın

Sonuç ekranında tahminin ne olduğunu ve ne olmadığını söyleyin. “Bu aralık seçtiğiniz yanıtlar ve listelenen varsayımlar üzerinden hazırlanmıştır; kesin teklif için kapsam görüşmesi gerekir” gibi doğru bir açıklama, kullanıcıyı bağlayıcı bir fiyat aldığı yanılgısından korur. Ancak gerçek süreç bunu desteklemiyorsa ekibin daha sonra mutlaka arayacağını, belirli sürede yanıt vereceğini ya da tahminin değişmeyeceğini yazmayın.

Aralığın alt ve üst sınırının neden farklı olduğunu sade dille açıklayın. İçeriklerin hazır olup olmaması, göç edilecek veri miktarı veya harici yazılımla bağlantı gibi belirsizlikleri sıralamak sonucu daha anlamlı kılar. Her ayrıntıyı sonuç ekranına yığmayın; ana varsayımları görünür tutup teknik açıklamayı açılır bilgi alanına taşıyabilirsiniz. Kullanıcı bir seçeneği değiştirince sonuç güncelleniyorsa, hangi girdinin değiştiği ve yeni aralığın neden oluştuğu anlaşılmalıdır.

Hariçleri ve bilinmeyenleri saklamayın

Hesaplayıcının kapsamadığı işleri listeleyin: örneğin içeriği yazma, ürün fotoğrafı, özel yazılım, üçüncü taraf lisansı veya sonradan istenen bakım, ancak işletmenin teklif kuralı böyleyse hariç olarak belirtilmelidir. Gerçekte dahil olan bir hizmeti “ekstra” gibi göstererek kullanıcıyı şaşırtmayın. Girdiyle belirlenemeyen hususlar varsa tahmini daraltmak yerine ek görüşme gerektirdiğini söyleyin. Bilinmeyen bir teknik bağımlılığı otomatik puanla çözülebilir gibi sunmak güvenilir değildir.

İyi bir hesaplayıcı, yanlış kesinlik yerine ölçülü belirsizliği açık eder. Bir proje aralığının son teklife dönüşmesi için hangi bilgilerin doğrulanacağını belirtin. Örneğin mevcut siteye erişim, içerik örnekleri veya bağlantı gereksinimi görüşmede incelenebilir. Bu belgeleri ilk adımda zorunlu istemek yerine neden gerekli olduğunu açıklayın. Hassas bilgileri de yalnız gerçekten gerekiyorsa ve uygun süreç belirlenmişse alın.

Formu erişilebilir ve anlaşılır kurgulayın

Her seçeneğe açıklayıcı etiket ve gerektiğinde örnek ekleyin; zorunlu alanları görünür metinle belirtin. W3C’nin WCAG 2.2 açıklamasındaki 3.3.2 ölçütü, kullanıcı girdisi beklenen kontroller için etiket veya yönerge sağlanmasını ele alır. Otomatik saptanan giriş hatalarının metinle tanımlanması 3.3.1’de, bilinen düzeltme önerilerinin uygun olduğunda verilmesi 3.3.3’te açıklanır. Bunlar form metninin nasıl düşünülmesi gerektiğine ilişkin ölçütlerdir; hesaplayıcıyı tek başına erişilebilir kılmaz.

Bir soru atlandığında yalnız kırmızı kenarlıkla yetinmeyin; hangi yanıtın gerektiğini yazın. Sonuç güncellenirken ekran okuyucu ve klavye kullanımını test edin. İleri/geri düğmeleri, odak sırası, yanlış yanıtı değiştirme ve sonuç ekranına dönme senaryolarını sınayın. Mobilde kısa etiketlerin kesilmediğini, açılır seçeneklerin doğru çalıştığını ve kullanıcı ilerlemesini kaybetmediğini kontrol edin. Tasarım tesliminde bu senaryoları geliştirme ekibine de aktarın.

Talep devrini ve veri toplamayı sınırlayın

Kullanıcı tahmini kaydetmek veya teklif istemek isterse yalnız gerekli iletişim bilgisini sorun. Sonuç ekranını görebilmek için telefon ve e-posta vermeyi zorunlu hale getirmek işletmenin bilinçli tercihi olmalı; bunu gizlemeyin. Tahmin cevaplarını iletişim talebine ekleyin ki kullanıcı aynı bilgiyi ikinci kez yazmasın. Başvuru gönderildikten sonra hangi ekibin talebi inceleyeceği ve hangi koşulda geri dönüş yapılacağı gerçek operasyonla eşleşmelidir.

Hesaplayıcının yanıtlarını kimlerin görebildiği, ne kadar saklandığı ve pazarlama iletişimi için ayrıca onay gerekip gerekmediği süreç sahibiyle netleştirilmelidir. Bu konuda genel hukuk veya güvenlik garantisi vermeyin; işletmenin veri sorumluluğu ve uygulaması yetkin kişilerce değerlendirilmelidir. Aracın amacı kapsam belirlemekse, gereksiz kişisel veri istemek yerine ihtiyaca yönelik seçimlerle yetinin. Sonuçları raporlamak için de gerekli olandan fazla veriyi tutmayın.

Yayına almadan önce örnek senaryoları çalıştırın

En azından küçük bir tanıtım sitesi, çok sayfalı kurumsal yapı, ürün satışı ve mevcut siteden geçiş isteyen örnekler hazırlayın. Bunlar gerçek müşteri hikâyesi değil, test senaryoları olmalıdır. Her senaryoda soruların doğru sırada açıldığını, sonuç aralığının fiyat ekibinin kuralıyla örtüştüğünü, hariçlerin gösterildiğini ve teklife geçişin çalıştığını denetleyin. Beklenmeyen yanıt kombinasyonlarını da deneyin; sistemde karşılığı olmayan seçeneği sessizce sıfır bedel gibi göstermeyin.

Fiyat güncellemesinden, yeni hizmet eklenmesinden veya üçüncü taraf maliyeti değişmesinden sonra hesaplamayı tekrar doğrulayın. Sonuç kuralının sürümünü ve değişikliği onaylayan kişiyi kaydetmek eski tahminle yeni teklifin neden farklı olduğunu açıklamaya yardımcı olur. Sitedeki kullanıcı turu için yayın öncesi test rehberini kullanın. Geliştirme ekibiyle bağlantı ve bakım gereksinimlerini de aynı kapsam planına dahil edin.

İlgili rehberlerle birlikte planlayın

Web tasarım ve yazılım hizmeti, hesaplayıcı gibi özel işlevlerin proje kapsamına alınacağı ana hizmettir. Ziyaretçiden hangi bilgilerin isteneceği için web sitesi form tasarımı rehberini, tahminin gerçek teklif karşılığını nasıl anlatacağınız için web tasarım tekliflerini karşılaştırma rehberini inceleyin. Teklif gönderiminin satışla aynı şey olmadığını izlemek için form ve satış ölçümü rehberi de yararlıdır. Bir bağlantı, işlevin çalıştığını veya fiyat politikanızın doğrulandığını tek başına göstermez.

Sık sorulan sorular

Web sitesi fiyat hesaplayıcısı kesin teklif verebilir mi?

Yalnız işletmenin kapsam ve fiyat kuralları tüm yanıtlar için doğrulanmışsa ve teklif süreci bunu destekliyorsa kesin fiyat gösterilebilir. Değişken projelerde tahmin aralığı daha uygun olabilir. Sonuçta varsayımları, dahil olan işleri ve görüşmede netleşecek noktaları açıklayın.

Bir hesaplayıcıda hangi sorular bulunmalı?

Yalnız fiyatı veya proje kapsamını değiştiren soruları ekleyin. Sayfa türleri, işlevler, içerik sorumluluğu, veri taşıma ve entegrasyonlar bazı projelerde önemlidir. Seçenekleri hizmet ekibiyle doğrulayın; teknik terimleri açıklayın ve sonucu değiştirmeyen soruları çıkarın.

Sayfa sayısı web sitesi fiyatını tek başına belirler mi?

Hayır. İçerik, özel işlev, veri taşıma, entegrasyon ve devam eden sorumluluklar da işi değiştirebilir. Yalnız sayfa adedine bağlı araç eksik resim verebilir. Fiyat kuralını işletme belirlemeli; bilinmeyen işleri ayrıca görüşülecek olarak göstermelidir.

Tahmini aralık nasıl açıklanmalı?

Aralığın hangi yanıtlara dayandığını, neleri kapsadığını ve kesin teklif için nelerin doğrulanacağını yazın. Alt ve üst sınırın neden değişebileceğini anlaşılır örneklerle belirtin. Gerçek kuralda karşılığı olmayan gerekçe eklemeyin; tahminin bağlayıcı olmadığını görünür tutun.

Kişisel bilgiyi hesaplamayı görmek için zorunlu istemeli miyim?

Bu, işletmenin ticari tercihi ve veri sürecine bağlıdır; teknik gereklilikmiş gibi sunulmamalıdır. Sonuç iletişim bilgisi olmadan gösterilebiliyorsa, tahmin görme ve teklif isteme seçeneklerini ayırabilirsiniz. Bilgi isteniyorsa nedenini açıklayın, gereksiz alan eklemeyin.

Fiyat kuralı değiştiğinde hesaplayıcıyı kim günceller?

Fiyatı ve kapsamı doğrulayan işletme değişikliği onaylamalı; web ekibi kuralı, yardım metnini ve sonuç ekranını birlikte güncellemelidir. Değişiklik tarihini kaydedin ve yeni seçenekler sonrası eski yanıt kombinasyonlarını yeniden test edin. Güncel olmayan hesaplayıcıyı yayında bırakmayın.

Hata mesajlarında ne gösterilmeli?

Hangi alanın eksik veya geçersiz olduğunu metinle belirtin ve biliniyorsa düzeltme yolunu gösterin. W3C WCAG 2.2’nin 3.3.1 ve 3.3.3 ölçütleri otomatik saptanan hatanın tanımı ve uygun düzeltme önerisiyle ilgilidir. Bu, tüm erişilebilirlik testinin yerine geçmez.

Hesaplayıcının doğru çalıştığını nasıl test ederim?

Fiyat ekibinin onayladığı farklı kapsam senaryolarında soruları, tahmin aralığını, hariçleri ve talep aktarımını kontrol edin. Uç durumlarda yanlışlıkla sıfır veya kesin fiyat üretilmediğini sınayın. Klavye, mobil, hata düzeltme ve fiyat kuralı değişikliği sonrası tekrar test de gerekir.