İyi bir proje gerçekten nereden başlar?
Önceki bölümlerde önemli bir sonuca vardık - sadece “yeni bir site” gerektiği için site tasarlamıyoruz.
Biz, belirli bir problemi çözmek için bir araç tasarlıyoruz.
Bazen problem zayıf satışlardır. Bazen yetersiz sayıda gelen talep. Bazen müşteriler bilgi bulamıyor. Başka zamanlarda satış ekibi her gün aynı soruları yanıtlıyor çünkü site temel bilgileri iletmiyor. Ayrıca bazen şirket büyür ve mevcut site gerçek ölçeğine cevap vermez hale gelir.
Bu yüzden ilk aşama Photoshop, Figma veya bir framework seçimi olmamalı.
İlk aşama bir konuşma olmalı.
Önce işi tanıyoruz
İyi bir UX tasarımcısının çalıştığı her sektörde uzman olması gerekmez. Ancak müşterinin işini yeterince iyi anlamalıdır; hangi sorunları çözmeye çalıştığını bilmek için.
Bu yüzden başta tasarımla ilgiliymiş gibi görünmeyen sorular soruyoruz;
- Müşteriler nereden geliyor?
- Neden tam olarak bu firmayı seçiyorlar?
- Neden ayrılıyorlar?
- Satın almadan önce en sık hangi soruları soruyorlar?
- Satış süreci nasıl işliyor?
- Sorgulardan kim sorumlu?
- Form gönderildikten sonra lead ile ne oluyor?
- Hangi ürünler en önemli?
- Hangi hizmetlerin en büyük potansiyeli var?
- Firma, gelen sorgu sayısını mı, sipariş değerini mi, müşteri sayısını mı artırmak istiyor yoksa öncelikle itibarını mı iyileştirmek istiyor?
Bu tür sorulara verilen cevaplar, aslında neyi tasarlamamız gerektiğini belirlememizi sağlar.
Discovery - ilk taslak oluşmadan önce
Dijital projelerde sıkça kullanılan bir terim vardır: Discovery.
Bu, gerçek tasarım ve geliştirmeye başlamadan önce problemin, kullanıcıların, iş hedeflerinin, sınırlamaların ve teknolojik imkanların keşfedildiği aşamadır.
Bu, “çalışmaya başlamadan önce zaman kaybı” değildir. İyi yürütülen bir Discovery, güzel görünecek ama gerçek problemi çözmeyecek bir şey inşa etme riskini azaltır.
Örneğin müşterinin aslında yeni bir siteye hiç ihtiyacı olmadığını keşfedebiliriz.
Belki daha iyi bir bilgi mimarisine ihtiyacı vardır.
Ya da satın alma sürecinin sadeleştirilmesine.
Ya da sitenin CRM ile entegrasyonuna.
Ya da sorgu yönetiminin otomasyonuna.
Ya da teklifin tamamen farklı bir şekilde sunulmasına.
İşte bu yüzden bazen üretime başlamadan önce durmak faydalıdır.
UX görünümle başlamaz
UX, yani User Experience, kullanıcının bir ürün veya hizmeti kullanırken yaşadığı deneyimi ifade eder.
Bir web sitesi söz konusu olduğunda, bu sadece arayüzün görünümünden çok daha fazlasını kapsar.
Ayrıca şunlardır:
- sitede gezinme biçimi,
- bilgi bulmanın kolaylığı,
- iletilerin anlaşılabilirliği,
- satın alma süreci,
- formlar,
- içerik hiyerarşisi,
- görevleri tamamlama hızı,
- kullanıcı eylemlerine sistem tepkisi,
- erişilebilirlik,
- güven ve emniyet hissi.
Bu yüzden UX, birileri ilk ekranı çizmeden önce başlar.
Önce, kullanıcının ne başarmaya çalıştığını anlamamız gerekir.
User Flow - kullanıcı hedefe hangi yoldan ulaşmalı?
UX tasarımının temel araçlarından biri User Flow’dur. Bu, kullanıcının belirli bir görevi tamamlamak için izlediği yolun tanımıdır.
Örneğin bir e-ticarette şöyle olabilir: reklam → ürün sayfası → varyant seçimi → sepet → teslimat → ödeme → sipariş onayı.
Bir hizmet şirketinde: Google → hizmet sayfası → referanslar → örnek işler → form → satış temsilcisiyle iletişim.
Bir üreticide: arama → ürün → teknik özellikler → dokümantasyon → teklif talebi.
Her bir yol farklı tasarım kararları gerektirir.
Kullanıcının en önemli hedefi satın almaksa, onu onlarca ekran metin okumaya zorlayamayız. Ancak ürün pahalı, karmaşık ve danışma gerektiriyorsa, kullanıcıyı çok hızlıca forma yönlendirmek de yanlış olabilir.
UX, kullanıcıyı yönlendirmede doğru dengeyi bulmaktır.
Wireframe - “güzelleştirmeden” önce
Bir sonraki aşama wireframe olabilir; bu, içeriğin ve fonksiyonların düzenini gösteren sade bir ekran şemasıdır.
Wireframe’in güzel olması gerekmez. Hatta iyi olur. Bu aşamada önemli olan buton renginin doğru seçilmesi değil.
Cevaplamamız gereken sorular şunlardır:
- Kullanıcı ilk olarak neyi görecek?
- En önemli şey ne olacak?
- Hangi içerikler daha yukarıda olmalı?
- Ek bilgiler nereye konacak?
- Kullanıcı bir sonraki adıma nasıl geçecek?
- Tıklayınca ne olacak?
Bu biraz da bir daire tasarlamak gibidir.
Önce duvarların, kapıların ve odaların nerede olacağını belirliyoruz. Sonra duvarın rengine karar veriyoruz.
Design system - projenin rastgele parçalar yığını olmaması için
Daha büyük projelerde bir diğer önemli unsur ortaya çıkar - Design System.
Bu, arayüzün nasıl inşa edileceğini tanımlayan düzenli bir kural, bileşen ve desen setidir.
Şunları içerebilir:
- renkler,
- tipografi,
- butonlar,
- formlar,
- kartlar,
- tablolar,
- bildirimler,
- ikonlar,
- boşluklar,
- responsive kurallar,
- bileşen davranışları.
Neden? - Arayüzün tutarlı olması için.
Bir sayfada bir buton bir şekilde davranırken başka bir sayfada tamamen farklı davranırsa, kullanıcı her seferinde arayüzü yeniden öğrenmek zorunda kalır.
Design System ayrıca geliştirme ekibine de yardımcı olur. Her seferinde bir bileşeni sıfırdan yapmak yerine önceden tanımlanmış öğeleri kullanabilirler.
Bu, daha fazla tutarlılık, daha kolay geliştirme ve genellikle daha düşük bakım maliyeti demektir.
Tüm bunlarda teknoloji nerede duruyor?
Teknoloji erken aşamalarda görünmeli, ama tüm projeyi dikte etmemeli. Bu önemli bir ayrımdır.
Tasarımcı iş mantığı açısından anlamlı görünen harika bir özellik düşünebilir. Ancak geliştirici bunun uygulanmasının çok maliyetli olacağını veya performans sorunlarına yol açacağını fark edebilir.
Diğer yandan geliştirici uygulanması çok kolay bir teknolojik çözüm önerebilir, ama bu kullanıcı açısından problemi yeterince iyi çözmeyebilir.
Bu yüzden en iyi projeler UX, tasarım, geliştirme ve iş birimlerinin en başından beri birbirleriyle konuştuğu yerlerde ortaya çıkar.
Sırayla: “Önce tasarımcılar, sonra geliştiriciler” şeklinde değil.
Tersine: “Birlikte en iyi nasıl çözüm üretiriz?”
Teknoloji moda olduğu için seçilmemeli
React, Vue, Next.js, Laravel, Symfony, .NET, WordPress, headless CMS, native uygulama, PWA... Teknolojiler uzun uzadıya sayılabilir.
Ama müşteri teknoloji satın almaz. Çözüm satın alır.
Bu yüzden “Hangi framework’ü kullanacağız?” sorusu
çoğu zaman “Sistem hangi problemleri çözmeli?” sorusundan çok daha az önemlidir. Ancak daha sonra uygun mimari seçilebilir.
Basit bir kurumsal site başka bir teknoloji ister, binlerce siparişi yöneten bir mağaza başka bir şey, geniş entegrasyonlara ve kullanıcı yetkilerine sahip B2B platformu ise bambaşka bir çözüm gerektirir.
Teknoloji gereksinimlerden çıkmalı, gereksinimler teknolojiden türetilmemeli.
Backend, frontend ve kullanıcının görmediği yer
Ayrıca unutulmamalı ki bir web sitesi sadece tarayıcıda gördüğümüz şey değildir.
Frontend, kullanıcının doğrudan etkileşime girdiği uygulama kısmından sorumludur.
Backend, sunucu tarafında çalışan mantıktan—veri işleme, veritabanı iletişimi, süreçlerin yönetimi ve entegrasyonlardan—sorumludur.
Aralarında ise genellikle pek çok ek unsur bulunur;
- CRM.
- ERP.
- Ödeme sistemi.
- E-posta pazarlama platformu.
- Depo/stok yönetim sistemi.
- API.
- Analitik.
- Otomasyonlar.
- Müşteri hizmetleri sistemi.
Eğer yeni bir siteyi bu ekosistemi dikkate almadan tasarlarsak, güzel bir frontend yaratabiliriz ama bu yalnız bir ada gibi işlev görebilir.
Oysa amaç bambaşka olmalı.
İyi bir site sadece “form toplamak”tan fazlasını yapabilir
Modern bir web sitesi daha büyük bir iş sürecinin parçası olabilir;
- Kullanıcı bir talep gönderir.
- Sistem konusunu tanır.
- Lead CRM’e düşer.
- Satış temsilcisi bildirim alır.
- Müşteriye otomatik bir onay gönderilir.
- Veriler uygun kategoriye atanır.
- Sistem ürünün stok durumunu kontrol edebilir.
- Satış temsilcisi için bilgi hazırlayabilir.
- Belirli bir workflow başlatabilir.
Bir mağazada sipariş otomatik olarak işlem aşamalarından geçebilir. B2B’de müşteri özel fiyatlara, dökümanlara ve sipariş geçmişine erişebilir.
O zaman site sadece bir “kartvizit” olmaktan çıkar; iş altyapısının bir parçası haline gelir.
Peki ya AI?
AI de böyle bir sistemin bir parçası olabilir. Ancak yine — “herkesin artık AI’si var” diye eklenmemeli.
Eğer chatbot hiçbir gerçek problemi çözmüyorsa, sadece sitede başka bir pencere olur.
Ama eğer AI sayesinde kullanıcı doğru ürünü daha hızlı bulabiliyorsa, hizmeti yapılandırabiliyorsa, bir soruya yanıt alabiliyorsa veya seçim sürecini geçebiliyorsa, o zaman bu teknoloji haklı bir gerekçe kazanır.
Kişiselleştirme için de aynı şey geçerli.
Kullanıcının davranışına, giriş kaynağına veya satın alma sürecindeki aşamasına göre farklı içerikler gösterebiliriz. Verileri analiz edip müşterilerin ihtiyaçlarını daha iyi tahmin edebiliriz.
Ama her zaman önce şu sorudan başlamalıyız: “Hangi problemi çözüyoruz?”
Sonra: “AI bunu çözmek için en iyi yol mu?”
Sadece çalışıyor mu test etmiyoruz
En sık yapılan hatalardan biri, siteyi ancak işin sonunda test etmektir. O zaman formun çok uzun olduğu, satın alma sürecinin sezgisel olmadığı veya kullanıcının en önemli bilgiyi bulamadığı ortaya çıkar.
Böyle bir problemi ne kadar geç keşfedersek, düzeltmesi o kadar pahalı olur.
Bu yüzden projeyi aşama aşama test etmek faydalıdır. Prototipleri test edebiliriz. Kullanıcı davranışlarını gözlemleyebiliriz. Kullanılabilirlik testleri yapabiliriz. Google Analytics veya diğer analiz araçlarından veri inceleyebiliriz. Oturum kayıtları veya ısı haritaları kullanabiliriz, tabii gizlilik gerekliliklerine uyuluyorsa. Ayrıca satış ekibiyle konuşabiliriz.
Sonuncusu sıkça hafife alınır.
Satış temsilcisi her gün müşterilerin sorduğu soruları duyar; neleri anlamadıklarını bilir. Nelerden endişe ettiklerini bilir. Satın alma öncesinde hangi bilgilerin verilmesi gerektiğini bilir.
Bu, büyük bir tasarım bilgisidir.
MVP değersiz bir şey demek değildir
Dijital projelerde sıkça duyduğumuz bir kavram var: MVP - Minimum Viable Product.
Bu, varsayımları doğrulamak ve kullanıcılara değer sunmak için gereken minimum işlev setini içeren ürünün ilk sürümüdür.
MVP, “her nasıl olursa olsun bir şey yapalım, sonra bakarız” anlamına gelmemeli.
İyi bir MVP şu soruya cevap vermelidir: “Doğru yönde olup olmadığımızı test etmek için en küçük çözüm ne?”
Bu, web siteleri ve uygulamalar için de çok önemlidir.
Bir kerede otuz özellik geliştirmek yerine, bazen en önemli beşini yayınlayıp kullanıcıların bunları nasıl kullandığını görmek daha iyidir. Sonra gerçek verilere dayanarak sistemi geliştiririz, sadece ilk toplantıdaki varsayımlara değil.
Site yayınlandığında bitmez
Bu unutulan başka bir noktadır.
Site yayınlanma anı aslında gerçek hayatının başlangıcıdır. O zaman gerçek kullanıcılar gelir. Hangi içeriklerin işe yaradığını görürüz. Hangi öğelerin görmezden gelindiğini görürüz. O zaman ziyaretçi sayısının, sorgu sayısının, satışların, sitede geçirilen sürenin veya daha önce belirlediğimiz diğer metriklerin artıp artmadığını test edebiliriz.
Bu yüzden proje geliştirilmelidir;
- Analiz.
- Çıkarımlar.
- Değişiklik.
- Test.
- Yeniden analiz.
Bu bir döngü gibidir, tek seferlik bir olay değil.
Neyi ölçmeliyiz?
Bu, projenin hedefine bağlıdır.
Bir e-ticaret sitesi için şunlar olabilir:
- dönüşüm oranı,
- ortalama sipariş değeri,
- sepet terk oranı,
- gelir,
- müşteri yaşam boyu değeri.
Bir hizmet firması için:
- değerli lead sayısı,
- form dönüşüm oranı,
- planlanan danışmanlık/randevu sayısı,
- lead edinme maliyeti,
- sorgu kalitesi.
Bir haber sitesi için:
- belirli bilgileri bulma,
- kullanıcı etkileşimi,
- geri dönüş sayısı,
- kaynak indirmeleri.
Her şeyi ölçmek gerekmez. Ancak neyin önemli olduğunu bilmek gerekir.
Çünkü firma değerli sorgu sayısını artırmak istiyorsa, sadece trafik artışı başarı anlamına gelmeyebilir. On kat daha fazla ziyaretçimiz olabilir ama tek bir ekstra müşteri kazanamayabiliriz.
En büyük hata? “Neden?” sorusuna cevap olmadan tasarlamak
Harika görsel bir site oluşturulabilir.
Modern bir teknoloji yığını kullanılabilir.
Mükemmel animasyonlar hazırlanabilir.
Her piksele özen gösterilebilir.
Yine de proje beklenen iş sonuçlarını getirmeyebilir. Neden?
Çünkü en önemli soruya cevap bulunmamıştır: Bütün bunları yapmamızın amacı ne?
Eğer cevap “Çünkü eski site çirkin” ise,
bu biraz eksik kalır.
Ama eğer cevap “B2B müşterilerinden gelen değerli sorgu sayısını artırmak, müşterinin doğru hizmete ulaşma süresini kısaltmak ve satış ekibini tekrarlayan sorulardan kurtarmak” ise,
bir anda çözmemiz gereken somut bir problemimiz olur.
Ve çözümü tasarlayabiliriz.
Web24 olarak sadece site teslim etmek istemiyoruz
Bu, bir işi yapıp teslim etmek ile teknolojik bir ortaklık yapmak arasındaki farktır.
Müşteri belirli bir fikriyle gelmişse, bizim görevimiz onu düşüncesizce uygulamak değildir.
Aynı zamanda “Bu mantıklı” demek de bizim görevimizdir.
Ya da: “Bunu daha iyi yapabiliriz.”
Ya da: “Teknik olarak bunu yapabiliriz ama iş gerekçesini görmüyoruz.”
Ya da: “Bunu yapmadan önce kullanıcıların gerçekten buna ihtiyacı olup olmadığını test edeceğiz.”
Bazen en iyi tasarım kararı bir özellik eklemek; bazen onu kaldırmak; bazen ise varsayımları tamamen değiştirmektir.
Ve işte ekip deneyimi bundan ibarettir - her şeyi inşa edebiliyor olmak değil, gerçekte neyi inşa etmenin değerli olduğunu tespit edebilmektir.
Aynı iki proje yoktur
Tekrar başlangıç noktasına dönüyoruz.
Aynı sektörden iki müşteri olabiliriz. İki üretici. İki mağaza. İki hukuk bürosu. İki yazılım şirketi.
Siteleri benzer görünebilir. Ancak aynı olmamalıdırlar sadece aynı kategoride oldukları için.
Çünkü onları farklı kılan insanlar, strateji, satış süreci, teklif, bütçe, teknoloji, müşteriler ve hedeflerdir.
İşte bu yüzden her proje kendi kararlarını gerektirir.
Her zaman çarpıcı olmak zorunda değil. Her zaman devrimsel değil. Ama bilinçli olmalıdır.
Web sitesi bir dekorasyon değil, bir araçtır
İyi tasarlanmış bir site, şirket için sadece dijital bir kartvizitten fazlası olmalıdır.
Kullanıcının karar vermesine yardımcı olmalı. Satışı kolaylaştırmalı. Soruları yanıtlamalı. Güven inşa etmeli. Çalışanları desteklemeli. Mantıklı olduğunda diğer sistemlerle entegrasyon sağlamalıdır.
Ve her şeyden önemlisi, belirli bir iş hedefini gerçekleştirmelidir.
Bu yüzden “İyi bir web sitesi nasıl görünür?” sorusunun tek bir cevabı yoktur.
Daha iyi soru: “Bu belirli şirketin hedeflerine ulaşmasına yardımcı olmak için sitesi nasıl çalışmalı?”
Ve her iyi proje aslında bu soruyla başlamalıdır.
Son - en önemli kural
Siteyi, müşteri “Ne kadar güzel!” diyebilsin diye tasarlamıyoruz.
Sitenin amacı, birkaç ay sonra müşterinin “Bu gerçekten iş yapmamıza yardımcı oluyor” diyebileceği bir şey tasarlamaktır.
Güzel bir site ile iyi bir dijital ürün arasındaki fark genellikle ilk ekranda görünmez.
Bunu ancak sonuçlarda görürsünüz.
Serinin özeti
Bu seride neden iki aynı web sitesini tasarlamadığımızı inceledik.
Basit bir varsayımla başladık: aynı sektör aynı işi ifade etmez.
Ardından, şirket stratejisinin, satış yönteminin, hedef kitlenin ve kullanıcı ihtiyaçlarının UX, bilgi mimarisi ve işlevselliği nasıl etkilediğini gösterdik.
Son bölümde Discovery ve işi tanımadan User Flow, wireframe’ler, Design System’e; teknoloji, entegrasyonlar, test, analitik ve devam eden geliştirme süreçlerine kadar proje sürecini anlattık.
Çünkü özel bir proje sadece “farklı bir görünüm” demek değildir.
Başka kararlar gerektirir; farklı bir problemden kaynaklanan kararlar.
İşte bu yüzden her şirket ortalama bir firmaya göre değil, kendisine göre tasarlanmış bir çözüm almalıdır.
