Kurumsal Web Sitesi Yaptırmadan Önce Hazırlanması Gerekenler

Kurumsal web sitesi projesi, ana sayfanın nasıl görüneceğine karar vermeden önce başlar. Markanın ne sunduğu, kime hitap ettiği, ziyaretçinin hangi sorularla geleceği ve sitede ne yapacağı net değilse tasarım süreci sürekli değişen beklentilerle ilerler. Güçlü bir başlangıç, tasarımcıya çok sayıda referans göndermekten önce işletmenin ihtiyacını anlaşılır hâle getirmektir.

Bu rehber; yeni bir kurumsal site yaptıracak, mevcut sitesini yenileyecek veya yalnızca arayüz tasarımı için destek alacak markalara yöneliktir. Teknik terimleri ezberlemeniz gerekmez. Proje hedefini, içerikleri, sorumlulukları ve teslim beklentisini netleştirmeniz yeterlidir. Aşağıdaki hazırlıklar, daha sağlıklı teklif almanıza ve tasarım kararlarını gerçek ihtiyaçlar üzerinden değerlendirmenize yardımcı olur.

Sitenin birincil amacını bir cümleyle yazın

“Daha modern bir site istiyoruz” iyi bir başlangıç hissidir, fakat proje hedefi olarak belirsizdir. Modern görünümün işletmeye hangi konuda yardımcı olmasını bekliyorsunuz? Hizmetlerin anlaşılmasını, doğru kişilerin teklif istemesini, ürünlerin incelenmesini veya mevcut müşterilerin bir işlemi tamamlamasını mı? Bu amaçlar birlikte bulunabilir; yine de öncelikli olanı belirlemek gerekir.

Örneğin bir mühendislik firmasının hedefi, uzmanlık alanlarını ve proje deneyimini anlatarak uygun teklif talepleri almak olabilir. Bir teknik servis platformunda ise hizmet seçimi ve randevu adımlarının anlaşılması öne çıkabilir. Hedef farklı olduğunda ana sayfanın bilgi sırası, gezinme yapısı ve iletişim çağrıları da değişir. Aynı görsel şablon iki işletmenin ihtiyacını aynı ölçüde karşılamayabilir.

Birincil hedefin yanına iki destekleyici amaç yazın. “Teklif talebi almak” ana hedefse, “hizmet kapsamını açıklamak” ve “ilgili projeleri göstermek” onu destekleyebilir. Bu kısa liste, proje boyunca yeni bir bölüm veya özellik istendiğinde karar vermenizi kolaylaştırır. Eklenen şeyin hedefe katkısı açıklanamıyorsa sonraki aşamaya bırakılması değerlendirilebilir.

Hedef ziyaretçiyi ve sorularını tanımlayın

Bir kurumsal siteyi işletmenin iç organizasyonuna göre kurmak kolaydır. Ancak ziyaretçi departman isimlerinizi, kullandığınız kısaltmaları veya hizmetler arasındaki ayrımı bilmeyebilir. İçerik yapısı, işletmenin kendini nasıl sınıflandırdığından çok ziyaretçinin neyi anlamaya çalıştığını dikkate almalıdır. Bu nedenle müşteri görüşmelerinde tekrar eden sorular önemli bir başlangıç kaynağıdır.

Son dönemde gelen teklif taleplerini düşünün. İnsanlar ilk olarak fiyatı mı soruyor, çalışma kapsamını mı anlamaya çalışıyor, benzer bir projede deneyiminiz olup olmadığını mı öğrenmek istiyor? Hangi müşterilerin size uygun olmadığını da not edin. Site hem doğru kişiye yardımcı olmalı hem de sunmadığınız bir hizmet için yanlış beklenti oluşturmamalıdır.

İki veya üç temel ziyaretçi senaryosu yeterli olabilir. “Hizmeti ilk kez araştıran kişi”, “alternatifleri karşılaştıran satın alma sorumlusu” ve “daha önce çalıştığınız, yeniden iletişime geçmek isteyen müşteri” farklı bilgi ihtiyaçları taşır. Her senaryo için başlangıç sayfası, görmek istediği kanıt ve olası sonraki adım yazılabilir. Bunlar kullanıcı deneyimi, yani UX kararlarının somut zeminidir.

Mevcut siteniz varsa önce envanter çıkarın

Yenileme projesinde eski siteyi yalnızca görsel olarak değerlendirmeyin. Hangi sayfaların ziyaret aldığını, hangi bağlantıların başka yerlerde paylaşıldığını ve hangi içeriklerin güncel kaldığını belirleyin. İyi çalışan bir hizmet sayfasının adresini gereksiz yere değiştirmek, yeni görünümden bağımsız bir geçiş sorunu yaratabilir. Mevcut yapının güçlü ve zayıf taraflarını ayrı ayrı görmek gerekir.

Hazırlık listesine mevcut alan adını, sayfa adreslerini, önemli formları, kullanılan e-posta adreslerini ve bağlı sistemleri ekleyin. Search Console ve ziyaret ölçüm verisi varsa sayfa ve sorgu düzeyinde inceleme için erişim planlanabilir. Bu erişimleri herkese açık belgelerde paylaşmayın; proje başladığında ilgili kişilere uygun yetkiyle verin.

İçerik envanterindeki her sayfayı korunacak, güncellenecek, birleştirilecek veya kaldırılması değerlendirilecek olarak işaretleyebilirsiniz. Bu kararlar, geliştirme sonunda aceleyle verilmemelidir. Özellikle eski bağlantıların yeni sayfalara nasıl karşılık geleceği tasarlanırsa hem kullanıcılar hem de arama motorları açısından daha düzenli bir geçiş hazırlanabilir.

Sayfa listesini içerikle birlikte düşünün

“Beş sayfalık site” tanımı tek başına yeterli kapsam değildir. Tek bir hizmet sayfasının içeriği ve işlevi, başka bir projedeki beş basit sayfadan daha kapsamlı olabilir. Ana sayfa, hakkımızda, hizmetler, projeler ve iletişim gibi başlıkların her birinin ne anlatacağını kısa cümlelerle açıklayın. Alt hizmetlerin ayrı sayfa gerektirip gerektirmediğini değerlendirin.

Bir hizmet sayfası için şu içerikler başlangıç olabilir: kime uygun olduğu, hangi ihtiyacı karşıladığı, nelerin teslim edildiği, nasıl çalışıldığı, ilgili proje örnekleri ve sık sorulan sorular. Her başlığın ayrı bir sayfaya dönüşmesi gerekmez. Kullanıcının aynı kararı verebilmesi için birlikte görmesi gereken bilgileri bölmek, gezinmeyi gereksiz yere zorlaştırabilir.

Çok dilli site istiyorsanız içerik kapsamını dil bazında yazın. Bütün sayfalar çevrilecek mi, yalnızca belirli hizmetler mi sunulacak? Çeviriyi kim sağlayacak ve güncellemeler iki dilde nasıl sürdürülecek? İkinci dil, menüye bayrak eklemekten daha geniş bir içerik ve bakım sorumluluğudur. Hazırlık aşamasında bu soruları yanıtlamak teklifin gerçek kapsamını ortaya çıkarır.

Metinleri tasarımdan tamamen sonraya bırakmayın

Tasarımın yalnızca örnek metinlerle onaylanması, gerçek içerik yerleştiğinde sorun çıkarabilir. Hizmet başlığı beklenenden uzundur, ürün listesi büyümüştür veya önemli bir açıklama için alan ayrılmamıştır. Bütün metinlerin kusursuz olması şart değildir; fakat gerçek başlıklar, yaklaşık içerik uzunluğu ve temel mesajlar tasarım öncesinde belli olmalıdır.

Her sayfa için bir içerik sorumlusu belirleyin. Özellikle teknik hizmet bilgilerini işletme içinde doğrulayabilecek kişi önemlidir. Tasarımcı metni daha anlaşılır sunabilir, ancak işletmenin vermediği bir hizmeti veya doğrulanmamış bir başarıyı kendi başına üretmemelidir. İçeriğin doğruluğu ile anlatım biçiminin iyileştirilmesi farklı sorumluluklardır.

Markanızın dili için birkaç örnek yazın. Resmî ama anlaşılır bir ton mu, daha doğrudan ve sıcak bir anlatım mı istiyorsunuz? Kullanılmaması gereken ifadeleri de paylaşın. Aynı hizmetin farklı bölümlerde farklı adlarla anılması, ziyaretçinin kapsamı anlamasını zorlaştırır. Tutarlı isimlendirme hem tasarım hem de sonraki içerik yönetimi için işinizi kolaylaştırır.

Marka ve görsel dosyalarını düzenleyin

Logo, renkler, yazı tipleri ve fotoğraflar tek bir güncel klasörde bulunmalıdır. Logonun mümkünse uygun vektör sürümünü, açık ve koyu zemin kullanımını, varsa kurumsal kimlik rehberini paylaşın. Hangi dosyanın güncel olduğunu açıklamak, tasarımın eski bir marka sürümüyle başlamasını önler. Eksik marka öğeleri varsa bunların proje içinde hazırlanıp hazırlanmayacağı konuşulmalıdır.

Fotoğraf seçerken yalnızca çözünürlüğe değil, içeriğin doğru kişiyi, ürünü veya mekânı temsil etmesine de bakın. Gerçek ekibin fotoğrafı yerine genel bir stok görsel kullanmak bazı sayfalarda istenen güveni vermeyebilir. Henüz görseli olmayan hizmetler için çekim, illüstrasyon, mevcut arşiv veya başka bir üretim ihtiyacı ayrı planlanabilir.

Görsellerin nerede kullanılacağı da önemlidir. Aynı fotoğraf geniş bir ana sayfa alanında ve dar bir mobil kartta farklı biçimde kırpılır. Kritik ürün ayrıntıları kenarda kalıyorsa uygun alternatif gerekebilir. web.dev'in görsel performansı rehberi, görsellerin yüklenme deneyimindeki rolünü açıklar. Üretim aşamasında doğru boyut ve sıkıştırma da görsel seçimi kadar dikkate alınmalıdır.

İşlevleri görünümden ayrı listeleyin

Bir sitenin ne göstereceği ile ne yapacağı farklı sorulardır. Teklif formu, randevu akışı, kullanıcı hesabı, ödeme, ürün filtreleme, dosya yükleme ve başka sistemlerle veri alışverişi farklı geliştirme ihtiyaçları oluşturur. Bu özelliklerin yalnızca ekranda görünmesiyle gerçekten çalışması arasında önemli kapsam farkı vardır.

Her özellik için basit bir kullanım senaryosu yazın. Örneğin “Ziyaretçi hizmet seçer, iletişim bilgilerini bırakır, talep belirlenen adrese ulaşır ve kullanıcı sonucu ekranda görür.” Ardından başarısız durumları düşünün: eksik bilgi varsa ne olacak, gönderim başarısız olursa ne gösterilecek, dosya çok büyükse kullanıcı ne yapacak? Bu sorular teknik ayrıntıdan çok deneyimin tamamlanmasıyla ilgilidir.

Haricî bir CRM, randevu sistemi veya ödeme sağlayıcısı kullanılacaksa mevcut sistemi ve erişim sorumlusunu belirtin. Entegrasyonun mümkün olup olmadığı ilgili hizmetin koşullarına ve teknik olanaklarına bağlıdır. Proje teklifinde hangi bağlantıların dahil olduğu açıkça yazılmalıdır. “Gerekirse sonra bağlarız” yaklaşımı, bütçe ve takvim üzerinde sonradan belirsizlik yaratabilir.

UI tasarımı, UX ve geliştirme kapsamını ayırın

UX, ziyaretçinin amacına ulaşacağı akışı ve bilgi düzenini ele alır. UI ise bu deneyimin ekran üzerindeki görsel arayüzüdür. Geliştirme, tasarımın çalışan bir siteye dönüşmesini sağlar. Bunlar birbirini etkiler, ancak tekliflerde hepsinin birlikte sunulduğu varsayılmamalıdır. Bazı projelerde yalnızca arayüz ve geliştiriciye teslim dosyaları hazırlanır.

Tasarım hizmeti alıyorsanız hangi ekranların, mobil durumların, bileşenlerin ve etkileşim açıklamalarının teslim edileceğini sorun. Geliştirme de dahilse içerik yönetimi, form gönderimi, yayın ortamı ve son kontrollerin kapsamını öğrenin. Web tasarım ve yazılım hizmeti bu ihtiyaçların birlikte konuşulabileceği başlangıç noktasıdır; proje özelinde görevler ayrıca netleştirilir.

Portfolyodaki rol açıklamaları bu ayrımı anlamanıza yardımcı olur. KonutKonfor web UI/UX projesi, hizmet seçimi, randevu ve ödeme adımlarının tasarımına odaklanır. Bu örnekte anlatılan tasarım katkısını, ayrıca doğrulanmamış yazılım geliştirme veya ticari başarı iddiası olarak yorumlamamak gerekir. Bir projeyi değerlendirirken tasarımcının tam olarak ne yaptığını okuyun.

Tasarım, yazılım ve yayın sorumluluklarını yan yana yazın

Aşağıdaki matris teklif görüşmesinde doldurulacak bir görev ayrımıdır. Her satırın sorumlusunu ve teslim koşulunu yazın; UI/UX tasarımı satın almak geliştirme, barındırma veya bakımın otomatik olarak dahil olduğu anlamına gelmez.

Teklifte bir satır boş kaldığında onun varsayılan olarak tasarımcıya veya geliştiriciye ait olduğunu düşünmeyin. Örneğin ödeme ekranının Figma'da görünmesi, ödeme sağlayıcısının bağlandığını göstermez. Önce tasarım teslimini, sonra çalışan sistemin kabul koşulunu ayrı tarif edin.

KonutKonfor ve Garantili Oto Servis arayüz örneklerinde kullanıcı akışlarını inceleyebilirsiniz. Yazılım sorumluluğunu portfolyo ekranından çıkarmak yerine proje rolünden ve kendi teklifinizden doğrulayın.

Mobil deneyimi baştan kapsamın içine alın

Masaüstündeki bütün öğeleri küçültmek, kullanılabilir bir mobil arayüz üretmeyebilir. Menü, uzun başlıklar, karşılaştırma tabloları, formlar ve görsel sıralaması daha küçük ekranlarda farklı kararlar gerektirir. Mobil tasarımın proje sonunda otomatik çözüleceğini varsaymak yerine, kritik sayfa ve akışları baştan belirleyin.

Özellikle iletişim kurma adımını telefonda düşünün. Ziyaretçi numarayı kopyalamak zorunda mı, WhatsApp bağlantısını kolayca bulabiliyor mu, form alanları anlaşılır mı? Kullanıcı bir hata yaptığında açıklama görebilmeli ve yazdıklarını kaybetmeden düzeltebilmelidir. Bunlar yalnızca görsel ayrıntı değil, sitenin gerçek kullanımını etkileyen kararlardır.

Mobil incelemede yalnızca ana sayfaya bakmayın. Hizmet ayrıntısı, proje sayfası ve iletişim akışı birlikte test edilmelidir. Bir kişi arama sonucundan doğrudan alt sayfaya girebilir. O sayfanın marka hakkında yeterli bağlam sunması ve sonraki adımı anlaşılır göstermesi gerekir. Ziyaretçinin önce ana sayfayı okuyacağını varsayarak içerik yazmak bu nedenle eksik kalır.

Erişilebilirliği proje sonuna bırakmayın

Okunaklı metin, belirgin bağlantılar, anlaşılır form etiketleri ve klavyeyle kullanım birçok ziyaretçinin deneyimini etkiler. Görsel olarak etkileyici bir arayüz, temel bilgileri fark etmeyi zorlaştırıyorsa amacına hizmet etmeyebilir. Renk, hareket ve etkileşim kararları yalnızca estetik açıdan değerlendirilmemelidir.

W3C'nin erişilebilirlik planlama yaklaşımı, erişilebilirliğin proje boyunca sorumluluk ve kontrol gerektirdiğini vurgular. Hazırlık aşamasında hangi beklentilerin bulunduğu, kimlerin değerlendirme yapacağı ve sorunların nasıl giderileceği konuşulabilir. Tek bir otomatik araç sonucu, bütün deneyimin erişilebilir olduğunu kanıtlamaz; gerçek kullanım senaryoları da incelenmelidir.

İşletme açısından basit sorularla başlayabilirsiniz: Önemli bilgi yalnızca renkle mi anlatılıyor, görselin içindeki metnin başka bir karşılığı var mı, formun hangi alanının hatalı olduğu anlaşılabiliyor mu? Video kullanılıyorsa altyazı veya yazılı açıklama ihtiyacını değerlendirin. Bu hazırlıklar, sonradan tasarımın temelini değiştirmeyi gerektiren sorunları azaltabilir.

Google görünürlüğünü içerik planına bağlayın

SEO'yu site bittikten sonra eklenecek birkaç anahtar kelime olarak düşünmeyin. Hizmetlerin ayrı ve anlaşılır biçimde açıklanması, ilgili projelerle desteklenmesi, sayfa başlıklarının içeriği doğru anlatması ve bağlantıların takip edilebilir olması başlangıçtan itibaren ele alınabilir. Google'ın SEO başlangıç rehberi, arama motorlarının içeriği keşfetmesi ve anlaması için bu temel yaklaşımı açıklar.

Hazırlık sırasında müşterilerinizin kullandığı dili toplayın. İşletme içinde “entegre çözüm” dediğiniz hizmeti müşteriler daha somut bir adla arıyor olabilir. Mevcut Search Console verisi varsa gerçek sorgular incelenebilir. Veri yoksa ilk kelime listesi bir çalışma hipotezidir; arama hacmi veya sıralama beklentisi ölçülmüş gibi sunulmamalıdır.

Yenileme projesinde mevcut adresler, yönlendirmeler ve indeksleme tercihleri ayrıca planlanmalıdır. Yayın sonrası sitemap ve sayfaların erişilebilirliği kontrol edilebilir. Ancak teknik koşulların sağlanması, her sayfanın hemen indeksleneceği veya belirli sırada görüneceği anlamına gelmez. SEO hedefini zaman içinde gözlenen görünürlük ve ilgili ziyaretlerle değerlendirmek gerekir.

Alan adı, erişimler ve içerik yönetimini netleştirin

Alan adının kimde kayıtlı olduğunu, barındırma hizmetini kimin yönettiğini ve kurumsal e-postaların hangi sistemde çalıştığını belirleyin. Yeni site yayına alınırken e-posta hizmetinin istemeden etkilenmemesi gerekir. Hesap sahipliği ve teknik erişim sorumlulukları, proje başlamadan görünür olmalıdır. Şifreleri ortak bir sunumun içine yazmak yerine güvenli yetkilendirme yöntemi kullanın.

Sitenin hangi bölümlerini kendiniz güncellemek istediğinizi de listeleyin. Blog eklemek, proje yayınlamak, ekip bilgisi değiştirmek veya hizmet açıklaması düzenlemek aynı içerik yönetimi ihtiyacını oluşturmaz. Panelin varlığından çok, işletmenizin gerçekten yapacağı işleri destekleyip desteklemediği önemlidir. İlgili kişinin paneli kullanmayı öğrenmesi de teslim planında yer almalıdır.

Bakım konusunu ayrıca konuşun. Yayından sonra içerik değişiklikleri, teknik güncellemeler, yedekleme ve sorun bildirimi için kim sorumlu olacak? Bu görevlerin proje ücretine dahil olup olmadığı veya ayrı yürütülüp yürütülmeyeceği yazılı biçimde açıklansın. Siteyi teslim almakla işletmenin dijital operasyonunu sürdürebilmesi arasında böyle bir sorumluluk köprüsü gerekir.

Takvimi onay ve içerik hazırlığıyla birlikte kurun

Teslim tarihi yalnızca tasarım ve geliştirme günlerinin toplamı değildir. İçeriklerin hazırlanması, kararların verilmesi, revizyonların değerlendirilmesi ve dış sistemlerden beklenen bilgiler de süreyi etkiler. Lansman günü belliyse bunu ilk görüşmede paylaşın. Aynı tarihe ulaşmak için hangi kapsamın gerçekçi olduğu birlikte değerlendirilebilir.

Onay verecek kişileri ve son karar sorumlusunu belirleyin. Ana sayfa üzerinde beş farklı kişinin birbirinden habersiz yorum yapması işi uzatabilir. Geri bildirimlerin tek yerde toplanması ve önceliklendirilmesi, tasarımcının neyi neden değiştireceğini anlamasını sağlar. Onaylanan bir aşamaya sonradan dönüldüğünde takvim ve kapsam etkisi yeniden konuşulmalıdır.

Örnek bir sıra; proje özeti ve içerik planı, bilgi mimarisi, temel ekranlar, mobil uyarlamalar, geliştirme, içerik girişi ve yayın kontrolleri olabilir. Her proje aynı sırayı birebir izlemek zorunda değildir. Önemli olan aşamaların görünür olması ve bir sonraki aşamaya geçmek için hangi kararların gerektiğinin bilinmesidir.

Teklifleri aynı kapsam üzerinden karşılaştırın

İki teklif arasında fiyat farkı varsa önce teslim listelerini yan yana koyun. Biri metin hazırlığını, mobil ekranları, içerik yönetimini ve yayın desteğini içerirken diğeri yalnızca tasarım dosyası veriyor olabilir. Sayfa adedi tek başına bu farkı açıklamaz. Revizyon, entegrasyon, lisans ve bakım kalemleri de karşılaştırmaya dahil edilmelidir.

İşletmeniz için zorunlu olanlarla sonraya bırakılabilecekleri ayırın. İlk sürümde ihtiyaç duyulmayan bir üyelik sistemi yerine güçlü hizmet sayfaları ve çalışan iletişim akışı öncelikli olabilir. Bütçe görüşmesinde bu ayrımı paylaşmak, yalnızca daha düşük fiyat istemekten daha yapıcı bir kapsam tartışması sağlar. Böylece neyin hangi nedenle ertelendiğini de bilirsiniz.

Tasarımcıya göndereceğiniz dosyada hedef, ziyaretçi grupları, sayfa listesi, içerik durumu, gerekli özellikler, referanslar, bütçe çerçevesi ve tarih beklentisi bulunabilir. Garantili Oto Servis projesindeki hizmet ve paket karşılaştırma akışı gibi ilgili örnekleri işaretleyerek hangi yaklaşımı beğendiğinizi anlatın. Görseli kopyalamayı değil, çözdüğü ihtiyacı konuşmayı hedefleyin.

Yayına çıkmadan önce kabul ölçütlerini belirleyin

Projeyi hangi koşullarda tamamlanmış sayacağınızı baştan konuşun. Sayfaların açılması, menünün çalışması ve görsellerin görünmesi temel kontrollerdir; fakat iletişim formunun doğru alıcıya ulaşması, mobil akışların kullanılabilmesi ve içeriklerin doğrulanması da gerekir. Test listesi, teklif kapsamındaki gerçek özelliklerle eşleşmelidir.

Örneğin WhatsApp bağlantısının doğru hatta gitmesi, form sonucunun kullanıcıya gösterilmesi, hatalı girişlerin açıklanması ve kritik sayfaların arama motorlarına açık olması kontrol edilebilir. Analitik olayların kaydedilmesi de ayrı bir adımdır. Tıklama, gönderim ve gerçek müşteri görüşmesi farklı aşamalardır; raporda bunların birbirine karıştırılmaması gerekir.

Son olarak alan adı, panel, kaynak dosyalar ve kullanım açıklamalarının teslim durumunu kontrol edin. Yayın sonrası ilk değerlendirme zamanını belirleyin. Yeni sitenin gerçek ziyaretçilerle nasıl kullanıldığını görmek, sonraki iyileştirmeler için daha sağlam veri oluşturur. İlk sürümün her olasılığı çözmesi yerine, açık hedeflerle çalışması ve geliştirilebilir olması daha gerçekçi bir yaklaşımdır.

Hazırlığınızı projeye dönüştürün

Kurumsal web sitesi yaptırmadan önce en değerli hazırlık; ne anlatacağınızı, kime hitap edeceğinizi ve ziyaretçiden hangi adımı beklediğinizi açıklamaktır. Dosyalar, içerikler, işlevler ve sorumluluklar bu çerçeveyi destekler. Böyle bir başlangıçta tasarım görüşmesi yalnızca renk ve beğeni üzerinden ilerlemez; işletmenizin ihtiyacıyla ilişkilendirilebilir.

Mevcut sitenizi, öncelikli hizmetlerinizi ve değiştirmek istediğiniz noktaları paylaşarak başlayabilirsiniz. Web/UI-UX çalışmalarını ve hizmet kapsamını inceleyebilir, ardından iletişim sayfasından proje özetinizi iletebilirsiniz. Bütün soruların yanıtını önceden bilmeniz gerekmez; amaç, doğru sorularla başlayan ve teslim beklentisi netleşen bir çalışma kurmaktır.