UI/UX Tasarım Hizmeti Almadan Önce Bilmeniz Gereken 12 Kritik Nokta

UI UX tasarım hizmeti satın almak, çoğu işletme için ilk bakışta "ekranları güzelleştirme" işi gibi gelir. Ancak teklif dosyasını açtığınızda araştırma, wireframe, prototip, kullanılabilirlik testi ve devir gibi birbirinden farklı kalemler çıkar. Bu yazıda 2012'den beri müşteri tarafında ve tasarım masasında gördüklerime dayanarak, imza atmadan önce kontrol etmeniz gereken 12 kritik noktayı sırasıyla anlatıyorum.

UI UX tasarım hizmeti nedir ve satın alırken neye bakmalısınız?

UI UX tasarım hizmeti, bir web sitesi ya da uygulamanın kullanıcı ihtiyacını araştıran, bilgi mimarisini ve akışları kuran, arayüzü görsel olarak tasarlayan ve sonucu test edip geliştirme ekibine teslim eden profesyonel süreçtir. Satın alırken kapsamı, teslim dosyalarını, hakları, testi ve devir biçimini yazılı olarak netleştirmelisiniz.

UX kısmının (kullanıcı deneyimi) sorusu şudur: "Kullanıcı bu ekranda ne yapmak istiyor ve bunu ne kadar zahmetsiz yapabiliyor?" UI kısmı (kullanıcı arayüzü) ise renk, tipografi, bileşen ve ekran düzeniyle bu kararları ekrana taşır. İkisi ayrı uzmanlıklar gibi dursa da bir projede birbirinden kopuk ilerlerse sonuç ya güzel ama kullanışsız ya da mantıklı ama güven vermeyen bir ekran olur.

Bu yazı bir tasarım hatası listesi değil. Sitenizdeki tipik kullanıcı deneyimi sorunlarını merak ediyorsanız SEO ve UX uyumu yazısına, Google ile kullanıcı arasındaki dengeyi merak ediyorsanız UX ve SEO dengesi rehberine göz atabilirsiniz. Burada odak, satın alan tarafın masaya hangi sorularla oturması gerektiği.

Bu kontrol listesi kimin işine yarar?

Bu listeyi, tasarım işini dışarıdan satın alan işletmeler için yazdım. Örneğin kurumsal sitesini yenileyen bir üretim firması, müşteri paneli kuran bir SaaS girişimi ya da mobil uygulamasının akışını sadeleştirmek isteyen bir e-ticaret markası aynı riskleri taşır: kapsamı belirsiz bir teklif, sonradan ortaya çıkan ek ücretler ve geliştirme ekibinin kullanamadığı dosyalar.

Ajansla da serbest tasarımcıyla da çalışsanız sorular değişmez. Değişen, cevapların nerede yazacağıdır. Ajanslar genellikle standart bir hizmet sözleşmesi getirir; serbest çalışanlarda ise kapsam çoğu zaman bir e-posta yazışmasında kalır. Bu nedenle listeyi bir "teklif karşılaştırma şablonu" gibi kullanmanızı öneririm: her tedarikçinin cevabını aynı satırlara yazdığınızda, fiyat farkının neden kaynaklandığı kendiliğinden ortaya çıkar.

Bir not daha: aşağıdaki maddeler hukuki danışmanlık yerine geçmez. Fikri haklar ve sözleşme bölümlerinde genel çerçeveyi anlatıyorum; tutarı yüksek veya uluslararası bir işte metni bir avukata okutmak her zaman daha güvenli yoldur.

Listeyi kullanmanın en pratik yolu, her maddeyi bir tabloya satır olarak yazmak ve teklif veren her tedarikçiye aynı soruları göndermektir. Cevapların bir kısmı boş dönecektir; bu boşluklar da size en az cevaplar kadar bilgi verir. Açıkçası sahada gördüğüm pahalı hataların çoğu, kötü tasarımdan değil, eksik yazılmış tekliflerden çıkıyor.

1. Kritik nokta: Kapsamda hangi teslimatlar yazıyor?

İlk soru her zaman şudur: bu parayı ödediğinizde elinize tam olarak ne geçecek? "Web sitesi tasarımı" ifadesi bir teslimat değildir. Teklifte kalemlerin tek tek, sayılarıyla birlikte yazmasını isteyin. Aşağıdaki liste, bir UI/UX projesinde sık gördüğüm teslimatları gösteriyor:

• Keşif ve araştırma çıktıları: paydaş görüşme notları, kullanıcı görüşmeleri, rakip incelemesi, persona veya iş akışı haritası.
• Bilgi mimarisi: site haritası, menü yapısı, sayfa şablonlarının listesi.
• Wireframe: düşük detaylı, renksiz ekran iskeletleri.
• UI tasarımı: masaüstü ve mobil kırılımlarda tam görsel ekranlar.
• UI kit veya tasarım sistemi: renk, tipografi, bileşen ve durum kütüphanesi.
• Tıklanabilir prototip: ana senaryoları gezdiren etkileşimli dosya.
• Kullanılabilirlik testi ve rapor: bulgular ve öncelik sırası.
• Geliştirici devri: ölçüler, varlık dışa aktarımları, etkileşim notları.

Bu kalemlerin hepsi her projede gerekmez. Ancak hangisinin dahil, hangisinin hariç olduğunu yazılı görmek, ileride "bu fiyata test yoktu" tartışmasını baştan bitirir. Ayrıca ekran sayısını da netleştirin: "yaklaşık 10 sayfa" yerine sayfa şablonlarının adlarını listeleyin.

2. Kritik nokta: Tasarımcı gerçek kullanıcılarla konuşacak mı?

Birçok teklifte "UX analizi" diye bir satır görürsünüz, ama içini açtığınızda tasarımcının siteyi bir saat gezip notlar aldığını fark edersiniz. Bu da değerli olabilir; yine de gerçek kullanıcı araştırmasıyla aynı şey değildir. Sormanız gereken soru basit: "Hangi kullanıcılarla, kaç görüşme, hangi yöntemle konuşacaksınız?"

Araştırma bütçesi kısıtlıysa bile en azından üç kaynaktan veri istemenizi öneririm. İlki, satış ve müşteri hizmetleri ekibinizin sık duyduğu itirazlar. İkincisi, mevcut sitenizin analitik verisi; örneğin hangi sayfalarda ziyaretçinin döndüğünü veya formun hangi adımında bıraktığını gösteren raporlar. Üçüncüsü ise birkaç gerçek müşteriyle kısa görüşmeler.

Hedef kitlenizi zaten tanımladıysanız bu çalışmayı tasarımcıyla paylaşın; tanımlamadıysanız hedef kitle analizi rehberi iyi bir başlangıç noktası sunar. Böylece tasarımcı sıfırdan değil, sizin bildiklerinizin üzerine inşa eder. Üstelik araştırma aşamasında ortaya çıkan bulgular, çoğu zaman tasarım kapsamını da değiştirir: bazen yeni bir sayfa gerekir, bazen de planladığınız bir bölüm gereksiz çıkar. Araştırma çıktısının bir belge olarak teslim edilmesini de şart koşun; çünkü o belge, bir sonraki tasarım ya da reklam çalışmasında da işinize yarar.

3. Kritik nokta: Wireframe ve prototipi hangi aşamada onaylayacaksınız?

Wireframe, renk ve görsel olmadan sayfanın iskeletini gösterir. Prototip ise bu ekranları birbirine bağlayarak bir kullanıcı senaryosunu gezilebilir hale getirir. İkisi de ucuz aşamalardır; yani yanlış bir kararı burada düzeltmek, tasarımı bitmiş ya da koda dönüşmüş bir ekranı değiştirmekten çok daha az zaman alır.

Bu yüzden süreçte bir "iskelet onayı" durağı olup olmadığını sorun. Benim tercih ettiğim akış şöyle ilerler:

1. Site haritasını ve sayfa listesini onaylarsınız; hangi sayfanın hangi amaca hizmet ettiğini yazarsınız.
2. Tasarımcı ana şablonların wireframe'lerini sunar ve içerik önceliklerinde uzlaşırsınız.
3. Kritik akışlar için tasarımcı tıklanabilir bir prototip hazırlar; örneğin teklif formu veya ödeme adımı.
4. Son adımda görsel tasarımı onaylı iskeletin üzerine giydirir.

Prototipin kapsamını da netleştirin. "Prototip dahil" ifadesi bazen yalnızca ana sayfadan iç sayfaya tek bir tıklamayı anlatır. Oysa asıl değer, dönüşümün gerçekleştiği akışlardadır. Form tarafında hangi kuralların işe yaradığını merak ediyorsanız randevu, teklif ve demo formu tasarımı yazısında ayrıntıları bulabilirsiniz.

4. Kritik nokta: UI kit ve tasarım sistemi teslimatın içinde mi?

UI kit, arayüzde tekrar eden parçaları (buton, form alanı, kart, uyarı kutusu, menü) tek bir kütüphanede toplayan dosyadır. Tasarım sistemi bunun bir adım ötesidir: bileşenlerin yanında kullanım kurallarını, boşluk ölçülerini ve durumlarını da tanımlar. Örneğin tasarımcı bir butonun normal, üzerine gelme, basma, pasif ve yükleme hallerini ayrı ayrı çizer.

Bu teslimat neden önemli? Çünkü siteniz yaşayan bir üründür. Altı ay sonra yeni bir kampanya sayfası açmak istediğinizde, UI kit yoksa her yeni ekran biraz farklı durur ve marka tutarlılığı aşınır. Hatta geliştirme ekibi de her seferinde yeni bir bileşen yazar; bu da bakım maliyetini büyütür.

Teklifte şu ayrıntıları arayın: renk paletinin HEX değerleri, tipografi ölçeği, ızgara ve boşluk kuralları, bileşen durumları ve ikon seti. Renk kodlarını düzenli tutmak için HTML renk kodları aracı gibi basit yardımcılar bile iş görür. Kurumsal kimliğiniz henüz dijitale uygun değilse bu işi tasarım projesinden önce marka kimliği tarafında çözmek, arayüz tasarımını ciddi ölçüde hızlandırır.

5. Kritik nokta: Kullanılabilirlik testini kaç kişiyle ve nasıl yapacaksınız?

Kullanılabilirlik testi, gerçek ya da hedef kitleye benzeyen kişilerin tasarımı belirli görevlerle denemesi ve tasarımcının nerede takıldıklarını gözlemlemesidir. Örneğin "bu sitede fiyat teklifi isteyin" görevini verirsiniz ve katılımcının formu bulup bulamadığını izlersiniz.

Nielsen Norman Group'tan Jakob Nielsen'in 2000 yılında yayımladığı beş kullanıcıyla test yazısına göre, beş kişilik bir test tasarımdaki kullanılabilirlik sorunlarının yaklaşık yüzde 85'ini ortaya çıkarır. Nielsen'in asıl önerisi ise tek büyük test yerine küçük ve tekrarlı testlerdir: test edin, düzeltin, yeniden test edin.

Teklifte şu soruların cevabını arayın:

• Test prototip aşamasında mı, yoksa tasarım bittikten sonra mı olacak?
• Katılımcıları kim bulacak ve teşvik ödemesi fiyata dahil mi?
• Test moderasyonlu mu (tasarımcı eşlik eder) yoksa uzaktan ve kendi başına mı?
• Bulguları bir raporla alacak mısınız ve düzeltmeler hangi revizyon hakkından düşecek?

Son madde gözden kaçar ama çok önemlidir. Test sonrası düzeltmeler revizyon hakkınızı tüketiyorsa, test yapmak sizin açınızdan cezaya dönüşür.

6. Kritik nokta: Erişilebilirlikte (WCAG) hangi seviyeyi hedefliyorsunuz?

Erişilebilirlik, sitenizin görme, işitme, motor veya bilişsel kısıtı olan kişiler tarafından da kullanılabilmesidir. Uluslararası referans W3C'nin WCAG 2.2 standardıdır. Standart dört ilkeye dayanır: algılanabilir, işletilebilir, anlaşılabilir ve sağlam. Standart üç uygunluk seviyesi tanımlar: A, AA ve AAA; pratikte ekiplerin en sık hedeflediği seviye AA'dır.

Konu teorik değil. WebAIM'in her yıl bir milyon ana sayfayı tarayan WebAIM Million raporunun 2026 sürümüne göre ana sayfaların yüzde 95,9'unda otomatik araçların yakalayabildiği WCAG hataları var. En sık hata ise yüzde 83,9 ile düşük kontrastlı metin. Bu hataların önemli kısmı tasarım aşamasında doğar.

Avrupa Birliği'ne satış yapıyorsanız konu ayrıca yasal bir boyut kazanır: Avrupa Erişilebilirlik Yasası (Direktif 2019/882) belirli dijital ürün ve hizmetler için 28 Haziran 2025'ten itibaren yürürlükte. Tasarımcıya şunu sorun: "Hangi seviyeyi hedefliyorsunuz, kontrast oranını ve klavyeyle gezinmeyi nasıl kontrol ediyorsunuz?" WCAG 2.2 AA seviyesinde normal metin için en az 4,5:1 kontrast oranı gerekir. Bu soruya somut bir yöntemle cevap veremeyen bir tasarımcı, muhtemelen konuyu geliştirme ekibine bırakıyordur.

7. Kritik nokta: Kaynak dosyalar ve fikri haklar kime ait olacak?

Bu madde en çok tartışma çıkaran maddedir. Tasarımın bedelini ödemeniz, kaynak dosyaların ve kullanım haklarının otomatik olarak size geçtiği anlamına gelmez. Kaynak dosya derken Figma, Sketch veya Adobe XD gibi araçlardaki düzenlenebilir çalışma dosyasını kastediyorum; PDF veya PNG ekran görüntüleri bu tanıma girmez.

Türkiye'de 5846 sayılı Fikir ve Sanat Eserleri Kanunu, mali haklara ilişkin sözleşmelerin yazılı olmasını ve devredilen hakların ayrı ayrı gösterilmesini şart koşar (madde 52). Yani "tüm haklar müşteriye aittir" gibi tek satırlık bir ifade yerine çoğaltma, işleme, yayma ve umuma iletim gibi hakların açıkça sayıldığı bir madde istemelisiniz.

Sözleşmede şu sorulara cevap arayın:

• Düzenlenebilir kaynak dosyaları alacak mısınız ve dosyalar hangi hesapta duracak?
• Hak devri süre veya coğrafya sınırı içeriyor mu?
• Stok görsel, ikon ve font lisanslarının sahibi kim olacak?
• Tasarımcı çalışmayı portföyünde gösterebilir mi?

Figma dosyasının tasarımcının kişisel hesabında kalması, pratikte sık gördüğüm bir sorundur. Ayrılık kötü biterse dosyaya erişiminiz de biter. Bu nedenle çalışma alanını baştan şirket hesabınızda açmanızı öneririm.

8. Kritik nokta: Kaç revizyon turu var ve revizyon neyi kapsıyor?

"Sınırsız revizyon" kulağa cömert gelir; ama pratikte ya kaliteyi düşürür ya da tasarımcının bir noktada projeyi sürüncemede bırakmasına yol açar. Sağlıklı olan, her aşama için belirli sayıda revizyon turu tanımlamak ve "revizyon" ile "kapsam değişikliği" arasındaki çizgiyi yazmaktır.

Örneğin bir butonun rengini değiştirmek veya bir bölümün sırasını kaydırmak revizyondur. Buna karşılık, onay almış bir wireframe'e yeni bir sayfa şablonu eklemek veya hedef kitleyi değiştirmek kapsam değişikliğidir ve ayrı fiyatlanır. Bu ayrım yazılı değilse, iki taraf da haklı olduğunu düşündüğü bir tartışmaya girer.

Revizyon sürecini verimli kılmanın en kolay yolu, geri bildirimi tek elden toplamaktır. Şirketinizde beş kişi ayrı ayrı yorum yazarsa tasarımcı birbiriyle çelişen talepler alır. Bu yüzden bir karar verici belirleyin, yorumları o kişi birleştirsin ve her turda "tamam" ya da "şu maddeler değişsin" diye net bir cevap dönsün. Ayrıca her tur için bir süre tanımlayın; örneğin geri bildirimi beş iş günü içinde vermeyi taahhüt edin.

9. Kritik nokta: UI UX tasarım hizmeti bitince geliştirme ekibine devir nasıl olacak?

Tasarımın ekranda güzel durması yetmez; kodlanabilir olması gerekir. Devir aşaması, UI UX tasarım hizmeti ile yazılım arasındaki köprüdür ve en çok kaybı burada görürsünüz. Geliştirici bir ekranın mobilde nasıl davranacağını, bir hata mesajının nerede çıkacağını veya boş bir listenin nasıl görüneceğini bilmiyorsa, bu kararları kendisi verir.

Devir paketinde görmek istediğim öğeler şunlardır:

• Masaüstü, tablet ve mobil kırılımları için ayrı ekranlar veya duyarlı davranış notları.
• Boş liste, yükleme, hata ve başarı durumları.
• Dışa aktarım halinde ikonlar ve görseller (SVG ve uygun boyutlarda raster dosyalar).
• Animasyon ve geçiş notları.
• Tasarımcının geliştirme sırasında soru cevaplamak için ayırdığı destek süresi.

Son maddeye özellikle dikkat edin. Birçok teklif, tasarım dosyası teslim edildiği anda biter. Oysa geliştirme sırasında mutlaka sorular çıkar. Bu nedenle teklife belirli bir destek süresi ve canlıya hazır sayfaların tasarıma uygunluğunu kontrol eden bir "tasarım gözden geçirme" adımı eklemenizi öneririm. Mobil tarafın neden önce düşünülmesi gerektiğini mobil öncelikli tasarım yazısında ayrıntılı anlattım.

10. Kritik nokta: UI UX tasarım hizmeti için hangi fiyatlandırma modeli uygun?

UI UX tasarım hizmeti fiyatları, projenin kapsamı kadar fiyatlandırma modeline de bağlıdır. Aynı işi iki tedarikçi farklı modellerle teklif ettiğinde rakamları doğrudan karşılaştırmak yanıltıcı olur. Aşağıdaki tablo dört yaygın modeli, sizin açınızdan artı ve eksileriyle özetliyor:

Hangi modeli seçerseniz seçin, ödeme planını aşamalara bağlamanızı öneririm: örneğin keşif onayı, wireframe onayı, UI teslimi ve devir. Böylece her ödeme, elinize geçen somut bir çıktıyla eşleşir. Web projelerinde tasarımı ve geliştirmeyi tek elden almak istiyorsanız web tasarım hizmeti sayfasında nasıl çalıştığımı görebilirsiniz.

11. Kritik nokta: Portföyü nasıl okumalısınız?

Portföy, bir tasarımcının vitrinidir; ama vitrin her zaman mağazanın tamamını göstermez. Güzel ekran görüntüleri, UI becerisini gösterir. UX becerisini görmek içinse süreci anlatan vaka çalışmalarına bakmanız gerekir.

İyi bir vaka çalışmasında şu soruların cevabını bulursunuz: Problem neydi? Kimlerle konuşuldu? Hangi alternatifleri denediler ve neden vazgeçtiler? Sonuçta ne değişti? Eğer portföyde yalnızca son halin parlak mockup'ları varsa, tasarımcıdan bir projeyi baştan sona anlatmasını isteyin. Özellikle "hangi kararınız test sonrası değişti?" sorusu, sürecin gerçekten yaşanıp yaşanmadığını çok hızlı ortaya çıkarır.

Portföyde dikkat ettiğim diğer işaretler şunlar:

• Sizin sektörünüze veya benzer karmaşıklıktaki projelere örnek var mı?
• Yayındaki projeler hâlâ tasarlandığı gibi mi, yoksa canlıda çok mu farklı?
• Portföy mobil ekranları da içeriyor mu, yoksa yalnızca masaüstünü mü?
• Referans verilen işletmeyle kısa bir görüşme yapma imkanınız var mı?

Canlı projeleri kendiniz gezmek, en ucuz ve en dürüst testtir. Tamamlanan işlerin nasıl göründüğünü merak ederseniz referanslar sayfasındaki örneklere de bakabilirsiniz.

12. Kritik nokta: Sözleşmede hangi maddeler mutlaka olmalı?

Önceki on bir maddenin hepsi, sonunda sözleşmeye yazıldığında güvence kazanır. Sözlü anlaşmalar proje iyi giderken sorun çıkarmaz; ama ilk gecikmede herkes farklı bir şey hatırlar. Bu nedenle en azından aşağıdaki başlıkların sözleşmede ya da ekindeki iş tanımında yer almasını isteyin:

1. Kapsam ve teslimat listesi: ekran sayısı, kırılımlar, dahil ve hariç kalemler.
2. Takvim ve bağımlılıklar: sizin içerik ve geri bildirim teslim tarihleriniz dahil.
3. Revizyon hakları ve kapsam değişikliği prosedürü.
4. Fikri hakların devri ve kaynak dosya teslimi.
5. Ödeme planı ve aşama onay kriterleri.
6. Gizlilik ve kişisel veri: araştırma kayıtları ve müşteri verisinin nasıl saklanacağı.
7. Fesih koşulları: proje yarıda kalırsa o ana kadar üretilen işin durumu.
8. Devir sonrası destek süresi.

Kişisel veri maddesini çoğu işletme unutur. Kullanıcı görüşmelerinin kaydı alınıyorsa veya tasarımcı gerçek müşteri verisiyle çalışıyorsa, bu verinin nasıl saklanacağı ve ne zaman silineceği yazılmalıdır. Fesih maddesi de benzer şekilde önemlidir; çünkü yarım kalan bir projede ödediğiniz aşamaların dosyalarını alabilmek, yeni bir tedarikçiyle sıfırdan başlamaktan çok daha ucuzdur.

Teklif toplarken hangi ek soruları sormalısınız?

On iki nokta, teklifin iskeletini kurar. Ancak iki teklif arasında karar verirken şu ek sorular çoğu zaman belirleyici olur:

• Projede fiilen kim çalışacak? Satış görüşmesine gelen kıdemli tasarımcı mı, yoksa ekipteki başka biri mi?
• Aynı anda kaç projeye bakıyorsunuz ve bizim işimize haftada ne kadar zaman ayıracaksınız?
• İçerik (metin, görsel) kimin sorumluluğunda? Tasarımcı yer tutucu metinle mi çalışacak?
• Başarıyı nasıl ölçeceğiz? Tasarım sonrası hangi metriğin iyileşmesini bekliyoruz?
• SEO tarafından kim sorumlu? Başlık yapısı, URL'ler ve içerik hiyerarşisi tasarımda nasıl yer alacak?

İçerik sorusu özellikle önemlidir. Gerçek metin olmadan yapılan tasarım, metin geldiğinde çoğu zaman çöker: başlıklar taşar, kartlar eşitsiz uzar. Bu yüzden en azından ana sayfalar için taslak içeriği tasarımdan önce hazırlamanızı öneririm.

SEO sorusunu da atlamayın. Mevcut bir siteyi yeniliyorsanız, tasarım kararları sıralamalarınızı doğrudan etkileyebilir; site yenilemede SEO koruma rehberi bu riski adım adım ele alıyor.

Hangi uyarı işaretleri sizi masadan kaldırmalı?

Bazı cevaplar, fiyat ne kadar cazip olursa olsun bir sonraki adıma geçmemeniz gerektiğini gösterir. Sahada en sık gördüğüm uyarı işaretleri şunlardır:

• Tedarikçi sizinle hiç konuşmadan ve sitenizi incelemeden teklif gönderdi.
• Kaynak dosya sorusuna "onu vermiyoruz" cevabı geldi ve alternatif bir çözüm gelmedi.
• Erişilebilirlik sorusuna "o geliştiricinin işi" cevabı geldi.
• Portföydeki projelerin süreci hakkında soru sorduğunuzda somut bir anlatım gelmedi.
• Tedarikçi tüm bedeli peşin istiyor ve aşama onayı yok.

Bu işaretlerden biri tek başına kesin bir hüküm anlamına gelmez. Örneğin küçük bir serbest tasarımcı peşinat isteyebilir ve bu makul olabilir. Yine de iki veya üç işaret bir araya geldiğinde, ileride yaşayacağınız sorunların habercisi olma ihtimali yüksektir. Dolayısıyla karar vermeden önce bu listeyi teklif karşılaştırma tablonuza bir sütun olarak eklemenizi öneririm.

UI UX tasarım hizmeti sonrasında hangi sonuçları ölçmelisiniz?

Tasarım projesi, ekranlar teslim edildiğinde değil, yeni tasarım canlıya çıkıp kullanıcılarla buluştuğunda sınava girer. Bu nedenle proje başlamadan önce hangi metriklerin izleneceğini ve mevcut değerlerini not etmenizi öneririm. Aksi halde "yeni tasarım işe yaradı mı?" sorusuna yalnızca izlenim üzerinden cevap verirsiniz.

İzlemeye değer metrikler projeye göre değişir. Kurumsal bir sitede form gönderimi ve teklif talebi sayısı öne çıkar; bir e-ticaret sitesinde sepete ekleme ve ödeme adımlarındaki terk oranı; bir SaaS panelinde ise belirli bir görevi tamamlama süresi ve destek talebi sayısı. Hangi hedefin sizin için doğru olduğunu belirlemek için dönüşüm hedefi belirleme rehberini kullanabilirsiniz.

Bir uyarı: tasarım değişikliğinin etkisini yalnızca canlıya çıktığı ilk haftaya bakarak yorumlamayın. Mevsimsellik, reklam bütçesi ve kampanyalar sonuçları karıştırır. Karşılaştırmayı benzer dönemler arasında ve mümkünse birkaç haftalık veriyle yapın.

Tasarımı dönüşüm hedefiyle nasıl ilişkilendirmelisiniz?

Birçok işletme UI UX tasarım hizmeti alırken "daha modern görünmek" hedefiyle yola çıkar. Modern görünmek kötü bir hedef değil; ama tek başına ölçülebilir de değil. Tasarımcıya brifing verirken görünüm beklentisinin yanına mutlaka bir iş hedefi ekleyin.

Örneğin "ziyaretçilerin hizmet sayfasından teklif formuna daha kolay ulaşması" ya da "mobilde ödeme adımında daha az kişinin vazgeçmesi" gibi hedefler, tasarımcının kararlarını yönlendirir. Böylece tartışmalar "bu renk hoşuma gitmedi" düzleminden "bu değişiklik hedefe hizmet ediyor mu?" düzlemine geçer. Bu yaklaşımın ayrıntılarını dönüşüm odaklı web tasarım yazısında bulabilirsiniz.

Hedef netleştiğinde tasarımcıdan her ana ekran için "bu ekranın birincil amacı ne?" sorusunun cevabını yazmasını isteyebilirsiniz. Bu küçük alışkanlık, gereksiz bölümleri ayıklamanın ve ekranı sadeleştirmenin en pratik yoludur.

Karar vermeden önce neyi netleştirmelisiniz?

Kısacası, iyi bir UI UX tasarım hizmeti satın almanın sırrı doğru tasarımcıyı bulmak kadar doğru soruları sormaktan geçer. Kapsamı teslimat listesiyle yazdırın, araştırma ve testin içini doldurun, erişilebilirlik seviyesini belirleyin, kaynak dosyaları ve hakları sözleşmeye bağlayın ve devir sonrası desteği unutmayın.

Teklifleri aynı şablon üzerinde karşılaştırdığınızda, en düşük fiyatın çoğu zaman en dar kapsamı temsil ettiğini görürsünüz. Bu, pahalı teklifin her zaman doğru olduğu anlamına gelmez; ama ödediğiniz bedelin karşılığını satır satır görmenizi sağlar.

Projenizi bu 12 noktaya göre birlikte değerlendirmek isterseniz iletişim sayfasından bana yazabilirsiniz. İlk görüşmede mevcut sitenizi ve hedeflerinizi konuşur, hangi teslimatların gerçekten gerekli olduğunu birlikte ayıklarız.

Son bir öneri: kararı yalnızca tasarım ekibinin sunumuna bakarak vermeyin. Teklifi, işi günlük olarak yönetecek kişiyle ve geliştirme tarafındaki sorumluyla birlikte okuyun. Böylece hem teslimatların gerçekten kullanılabilir olup olmadığını hem de sizin tarafınızdaki iş yükünü baştan görürsünüz. Özetle, iyi hazırlanmış bir brif ve net bir sözleşme, tasarımcı seçiminin yarısı kadar önemlidir.