Kurumsal web sitesiyle e-ticaret mağazasını aynı projede planlamak için önce ziyaretçinin iki ayrı işini tanımlayın: işletmeye güvenmek ve uygun ürünü satın almak. Ardından bu yolların nerede birleşeceğini, hangi verileri paylaşacağını ve kim tarafından yönetileceğini belirleyin. Tasarım, ürün kataloğu, ödeme, içerik ve ölçüm bu kararların ardından ilerlemelidir. Ana sayfayı çizerek başlayıp satış akışını sonradan eklemek, proje sonunda hem menüyü hem kapsamı yeniden açmanıza neden olabilir.
Bu rehber, markasını anlatan bir siteyi çevrim içi satışla birleştiren işletmeler ve mevcut kurumsal sitesine mağaza eklemek isteyen ekipler için hazırlanmıştır. Amaç belirli bir altyapıyı herkese önermek değil; ajans teklifini, şirket içi hazırlıkları ve yayın kararını aynı sorularla değerlendirebilmektir.
Önce iki kullanıcı yolunu kâğıda dökün
İlk yol, işletmeyi tanımak isteyen ziyaretçidir. Üretim kapasitesini, hizmetleri, çalışma biçimini veya iletişim kurulacak kişiyi arar. İkinci yol, satın almak istediği ürün hakkında karar vermeye çalışan ziyaretçidir. Ölçü, uyumluluk, stok, teslimat ve toplam ödeme bilgisine ihtiyaç duyar. Aynı kişi farklı zamanlarda iki yolu da kullanabilir; bu nedenle yolları birbirinden koparmak da her şeyi tek sayfaya toplamak da iyi bir başlangıç değildir.
Her yol için bir başlangıç ve bir tamamlanma noktası yazın. Örneğin hizmet sayfasından uygun teklif formuna ulaşmak bir kurumsal yol olabilir. Kategori sayfasından doğru varyantı seçerek siparişi tamamlamak ise alışveriş yoludur. “Siteyi gezsin” hedefi, hangi içeriğin veya işlevin öncelikli olduğunu belirlemek için yeterince açık değildir.
Satış ekibinin son dönemde yanıtladığı sorular bu çalışmaya malzeme sağlar. “Toplu alım yapabilir miyim?”, “Bu ürün bana uygun mu?” ve “Üretici siz misiniz?” aynı sayfada aynı ağırlıkla ele alınmak zorunda değildir. Soruyu doğru sayfaya yerleştirin; ilgili başka bilgiye doğal bir bağlantı verin. Böylece menü şirketin departman şemasına göre değil, ziyaretçinin işi üzerinden oluşur.
Tek altyapı mı, birbirine bağlı iki sistem mi?
Az sayıda kurumsal sayfa, standart ürün kataloğu ve benzer yayın ihtiyaçları varsa ortak bir içerik ve ticaret altyapısı yönetimi kolaylaştırabilir. Ürün güncelleyen ekibin aynı ortamda marka sayfalarını düzenleyebilmesi yararlı olabilir. Ancak kolay yönetim varsayımını gerçek bir denemeyle sınayın: ekip bir ürün varyantını, bir kampanya metnini ve bir hizmet sayfasını yardım almadan güncelleyebiliyor mu?
Mevcut kurumsal sistemin kapsamlı yayın süreçleri veya özel iş uygulamaları varsa ayrı mağaza sistemi daha uygun olabilir. Bunun karşılığında menü tutarlılığı, arama, oturumlar, ölçüm ve iki sistemin bakımı için ek çalışma doğar. İki ayrı sistem kullanmak kendiliğinden kötü bir karar değildir; bakım yükü ve ziyaretçi geçişleri teklifin içinde açıkça yer almalıdır.
Başsız ticaret gibi daha özel mimariler, hazır yapının karşılayamadığı somut bir ihtiyaç bulunduğunda değerlendirilmelidir. Yalnızca daha esnek göründüğü için seçilen bir yapı, yayın ekibinin her değişiklikte geliştiriciye bağımlı kalmasına yol açabilir. Kararı tasarım özgürlüğü, ürün yönetimi, entegrasyon, bakım kapasitesi ve toplam sahip olma maliyeti birlikte belirlemelidir.
Alan adı, alt alan adı veya klasör kararı da bu incelemenin parçasıdır. Bunlardan birini bütün işletmeler için otomatik SEO avantajı gibi sunmayın. Önce mevcut adresleri, teknik sınırlamaları, dil yapısını ve ekip sorumluluklarını değerlendirin. Shopify düşünülüyorsa mağaza açmadan önce verilmesi gereken kararlar, altyapı seçimini operasyon hazırlığıyla birlikte ele almanıza yardımcı olur.
Kapsamı sayfa adediyle değil, teslimlerle tanımlayın
“On sayfalık web sitesi ve mağaza” ifadesi çalışmanın büyüklüğünü açıklamaz. Tek ürün şablonu yüzlerce ürünü gösterebilir; fakat ürün verilerini hazırlama, aktarma ve kontrol etme işi ayrıca vardır. Aynı şekilde bir teklif formu, alan sayısı az olsa da farklı ekiplere yönlendirme veya dosya ekleme gerektiriyorsa önemli bir iş paketi olabilir.
Teklifte en az şu teslimleri ayrı görünür kılın:
- Bilgi mimarisi: sayfa rolleri, menüler, kategori ağacı ve temel kullanıcı yolları.
- Arayüz: farklı sayfa şablonları, mobil davranışlar ve boş, hatalı, bekleyen durumlar.
- İçerik: metin yazımı, görseller, ürün bilgileri, dil sürümleri ve veri girişi.
- Ticaret: sepet, ödeme, teslimat seçenekleri ve sipariş sonrası iletişim.
- Bağlantılar: stok, muhasebe, kargo veya müşteri yönetimi sistemleriyle veri alışverişi.
- Yayın: testler, adres geçişleri, ölçüm kontrolü, eğitim ve ilk destek dönemi.
Her teslimin miktarı, sorumlusu ve kabul koşulu belli olsun. “Ürünler eklenecek” yerine kaç ürün ailesi, kaç varyant ve hangi alanların aktarılacağını yazın. Ürün fotoğrafı çekiminin veya çevirinin kapsamda olup olmadığını baştan ayırın. Bu ayrım, eksik hazırlığın sonradan tasarım gecikmesi gibi görünmesini önler.
Revizyon sınırı kadar değişiklik yöntemi de önemlidir. Onaylı kategori ağacına yeni bir ürün grubu eklendiğinde yalnız menü değişmeyebilir; filtreler, içerik ve testler de etkilenebilir. Yeni isteğin maliyet ve tarih etkisini kaydederek karar verin. Küçük görünen taleplerin toplamı, fark edilmeden ikinci bir proje oluşturmasın.
Gerçek ürün verisi tasarımın girdisidir
Ürün adı, stok kodu, seçenekler, fiyat, ölçü, ağırlık, görsel ve açıklama için ortak bir veri sözlüğü hazırlayın. Aynı özelliği bir yerde “ebat”, başka yerde “boyut” olarak kullanmak bazen yalnız editoryal sorun gibi görünür. Filtre, karşılaştırma veya dış sisteme aktarım başladığında ise bu tutarsızlık doğrudan işlevi etkiler.
Tasarım örneklerini yalnız en düzgün üç üründen seçmeyin. Uzun isimli, çok seçenekli, stokta olmayan, farklı teslim süresine sahip ve ek açıklama gerektiren ürünleri de dahil edin. Böylece şablonların gerçek kataloğu taşıyıp taşımadığı görülür. Başlık iki satırı geçtiğinde düğmenin kaybolması veya varyant değişince yanlış fotoğrafın kalması, bu aşamada yakalanabilecek sorunlardır.
Bir ürünün bilgisi eksikse boşluğun sahibi belli olmalıdır. Tasarımcı teknik ürün özelliğini tahmin etmemeli; içerik editörü teslimat süresi uydurmamalıdır. İşletmeden bir kişi ticari doğruluğu, bir kişi ürün bilgisini onaylayabilir. Küçük ekiplerde aynı kişi iki görevi üstlenebilir, ancak onay sorumluluğu yine yazılı olmalıdır.
Kurumsal sayfalar da gerçek malzemeye ihtiyaç duyar. Doğrulanabilir proje bilgileri, kullanılmasına izin verilen fotoğraflar, hizmet sınırları ve güncel iletişim bilgileri hazırlanmalıdır. Henüz elde olmayan referans veya ekip bilgisi tasarımda gerçekmiş gibi yayımlanmamalıdır. Yer tutucu içerik, yayına hazır içerik kabul edilmez.
Proje ve ürün fotoğraflarını teslim listesinde yalnız dosya adediyle tanımlamayın. Kırpma, mobil boyut, alternatif metin ve sayfadaki açıklama da kontrol edilmelidir. Görsel SEO için proje fotoğrafı hazırlama rehberi, bu işleri çekimden canlı sayfaya kadar takip etmek için bir kontrol sırası sunar.
Ortak marka dili, farklı sayfa görevleri
Kurumsal bölüm ve mağaza aynı markaya ait görünmelidir: yazı karakterleri, renkler, düğme davranışları ve açıklama dili tutarlı kalmalıdır. Buna karşılık hizmet sayfasıyla ürün sayfası aynı düzeni kullanmak zorunda değildir. Hizmet sayfasında çalışma kapsamı ve uygunluk öne çıkarken ürün sayfasında seçim, fiyat ve teslimat bilgisi daha erken görünmelidir.
Ana sayfanın görevi bütün kataloğu sergilemek değildir. Ziyaretçiye ne sunduğunuzu anlatmalı ve onu uygun başlangıca taşımalıdır. Perakende alıcıyla bayi adayının beklentileri farklıysa “Mağazayı inceleyin” ve “Bayi başvurusu” gibi anlaşılır yollar sunabilirsiniz. Her ek düğme bir öncelik kararıdır; hepsinin aynı görsel ağırlıkta olması seçimi zorlaştırır.
Mobil tasarımda menü, ürün seçimi ve form doldurma gerçek içerikle denenmelidir. Klavye açılınca formun önemli alanları erişilebilir kalıyor mu? Uzun seçenek adları kesiliyor mu? Hata yalnız renkle mi gösteriliyor, yoksa neyin düzeltileceği yazıyla da anlatılıyor mu? Tasarım onayı, sadece ekran görüntülerinin beğenilmesinden daha kapsamlı bir kontrol olmalıdır.
Kategori, ürün ve filtrelerin ayrı görevlerini belirlemek için e-ticaret sayfa mimarisi rehberini kullanabilirsiniz. Böylece arama için hazırlanan açıklamalarla alışveriş arayüzü aynı ihtiyacı farklı yerlerde gereksiz yere tekrarlamaz.
Entegrasyonları “bağlandı” diye teslim almayın
Stok bilgisinin hangi sistemde doğru kabul edildiğini belirleyin. Sipariş mağazada oluştuğunda hangi sisteme, ne zaman ve hangi durumla gidecek? İptal veya iade olduğunda stok ve sipariş durumu nasıl değişecek? İki uygulamanın birbirine bağlanması, bu soruların otomatik olarak çözüldüğü anlamına gelmez.
Her entegrasyon için normal akışın yanında bir hata senaryosu yazın. Örneğin kargo hizmeti yanıt vermezse müşteri ne görecek, işletme nasıl haberdar olacak? Aynı sipariş ikinci kez iletilirse kopya kayıt nasıl fark edilecek? Bunlar geliştiricinin yanıtlaması gereken teknik ayrıntılardır, ancak işletmenin beklediği davranış anlaşılır cümlelerle tarif edilmelidir.
Canlı müşteri verisi yerine uygun test verisiyle deneme planlayın. Hesap sahipliği işletmede kalsın; ekip üyeleri görevleri için gereken yetkiyi alsın. Proje sonunda kullanılmayan erişimlerin gözden geçirilmesini teslim listesine ekleyin. Yetki yönetimi ve operasyon eğitimi, tasarım tamamlandıktan sonra kendiliğinden oluşmaz.
Ödeme, sipariş ve teklif akışlarını ayrı test edin
Başarılı bir satın alma dışında reddedilen ödeme, yanlış adres, stok tükenmesi, kuponun geçersiz olması ve aynı işlemin tekrar denenmesi gibi durumları da kontrol edin. Müşteri ne olduğunu anlamalı; destek ekibi de sorunu açıklayabilecek bilgiye ulaşabilmelidir. Testin kaydı, beklenen sonuç ve gözlenen davranışı içermelidir.
Shopify, test siparişlerinin ödeme adımı yanında stok, kargo ve bildirim ayarlarını kontrol etmek için kullanılmasını önerir. Test modu açıkken gerçek sipariş alınamayacağına dikkat edin; gerçek ödeme ile yapılan denemelerde ücret doğabilir. Uygulanacak yöntemi Shopify test siparişi belgesinden doğrulayın.
Teklif formunda da yalnız teşekkür mesajını kontrol etmeyin. Bildirim doğru kişiye ulaşıyor mu, gerekli alanlar işleme yeterli mi, ek dosya bekleniyorsa hata anlaşılır mı? Formun çalışması ile gelen talebin satış ekibince takip edilmesi iki ayrı teslimdir. Takip süresini ve sorumlu kişiyi işletme belirlemelidir.
Ölçüm planını tasarımla birlikte hazırlayın
Kurumsal talep ile mağaza satışını tek başarı sayısına toplamayın. Ürün inceleme, sepete ekleme, ödeme başlangıcı ve satın alma farklı aşamalardır. Google'ın GA4 e-ticaret ölçüm belgesi, bu aşamalar için olayları ve ürün verilerini tanımlar; tutar gönderildiğinde para biriminin de doğru iletilmesini açıklar.
Proje planında hangi işlemin nerede ölçüleceğini, kimin test edeceğini ve hangi raporda okunacağını yazın. Buton tıklamasını tamamlanmış talep, sayfa görüntülemesini satış olarak raporlamayın. Deneme siparişinin tekrar sayılmadığını ve farklı para birimlerinin yanlış toplanmadığını kontrol ettirin. Onay tercihleri ve veri toplama koşulları da uygulamanın parçası olmalıdır.
İlk rapor için başlangıç değerlerini kaydedin. Ziyaret azsa dönüşüm oranındaki büyük yüzdelik değişimleri güçlü sonuç gibi sunmayın. Aynı dönemde fiyat, reklam veya ürün seçkisi değiştiyse bunu not edin. Ölçümde eksik bir kurulum varsa sonuç “sıfır talep” değil, “doğrulanamayan ölçüm” olabilir.
Sosyal medya paylaşımları bu yollara trafik getiriyorsa, paylaşımın vaadiyle açılış sayfasının cevabını da birlikte test edin. Sosyal medyadan web sitesine dönüşüm rehberi, bağlantı seçimini, form sonrasındaki takibi ve tamamlanan işlemin ölçümünü aynı akışta ele alır.
Yenileme projesinde mevcut adresleri koruyun
Mevcut kurumsal siteye mağaza eklenirken eski hizmet sayfaları ve içerikler unutulabilir. Trafik veya bağlantı alan adresleri listeleyin; korunacak olanları, değişecek olanları ve karşılığı bulunmayanları ayırın. Yeni görünüm onaylandı diye çalışan adresleri gerekçesiz değiştirmeyin.
Adres değişikliği gerekiyorsa eski sayfayı ilgili yeni karşılığına eşleyin; bütün adresleri ana sayfaya göndermekten kaçının. Google'ın URL değişikliğiyle site taşıma rehberi, eşleme, yönlendirme ve geçiş sonrası izlemeyi birlikte ele alır. Bu kontroller sıralama garantisi değildir; geçişin doğru uygulanmasını değerlendirmek içindir.
Ürün taşınması da kapsamdaysa Shopify taşıma planı üzerinden veri, adres ve sipariş sürekliliğini ayrıca gözden geçirin. Kurumsal içeriklerle mağaza verilerinin aynı gün taşınması zorunlu olmayabilir; aşamalı geçişin ziyaretçi üzerindeki etkisini önce tasarlayın.
Temsili bir projeyi aşamalara bölelim
Varsayımsal örnek olarak hem perakende satış yapan hem işletmelere toplu teklif veren bir ev aksesuarı üreticisini düşünün. İlk hedef, seçilmiş ürünlerin satın alınabilmesi ve toplu alım talebinin doğru ekibe ulaşması olsun. Bu bir müşteri vakası veya süre taahhüdü değildir; kapsamı nasıl ayırabileceğinizi göstermek içindir.
İlk aşamada işletme ürün verisini ve teslimat koşullarını hazırlar; ajans kullanıcı yollarını ve sayfa şablonlarını çıkarır. Sonraki aşamada gerçek ürünlerle mobil prototip incelenir. Perakende alıcı fiyat ve stok görür; özel üretim isteyen kişi hangi bilgileri paylaşması gerektiğini açıklayan bir talep yoluna ulaşır.
Geliştirme sırasında standart satın alma akışıyla toplu teklif akışı ayrı test edilir. İlk yayına hazır olmayan gelişmiş bayi fiyatlandırması, yalnız temel yol onsuz çalışabiliyorsa sonraki aşamaya bırakılır. Böylece “ileride lazım olabilir” özellikleri ana yayını sürekli geciktirmez. Ertelenen işin kapsamı ve yeniden değerlendirileceği koşul da kayıtlı kalır.
Yayın kararı için kısa kabul listesi
Yayına çıkmadan önce ekip, aşağıdaki maddelere yalnız “tamam” değil, gerektiğinde örnek kayıtla yanıt verebilmelidir:
- Kurumsal bilgi arayan ve ürün satın alan ziyaretçi görevini mobilde tamamlayabiliyor.
- Yayındaki ürünlerin fiyat, stok, görsel ve teslimat bilgileri sorumlu kişi tarafından kontrol edildi.
- Başarılı ve başarısız ödeme ile teklif bildirimi denendi; sonuçlar kaydedildi.
- Entegrasyonların normal ve hata durumları için sorumlular belirlendi.
- Mevcut adresler, iç bağlantılar, dil geçişleri ve gerekli yönlendirmeler kontrol edildi.
- Ölçüm olayları gerçek iş adımlarıyla eşleştirildi; doğrulanamayanlar açıkça yazıldı.
- İçerik ve ürün güncelleme eğitimi verildi; ilk destek döneminin kapsamı belli.
Yayın sonrası ilk incelemede sipariş ve form akışlarını, sonraki düzenli değerlendirmelerde arama görünürlüğünü ve kullanıcı davranışlarını ele alın. Sorun listesini etkisine göre sıralayın: satın almayı durduran hata, küçük bir görsel düzeltmeyle aynı öncelikte değildir. Her sorunun sahibi ve tekrar kontrol tarihi olsun.
WeAreMedia'nın web tasarım ve geliştirme ile e-ticaret hizmetlerini birlikte değerlendirirken görüşmeye mevcut siteniz, örnek ürünleriniz ve öncelikli iki kullanıcı yolunuzla başlayabilirsiniz. Bu üç bilgi, yalnız bir görünüm teklifinden daha net bir proje kapsamı oluşturmayı sağlar.
