Kurumsal Web Sitesi Tasarımı Nasıl Yapılır? Süreç ve Teknik Detaylar

Kurumsal web sitesi tasarımı, çoğu firmanın sandığı gibi birkaç şık sayfa çizmekten ibaret değildir. Keşiften yayına kadar sırası bozulmaması gereken bir proje sürecidir. Bu yazıda 2012'den beri yürüttüğüm projelerde izlediğim adımları, teknik seçimleri ve sık düşülen tuzakları anlatıyorum. Amacım size bir satış vaadi değil, ajansla konuşurken elinizde tutabileceğiniz bir yol haritası vermek.

Kurumsal web sitesi tasarımı nedir ve süreç nasıl işler?

Kurumsal web sitesi tasarımı, bir şirketin kimliğini, hizmetlerini ve iletişim kanallarını tek bir çatıda toplayan sitenin keşif, site haritası, içerik, arayüz tasarımı, geliştirme, test ve yayın adımlarıyla planlı biçimde hayata geçirilmesidir. Başarılı bir projede her adım bir öncekinin çıktısına dayanır ve ölçülebilir bir iş hedefine hizmet eder.

Pratikte süreci yedi ana aşamaya bölerim. Önce keşif yaparız, ardından bilgi mimarisini kurarız. Sonra içerik ve tel kafes çizimleri gelir. Görsel tasarım onaylandıktan sonra geliştirmeye geçeriz. Son olarak test eder, yayına alır ve ilk aylarda veriyle iyileştiririz.

• Keşif ve hedef belirleme.
• Site haritası ve bilgi mimarisi.
• İçerik planı ve tel kafes (wireframe).
• Görsel tasarım ve tasarım sistemi.
• Geliştirme, CMS ve barındırma kurulumu.
• Test, kalite kontrol ve yayın.
• Yayın sonrası ölçüm ve iyileştirme.

Bu sıralama katı bir kural değildir; ancak aşamaları atladığınızda maliyet genellikle sonradan, üstelik daha yüksek olarak geri döner.

Keşif aşamasında hangi soruları netleştirmelisiniz?

Keşif, projenin en ucuz ama en çok ihmal edilen aşamasıdır. Burada yazılım yok, tasarım yok; yalnızca doğru sorular var. Örneğin sitenin kime hitap ettiğini, ziyaretçiden hangi eylemi beklediğinizi ve satış ekibinin sahada en çok hangi soruyu duyduğunu konuşuruz.

Ayrıca mevcut sitenin verisine bakarım. Search Console ve analitik hesabınız varsa hangi sayfaların trafik getirdiğini, hangi aramalarda göründüğünüzü not ederim. Bu veri, yeni site haritasında neyi koruyacağımızı belirler.

• Hedef kitle kim, karar vericiler ve etkileyiciler kimler?
• Site hangi iş sonucunu üretmeli: teklif, bayi başvurusu, işe alım, güven?
• Rakipler neyi iyi yapıyor, sizi hangi noktada ayırıyor?
• Hangi içerikler hazır, hangilerini sıfırdan yazmanız gerekiyor?
• Kim onay verecek, karar süreci kaç kişiden geçecek?

Hedef kitle tarafını derinleştirmek isterseniz hedef kitle analizi rehberime göz atabilirsiniz. Keşif sonunda iki sayfalık bir proje özeti yazarım; bu belge sonraki bütün tartışmalarda hakem görevi görür.

Projenin başarı ölçütünü baştan nasıl yazarsınız?

"Modern bir site istiyoruz" bir hedef değildir. Bu yüzden keşif toplantısından ölçülebilir bir cümle çıkarmadan tasarıma geçmem. Örneğin "teklif formundan gelen nitelikli talep sayısını izlemek" veya "bayi başvurularını tek bir formda toplamak" iyi başlangıç hedefleridir.

Hedefi yazarken üç şeyi birlikte tanımlarım: eylem, ölçüm yöntemi ve kontrol sıklığı. Eylem, ziyaretçinin yapmasını istediğiniz şeydir. Ölçüm yöntemi, bu eylemi analitik araçta hangi olayla izleyeceğinizdir. Kontrol sıklığı ise raporu kimin, ne zaman okuyacağıdır.

Bu konuyu ayrıntılı işlediğim dönüşüm hedefi yazısında örnek hedef cümleleri de bulabilirsiniz. Burada yalnızca şunu vurgulayayım: hedef, tasarım kararlarında tartışmayı bitiren cümledir. Bir tasarım öğesi hedefe hizmet etmiyorsa, ne kadar güzel olursa olsun sorgularız.

Üstelik net bir hedef, yayından sonra projenin başarılı olup olmadığını konuşurken sizi zevk tartışmasından kurtarır. Veriye bakar, karar verirsiniz.

Site haritası ve bilgi mimarisini nasıl kurarsınız?

Site haritası, sayfaların listesi ve birbirine bağlanma biçimidir. Bilgi mimarisi ise ziyaretçinin aradığını kaç tıklamada, hangi etiketle bulacağını belirler. Kurumsal sitede genellikle ana sayfa, hakkımızda, hizmet veya ürün sayfaları, referanslar, blog ve iletişim temel iskeleti oluşturur.

İlk olarak içerik envanteri çıkarırım: mevcut sitede ne var, ne işe yarıyor, neyi kaldırmalıyız. Ardından anahtar kelime araştırmasıyla her sayfaya bir ana arama niyeti atarım. Böylece iki sayfanın aynı sorguda birbirini ezmesini baştan önlersiniz. Bu eşleştirmeyi anahtar kelime haritalama yazısında adım adım anlattım.

Menü etiketlerinde şirket içi jargon yerine müşterinin kullandığı kelimeleri seçin. Örneğin "Çözümlerimiz" yerine doğrudan "Endüstriyel Soğutma Sistemleri" demek hem kullanıcıya hem arama motoruna daha net sinyal verir.

Ürün veya hizmet sayısı çoksa kategori yapısı ayrı bir çalışma ister; bunun için büyük sitelerde kategori yapısı rehberine bakabilirsiniz. Mevcut bir siteyi yeniliyorsanız, eski adreslerin tamamını bu aşamada listelemeniz gerekir, çünkü yönlendirme planı buradan doğar.

İçeriği neden tasarımdan önce hazırlamalısınız?

Tasarımı içeriğe göre yaparsınız, içeriği tasarıma göre değil. Yine de projelerin çoğunda tersini görürüm: ekip önce şablonu çizer, sonra kutulara metin sığdırmaya uğraşır. Sonuç, lorem ipsum ile onay alan ama gerçek metinle dağılan sayfalardır.

Bu nedenle tel kafes aşamasına geçmeden en az ana sayfa ve bir hizmet sayfası için gerçek metin taslağı isterim. Metin kusursuz olmak zorunda değil; ancak başlık uzunluğu, paragraf sayısı ve sık sorulan sorular belli olmalı. Böylece tasarımcı gerçek içerik yüküne göre çalışır.

İçerikte dikkat ettiğim noktalar şunlardır:

• Her sayfanın tek bir ana mesajı ve tek bir birincil eylemi olsun.
• Rakam, sertifika ve referans gibi kanıtlar metnin içinde yer alsın.
• Başlıklar arama niyetine cevap versin; slogan tek başına yetmez.
• Görseller gerçek olsun; stok fotoğrafı son çare olarak kullanın.

Arama motorları için metin yazarken dikkat edilecekleri SEO uyumlu içerik yazısında topladım. Kısacası, içerik geciktiğinde bütün proje gecikir; o yüzden içerik sorumlusunu keşifte belirleriz.

Tel kafes aşaması kurumsal web sitesi tasarımında ne işe yarar?

Tel kafes (wireframe), renksiz ve süssüz bir sayfa iskeletidir. Hangi bilginin nerede duracağını, sıralamayı ve eylem noktalarını gösterir. Renk, font ve fotoğraf tartışmasını bilerek dışarıda bırakırsınız; çünkü bu aşamada tek soru "bilgi doğru sırada mı?" sorusudur.

Kurumsal web sitesi tasarımında tel kafesi önce mobil genişlikte çizerim. Google, siteleri dizine eklerken mobil sürümü esas alır; Google Search Central'ın mobil öncelikli dizine ekleme dokümanı bunu açıkça anlatır. Dolayısıyla dar ekranda çalışan bir hiyerarşi, masaüstüne genişletildiğinde de genellikle çalışır.

Tel kafes onayında karar vericilerin hepsini aynı toplantıya almaya çalışırım. Aksi halde görsel tasarım bittikten sonra "bu bölüm neden burada?" sorusu gelir ve iş başa döner. Mobil yaklaşımın ayrıntıları için mobil öncelikli tasarım yazısına bakabilirsiniz.

Üstelik tel kafes, geliştirici için de erken bir uyarıdır. Filtre, hesaplayıcı veya bayi haritası gibi özel bileşenleri burada fark edersiniz; böylece teknik eforu tasarım bitmeden tahmin edersiniz.

Görsel tasarım ve tasarım sistemi nasıl ilerler?

Tel kafes onaylandıktan sonra marka kimliğini arayüze taşırız. Renk paleti, tipografi, ikon dili ve fotoğraf yönü burada netleşir. Elinizde güncel bir kurumsal kimlik yoksa, önce onu tamamlamanızı öneririm; aksi halde site tasarımı kimlik kararlarını üstlenmek zorunda kalır.

Ben tek tek sayfa çizmek yerine bir tasarım sistemi kurarım. Yani butonlar, form alanları, kartlar, başlık seviyeleri ve boşluk ölçüleri tek bir kütüphanede yaşar. Böylece yeni bir sayfa eklediğinizde tasarımcıya ihtiyaç duymadan tutarlı kalırsınız. Bu işi genellikle Figma'da yaparım; süreci Figma ile arayüz tasarımı yazısında ayrıca anlattım.

1. Önce ana sayfa ve bir iç sayfa için iki yön sunarım.
2. Seçilen yönü tasarım sistemine dönüştürürüm.
3. Ardından kalan şablonları bu sistemle çizerim.
4. Son olarak mobil ve masaüstü prototipi tıklanabilir hale getiririm.

Revizyon sayısını sözleşmede sınırlamak iki taraf için de sağlıklıdır. Öte yandan sınır, geri bildirimin tek elden ve toplu gelmesi şartıyla anlam kazanır.

Kurumsal web sitesi tasarımı için hangi CMS'i seçmelisiniz?

İçerik yönetim sistemi (CMS), sitenizi yayından sonra kimin, ne sıklıkla ve ne kadar kolay güncelleyeceğini belirler. Bu yüzden seçimi teknoloji modasına göre değil, ekibinizin kapasitesine ve sitenin ihtiyacına göre yaparım. Aşağıdaki tablo, sahada en sık karşılaştırdığım seçenekleri özetliyor.

Seçim yaparken şu soruyu sorarım: "Bir yıl sonra bu siteye yeni bir hizmet sayfası eklemek kaç dakika sürecek?" Cevap "ajansı aramak gerekiyor" ise yanlış CMS'i seçtiniz demektir. Ayrıca kod ve içeriğin sahipliğinin sözleşmede size ait olduğundan emin olun.

Barındırma ve alan adı kararlarını nasıl verirsiniz?

Barındırma, sitenin hızını, güvenliğini ve kesintisiz çalışmasını doğrudan etkiler. Kurumsal bir site için en ucuz paylaşımlı paketi seçmek, çoğu zaman sonradan pahalıya patlar. Öte yandan her firmanın bulut sunucu kümesine ihtiyacı da yoktur.

Seçim yaparken baktığım kriterler şunlardır:

• Sunucunun hedef kitlenize coğrafi yakınlığı veya CDN desteği.
• Otomatik ve sunucu dışında tutulan yedekler.
• Ücretsiz ve otomatik yenilenen SSL sertifikası.
• Güncel PHP veya Node sürümleri ve kolay sürüm geçişi.
• Türkçe, hızlı ve teknik bilgisi olan destek.

Alan adının kaydı mutlaka şirketinizin hesabında olmalı. Ajansın veya eski bir çalışanın hesabında duran alan adı, yıllar sonra ciddi bir kriz kaynağına dönüşebilir. Ayrıca DNS kayıtlarını yayından önce belgeleyin; özellikle kurumsal e-postayı taşıyan MX kayıtları yanlışlıkla silinirse iletişiminiz durur. Bu konuyu kurumsal e-posta altyapısı yazısında ayrıntılı ele aldım. Kayıtları kontrol etmek için DNS sorgulama aracını kullanabilirsiniz.

Geliştirme aşamasında hangi teknik standartlar şart?

Geliştirme, onaylı tasarımı çalışan koda çevirdiğiniz aşamadır. Burada görünmeyen ama sitenin ömrünü belirleyen kararları verirsiniz. Örneğin kodun sürüm kontrolünde tutulması, bir test ortamının bulunması ve canlıya aktarımın yazılı bir prosedürü olması bence pazarlık konusu değildir.

Standart olarak şu listeyi uygularım:

1. Anlamsal HTML: başlık hiyerarşisi, liste ve tablo etiketleri yerli yerinde.
2. Duyarlı yapı: her bileşeni dar ekrandan geniş ekrana test ederim.
3. Görseller modern formatta ve gerçek gösterim boyutunda olur.
4. Formlar sunucu tarafında da doğrulama yapar, spam korumasıyla çalışır.
5. Kod ve içerik yedeklerini ayrı ayrı alırım.

Görsel boyutlarını hızlıca düşürmek için resim küçültme aracını kullanabilirsiniz. Birden çok ekibin aynı büyük platform üzerinde çalıştığı durumlarda mimari seçimler daha da önem kazanır; bu senaryoyu micro frontend yazısında anlattım.

Ayrıca geliştirme sırasında haftalık kısa bir demo toplantısı yapmanızı öneririm. Böylece sorunları iş bittikten sonra değil, oluştukları hafta görürsünüz; üstelik ekibiniz de yeni panele erkenden alışır. Bu toplantılar genellikle yarım saati geçmez ama projenin en değerli kontrol noktalarından biridir.

Kısacası, geliştirme kalitesini ekran görüntüsünden anlayamazsınız. Bu yüzden ajanstan test ortamı adresi ve sürüm geçmişine erişim istemeniz makul bir taleptir.

Performans hedeflerini hangi ölçütlere göre belirlersiniz?

Hız, tasarımın sonunda eklenen bir süs değil, baştan konan bir bütçedir. Google'ın web.dev üzerinde yayımladığı Core Web Vitals ölçütleri iyi bir çerçeve sunar. Buna göre en büyük içerik boyaması (LCP) 2,5 saniye veya altında, etkileşimden sonraki boyama (INP) 200 milisaniye veya altında ve kümülatif düzen kayması (CLS) 0,1 veya altında olmalıdır.

Ayrıca web.dev, bu eşiklerin sayfa yüklemelerinin 75. yüzdelik dilimine göre değerlendirilmesini önerir. Yani yalnızca kendi hızlı bilgisayarınızda değil, gerçek kullanıcıların çoğunda iyi sonuç almanız gerekir.

Pratikte bu hedefler tasarım kararlarını etkiler. Örneğin ana sayfada otomatik oynayan büyük video, üç farklı font ailesi ve ağır kaydırma animasyonları aynı anda istenirse, eşikleri tutturmak zorlaşır. Bu çatışmayı tasarım onayından önce konuşmak, geliştirmede sürpriz yaşamaktan iyidir.

Yayın öncesi ölçüm için Lighthouse ile performans testi rehberini izleyebilirsiniz. Hızın sıralamaya etkisini ise site hızı ve SEO yazısında tartıştım.

Erişilebilirlik kurumsal sitede neden teknik bir zorunluluk?

Erişilebilirlik, görme, işitme veya hareket kısıtı olan kişilerin de sitenizi kullanabilmesidir. Aynı zamanda güneş altında telefondan bakan, tek eli dolu olan herkesin deneyimini de iyileştirir. Bu nedenle erişilebilirliği ek bir özellik değil, kalite ölçütü olarak ele alırım.

Referans olarak W3C'nin WCAG 2.2 yönergelerini kullanırım. Örneğin AA seviyesinde normal metin için en az 4,5:1 kontrast oranı gerekir. Ayrıca WCAG 2.2 ile gelen hedef boyutu kriteri, tıklanabilir öğeler için en az 24 x 24 CSS piksellik bir alan (veya yeterli boşluk) öngörür.

• Her görselin anlamlı bir alternatif metni olsun.
• Formlarda etiket, alanın içinde kaybolan yer tutucu metinle değiştirilmesin.
• Site yalnızca klavyeyle de gezilebilsin; odak göstergesi görünsün.
• Renk tek başına bilgi taşımasın; hata mesajı metinle de yazılsın.

Renk kodlarını seçerken HTML renk kodları aracından yararlanabilirsiniz. Üstelik erişilebilir yapı, arama motorlarının sayfayı anlamasını da kolaylaştırır; iki hedef burada aynı yöne çalışır.

SEO altyapısını projenin hangi aşamasında kurmalısınız?

SEO'yu yayından sonra "eklenen" bir hizmet olarak görmek, en pahalı hatalardan biridir. Çünkü URL yapısı, başlık hiyerarşisi, iç linkleme ve şablonların meta alanları geliştirme sırasında şekillenir. Sonradan değiştirmek, hem kod hem içerik tarafında ikinci bir proje açmak demektir.

Ben SEO altyapısını üç noktada kontrol ederim. Site haritası aşamasında arama niyeti ve URL planı; geliştirme aşamasında teknik etiketler; yayın öncesinde ise yönlendirme ve dizin kontrolü. Böylece her aşama bir öncekini doğrular.

• Her şablonda düzenlenebilir başlık ve açıklama alanı.
• Temiz, kısa ve Türkçe karaktersiz URL'ler.
• XML site haritası ve doğru yapılandırılmış robots.txt.
• Kurum, hizmet ve SSS için yapısal veri.

Bu işler için XML sitemap oluşturucu ve schema oluşturucu araçlarını kullanabilirsiniz. Eski bir siteyi yeniliyorsanız, sıralamaları korumak için site yenilerken SEO nasıl korunur yazısındaki adımları mutlaka uygulayın.

Formlar, KVKK ve güvenlik tarafında nelere dikkat edersiniz?

Kurumsal sitenin en değerli noktası çoğu zaman iletişim veya teklif formudur. Ancak form, kişisel veri topladığı için hukuki ve teknik sorumluluk da getirir. Türkiye'de 6698 sayılı Kişisel Verilerin Korunması Kanunu kapsamında, veriyi toplarken ilgili kişiyi aydınlatmanız gerekir.

Bu yüzden form tasarımında yalnızca alan sayısına değil, aydınlatma metnine bağlantıya, verinin nereye gittiğine ve ne kadar saklandığına da bakarım. Form verisinin yalnızca e-postaya düşmesi yerine bir kayıt sisteminde tutulması, kaybolan talepleri de önler. Hukuki metinlerin içeriği için mutlaka bir hukukçuyla çalışın.

Güvenlik tarafında temel listem şöyledir: bütün sayfalarda HTTPS, yönetim paneli için güçlü şifre ve iki adımlı doğrulama, formda bot koruması, düzenli çekirdek ve eklenti güncellemesi. Güçlü şifre üretmek için şifre oluşturucu aracını kullanabilirsiniz.

Form alanlarının sayısı ve sırası dönüşümü doğrudan etkiler. Bu konuyu randevu, teklif ve demo formu tasarımı yazısında örneklerle ele aldım.

Yayından önce test sürecini nasıl planlarsınız?

Test, geliştirme bittikten sonra kalan zamana sıkıştıracağınız bir iş değildir. Bu nedenle proje takviminde teste en az bir hafta ayırırım. Bu sürede site, gerçek içerikle ve gerçek cihazlarda denerim; müşteri tarafından da bir kişi test sorumlusu olarak atanır.

Test kapsamını dört başlıkta toplarım. Birincisi işlevsellik: formlar, menüler, filtreler ve dil geçişleri. İkincisi görünüm: farklı tarayıcı ve ekran genişlikleri. Üçüncüsü performans ve erişilebilirlik ölçümleri. Dördüncüsü ise SEO ve analitik: etiketler, yönlendirmeler ve dönüşüm olayları.

Mobil tarafı kontrol etmek için mobil uyumluluk testi rehberinden yararlanabilirsiniz. Yönlendirmelerin doğru çalıştığını görmek için ise yönlendirme denetleyicisini kullanabilirsiniz.

Bulunan hataları bir tabloda önceliğe göre sıralarım: yayını engelleyenler, ilk hafta çözülecekler ve sonraki sürüme kalanlar. Böylece test sonsuz bir düzeltme döngüsüne dönüşmez ve yayın tarihini korursunuz.

Yayın günü adım adım neler yapmalısınız?

Yayın günü sürpriz yaşamamak için bir kontrol sırası izlerim. Yayını mümkünse hafta başında, trafiğin düşük olduğu bir saatte yaparım; cuma akşamı yayın, sorun çıktığında kimsenin ulaşılamaması demektir.

1. Canlı sitenin ve veritabanının son yedeğini alın.
2. DNS değişikliğini yapın veya yeni sunucuyu yayına alın.
3. SSL sertifikasının tüm alt alan adlarında çalıştığını doğrulayın.
4. Test ortamından kalan "dizine ekleme" engelini kaldırın.
5. Eski adreslerden yeni adreslere 301 yönlendirmelerini test edin.
6. Formları gerçek bir gönderimle deneyin ve bildirimin ulaştığını görün.
7. Analitik ve dönüşüm etiketlerinin veri aldığını gerçek zamanlı raporda kontrol edin.
8. XML site haritasını Search Console'a gönderin.

Dördüncü madde en sık unutulan adımdır; test ortamındaki noindex etiketi canlıya taşınırsa site aramalardan kaybolabilir. Search Console kurulumu için Search Console rehberine bakabilirsiniz.

Yayından sonraki ilk 90 günde neleri izlersiniz?

Yayın, projenin sonu değil, ölçüm döneminin başlangıcıdır. İlk hafta teknik hataları izlerim: 404 sayfaları, form hataları ve tarama sorunları. İlk ay ise ziyaretçi davranışına bakarım: hangi sayfada çıkıyorlar, hangi eylemi yapıyorlar.

Üç aylık süreçte şu soruları sorarım:

• Keşifte yazdığımız hedef ölçülüyor mu, rakam nasıl ilerliyor?
• Eski siteye göre dizindeki sayfa sayısı ve görünürlük nasıl değişti?
• Mobil ve masaüstü dönüşüm oranları arasında belirgin fark var mı?
• Ekibiniz içeriği kendi başına güncelleyebiliyor mu?

Yeni sitelerde sıralamaların birkaç hafta dalgalanması normaldir; bu nedenle ilk günlerdeki düşüşe panikle tepki vermem. Bununla birlikte ciddi ve kalıcı bir düşüş varsa yönlendirme haritasını yeniden kontrol ederim. Ziyaretçi erken ayrılıyorsa hemen çıkma oranını düşürme yazısındaki adımları uygulayabilirsiniz.

Son olarak, içerik planı yapmadan bırakılan bir site birkaç ay içinde eskir. Bu yüzden yayın sonrası en az üç aylık bir içerik takvimi öneririm.

Kurumsal web sitesi tasarımı ne kadar sürer?

Süre, sayfa sayısına, içeriğin hazır olup olmamasına ve onay hızına bağlıdır. Aşağıdaki aralıklar orta ölçekli, 15-30 sayfalık bir kurumsal site için saha tecrübeme dayalı başlangıç aralıklarıdır; garanti değildir ve projeden projeye değişir.

Tecrübeme göre gecikmelerin çoğu teknik değil, içerik ve onay kaynaklıdır. Dolayısıyla takvimi korumanın en etkili yolu, içerik sorumlusunu ve onay yetkilisini baştan netleştirmektir.

Süreçte en sık yapılan hatalar nelerdir?

Yıllar içinde aynı hataların farklı firmalarda tekrarlandığını gördüm. Hiçbiri teknik olarak karmaşık değil; hepsi süreç disiplinine dair.

• Keşfi atlayıp doğrudan "beğendiğimiz siteler" üzerinden tasarıma başlamak.
• İçeriği son haftaya bırakmak ve lorem ipsum ile onay vermek.
• Geri bildirimi beş farklı kişiden, birbiriyle çelişen şekilde iletmek.
• Eski URL'leri listelemeden yeni siteyi yayına almak.
• Alan adı ve barındırma hesabını ajansın üzerine bırakmak.
• Analitik ve dönüşüm ölçümünü "sonra kurarız" diyerek ertelemek.

Arayüz tarafında satışı düşüren tipik hataları ise UX hataları yazısında ayrıca topladım. Kısacası, hataların çoğunu projenin ilk iki haftasında vereceğiniz kararlarla önleyebilirsiniz.

Proje ekibinde hangi roller yer almalı?

Küçük bir projede bile rolleri netleştirmek, iletişim karmaşasını önler. Ajans tarafında genellikle proje yöneticisi, tasarımcı, geliştirici ve SEO sorumlusu bulunur. Bazen bu rollerin birkaçını tek kişi üstlenir; önemli olan kimin neyden sorumlu olduğunun yazılı olmasıdır.

Sizin tarafınızda ise en az üç rol görmek isterim. Birincisi karar verici: tasarım ve kapsam konusunda son sözü söyleyen kişi. İkincisi içerik sorumlusu: metinleri, görselleri ve teknik bilgileri toplayan kişi. Üçüncüsü test sorumlusu: yayından önce siteyi gerçek bir kullanıcı gibi deneyen kişi.

• Karar verici tek kişi olsun; kurul onayı gerekiyorsa toplantı takvimini baştan planlayın.
• İçerik sorumlusunun proje süresince haftada birkaç saat ayırabilmesi gerekir.
• Test sorumlusu, satış veya müşteri hizmetlerinden biri olursa gerçek soruları daha iyi yakalar.

Örneğin genel müdürün yalnızca son hafta devreye girdiği projelerde, tasarımın büyük kısmı yeniden açılır. Bu yüzden üst yönetimi en azından keşif ve tel kafes onayına davet etmenizi öneririm.

Ajansla çalışırken sürece dair hangi soruları sormalısınız?

Teklif karşılaştırırken fiyattan önce süreci sorgulamanızı öneririm. Çünkü iki teklif arasındaki gerçek fark, genellikle hangi aşamaların dahil olduğundadır. Örneğin birinde içerik ve SEO altyapısı varken diğerinde yalnızca tasarım ve kurulum olabilir.

1. Keşif aşaması teklifin içinde mi, çıktısı ne olacak?
2. Kaç revizyon turu var ve geri bildirimi nasıl toplayacağız?
3. Kod, tasarım dosyaları ve içerik kime ait olacak?
4. Test ortamına ve sürüm geçmişine erişimim olacak mı?
5. Yönlendirme planı ve SEO kontrolü kapsamda mı?
6. Yayından sonra bakım, güncelleme ve destek nasıl işleyecek?

Bu soruların cevabı yazılı olarak teklife eklenirse, projenin ortasında kapsam tartışması yaşama ihtimaliniz azalır. Tasarım tarafında hizmet alırken sormanız gerekenleri UI/UX hizmeti almadan önce 12 kritik nokta yazısında detaylandırdım. Sanayi ve üretim firmalarına özgü ihtiyaçlar için üretim firmaları için web tasarım rehberine de bakabilirsiniz.

Benim web tasarım hizmetimde bu aşamaların tamamını aracısız yürütüyor ve her adımı kendi CRM'imde takip ediyorum. Sürecinizi konuşmak isterseniz iletişim sayfasından bana ulaşabilirsiniz.