Tasarım borcu (UX borcu) nedir, nasıl ödenir?

Kısaca

Tasarım borcu, hızlı, kolay ya da özensiz bir çözüm yayına alındığında üründe kalan ve zamanla büyüyen sorunlardır. İngilizcede design debt ya da UX debt denir. Birbirini tutmayan bileşenler ve hiç güncellenmemiş eski akışlar tipik örneklerdir. Borcu ödemek için kalemleri listeler, etkiye ve düzeltme maliyetine göre sıralar, her sprintte küçük bir pay ayırırsınız.

Tasarım borcu nedir

NN/g'den Anna Kaley UX borcunu şöyle tanımlar: hızlı, kolay ya da özensiz bir çözüm yayına alındığında deneyimde kalan ve süren sorunlar. Bu borç bilerek de oluşabilir, kazara da. Bence ikisinde de bedeli önce kullanıcı öder.

Türkçede "tasarım borcu" ve "UX borcu" aynı şeyi anlatır. İngilizce kaynaklarda "design debt" ve "UX debt" diye geçer. Ben bu sayfada üçünü aynı anlamda kullanıyorum.

Kaley'nin altını çizdiği nokta, borcun faiz gibi işlemesi. Ele alınmayan sorunlar birbirine eklenir ve temizlik işi giderek büyür.

Teknik borçla benzerlik ve fark

Metafor teknik borçtan gelir. Kaley'nin aktardığına göre teknik borç kavramını Ward Cunningham 1992'de ortaya attı. Ekip en iyi yaklaşım yerine daha hızlı ya da daha kolay bir teknik çözümü yayına alır ve bunun bedelini sonra öder.

Benzerlik açık. İkisinde de bugün bir kısayol alırsınız, faizi yarın ödersiniz. Kaley'ye göre yayından sonra düzeltmek, baştan doğru çözümü yayına almaktan her zaman daha pahalıdır.

Bence asıl fark, faizi ilk kimin hissettiği. Teknik borcu önce ekip hisseder, çünkü her değişiklik biraz daha zorlaşır. Tasarım borcunu ise önce kullanıcı hisseder ve çoğu zaman sesini çıkarmadan ürünü bırakır.

İkisi sık sık birlikte gelir. Eski bir ekran yeni tasarım sistemine taşınamıyorsa sebep çoğu zaman eski koddur. Kaley de iki borcu birlikte ele almayı ve hiçbirini görmezden gelmemeyi önerir.

Borç her zaman kötü değildir. Kaley'ye göre metafor, borçtan ne pahasına olursa olsun kaçınmak gerektiği anlamına gelmez. Bilerek borç doğuracak kararlar dikkatle ve ekipçe verilmeli. Ben buna bir adım eklerim: alınan borcu bir yere yazın.

Tasarım borcu nasıl birikir

Kaley borcun çoğu zaman sıkışık takvimlerde ya da pratik olmayan proje kısıtlarında doğduğunu yazar. Saydığı nedenler şunlar:

  • Kullanıcı testini atlamak.
  • Marka standartlarını ve stil rehberlerini yok saymak.
  • Komitenin tasarlaması, yani her paydaşın bir parça eklemesi.
  • Ürün vizyonunu yanlış anlamak.
  • Başka bir ürünü satın almak ya da onunla birleşmek.
  • Zayıf iletişim ya da eksik dokümantasyon.
  • Yetersiz kalite kontrolü.
  • Eski kod ya da ertelenen yeniden yazım.

Audit'lerde bu nedenlerin sonucu karşıma en çok şu biçimlerde çıkar.

Tutarsız bileşenler

Aynı işi yapan iki buton ya da iki ayrı tarih seçici. Her biri başka bir sprintte, o günün acelesiyle tasarlanmıştır. Kullanıcı neyin tıklanabilir olduğunu her ekranda yeniden öğrenir.

Yamalar

Bir kampanya bandı ya da bir "yeni" rozeti geçici diye eklenir, sonra yerinde kalır. Yamalar üst üste bindikçe ekranın asıl görevi arkada kaybolur.

Eski akışlar

Yeni kayıt akışı tasarlanmıştır ama eski akış hâlâ yayındadır. Satın alınan bir ürünün ekranları ana ürünün menüsünü kullanmaz. Kullanıcı iki ürün arasında gidip geldiğini hisseder.

Yapay zekâ bu birikimi hızlandırabilir. Kaley ve Raluca Budiu'nun 2026 tarihli yazısına göre üretmek, UX değerlendirmesinden daha ucuz hâle geldi. Değerlendirme uygulamanın gerisinde kalınca borç birikir.

Neden sonra ödemek daha pahalı

Burada para rakamı vermeyeceğim. Açtığım kaynaklarda genellenebilir bir maliyet rakamı bulmadım. Kaley ise gerekçeleri şöyle sıralar:

  • Zayıf bir tasarımla çıkmak uzun vadede pazar payını etkiler.
  • Kullanıcılar kötü tasarıma alışır, sonra değişikliğe direnir.
  • Tekrar tekrar yapılan değişiklikler tutarlılık hissini aşındırır.
  • Hatalarınız internette kalır. Bloglar, forumlar ve video kanalları eski sürümü yıllarca anlatmaya devam eder.

İkinci madde bence en çok gözden kaçanı. Kötü bir akış bir yıl yayında kalırsa, düzeltmesi artık bir "değişiklik" olur. O akışa alışmış kullanıcıyı da ikna etmeniz gerekir.

Tasarım borcu nasıl ölçülür

Ölçmenin ilk adımı, borcu görünür kılmak. Kaley borcu bulmak için önce riskli alanlara bakmayı önerir: arayüz, etkileşim, metin ve içerik, bilgi mimarisi ve erişilebilirlik. Müşteri yolculuğunun tutarlılığı ve kanallar arası geçiş de listede.

Bulma yöntemlerinin başına kullanıcı testini koyar. Testi her sprint yayınından önce ve en az ayda bir yapmanızı önerir. Buna sayfa içi anketleri, CSAT ya da NPS puanlarını ve müşteri hizmetleri raporlarını ekler. Geliştiricilerin de katıldığı düzenli ekip toplantılarında herkes borç kalemi önerebilir.

Ben buna bir UX audit ya da heuristik değerlendirme eklerim. Dışarıdan bakan biri, ekibin alıştığı tutarsızlıkları daha kolay görür. Kullanıcının tıklayıp sonuç alamadığı yerler için rage click ve dead click verisi de iyi bir ipucudur.

Bir istisnayı ayırın. Kaley'ye göre A/B testindeki farklı varyantlar geçici ve bilinçlidir, bu yüzden borç sayılmaz. Kazanan varyant ise tasarım sistemine işlenmelidir.

Kaydı nerede tutmalı

Kaley iki yol anlatır. Her borcu doğrudan iş listesine (backlog) ayrı bir kayıt olarak ya da bir etiketle ekleyebilirsiniz. Diğer yolda önce bir tablo tutar, seçtiğiniz kalemleri sonra iş listesine taşırsınız.

Büyük kurumlarda iş listesindeki kalemler kaybolabilir ya da sürekli ertelenebilir. Tablo bu yüzden işe yarar.

Kaley'nin önerdiği sütunlar kullanıcının gözünden açıklama, deneyimdeki yer ve sıklıktır. Bunlara kimin bildirdiği ve düzeltme eforu (düşük, orta, yüksek) eklenir.

Tasarım borcu nasıl önceliklendirilir

Kaley her kalemi iki eksende yerleştirmeyi önerir: kullanıcıya değeri ve düzeltme eforu. Ayrıca sorunun ne kadar ciddi olduğuna, ne sık yaşandığına ve akışın neresinde durduğuna bakarsınız. Ödeme adımındaki bir sorun, ayarlar sayfasının dibindeki bir sorundan önce gelir.

Kaley'nin bir önerisi daha var: mevcut özelliklerdeki UX sorunları çoğu zaman yeni özelliklerden daha yüksek öncelik almalı. Bence ürün ekiplerinin en zor kabul ettiği cümle bu.

Ben ekiplerle çalışırken her ekseni iki seviyeye indiririm. Etki düşük mü yüksek mi, maliyet düşük mü yüksek mi? Böylece dört liste çıkar. Aşağıdaki envanterde kendiniz deneyin.

Borç envanteri

Liste, örnek kalemlerin başlangıç dağılımını gösteriyor. JavaScript açıkken her kalemi kendiniz işaretleyebilirsiniz.

Borç kalemleri

  • B1 Ödeme adımında hata mesajı alanın yanında değil, sayfanın en üstünde çıkıyor.

    Etki yüksek, maliyet düşük. Liste: Hemen yap

  • B2 Sepet, ödeme ve profil ekranlarında üç farklı birincil buton stili var.

    Etki düşük, maliyet düşük. Liste: Fırsat buldukça

  • B3 Eski kayıt akışı hâlâ yayında. Yenisi tasarlandı ama koda dökülmedi.

    Etki yüksek, maliyet yüksek. Liste: Planla

  • B4 Tarih seçimi için iki ayrı bileşen var: biri takvim, biri açılır listeler.

    Etki düşük, maliyet yüksek. Liste: Bırak

  • B5 Kampanya için eklenen geçici bant kapanmıyor ve menünün üstüne biniyor.

    Etki yüksek, maliyet düşük. Liste: Hemen yap

  • B6 Arama sonuçları sayfası eski yazı tipini ve eski boşlukları kullanıyor.

    Etki düşük, maliyet düşük. Liste: Fırsat buldukça

  • B7 Satın alınan bir üründen gelen iade ekranları farklı bir menü yapısı kullanıyor.

    Etki yüksek, maliyet yüksek. Liste: Planla

  • B8 Yönetim panelindeki eski rapor ekranını az kişi açıyor. Baştan yazmak büyük iş.

    Etki düşük, maliyet yüksek. Liste: Bırak

Planınız

  1. Hemen yap (2)

    Etkisi yüksek, düzeltmesi ucuz. Bu sprinte alın.

    • B1 Ödeme adımında hata mesajı alanın yanında değil, sayfanın en üstünde çıkıyor.
    • B5 Kampanya için eklenen geçici bant kapanmıyor ve menünün üstüne biniyor.
  2. Planla (2)

    Etkisi yüksek ama büyük iş. Yol haritasına tarihle yazın.

    • B3 Eski kayıt akışı hâlâ yayında. Yenisi tasarlandı ama koda dökülmedi.
    • B7 Satın alınan bir üründen gelen iade ekranları farklı bir menü yapısı kullanıyor.
  3. Fırsat buldukça (2)

    O ekrana zaten dokunduğunuzda düzeltin.

    • B2 Sepet, ödeme ve profil ekranlarında üç farklı birincil buton stili var.
    • B6 Arama sonuçları sayfası eski yazı tipini ve eski boşlukları kullanıyor.
  4. Bırak (2)

    Şimdilik bırakın ama kayıtta tutun. Üç ayda bir yeniden bakın.

    • B4 Tarih seçimi için iki ayrı bileşen var: biri takvim, biri açılır listeler.
    • B8 Yönetim panelindeki eski rapor ekranını az kişi açıyor. Baştan yazmak büyük iş.

Hemen yap: 2 · Planla: 2 · Fırsat buldukça: 2 · Bırak: 2

Sekiz kalem, kurgusal bir e-ticaret uygulamasına ait örneklerdir. Seçimleriniz hiçbir yere gönderilmez ve saklanmaz.

Borç envanteri: her kalem, etkisine ve düzeltme maliyetine göre dört listeden birine geçer. Etkisi yüksek, düzeltmesi ucuz olanlar ilk sıradadır.

Dört liste bir başlangıçtır. "Bırak" listesi silinmez, kayıtta kalır. Bir ekranı yeniden tasarlarken o listedeki kalemler çoğu zaman "fırsat buldukça" listesine geçer.

Ödeme planı: sprint içinde pay ve tasarım sistemi

Borç tek seferde ödenmez. Kaley üç yol anlatır.

  • Her sprintte pay. Her sprintte ya da iki sprintte bir, borca hikâye puanı ayırın. Hedef, en az bir ya da iki kalem kapatmak.
  • Üç ayda bir temizlik sprinti. Teknik borç ve UX borcu birlikte ele alınır.
  • Tek günlük temizlik. Tam bir sprint ayıramıyorsanız, ekip bir günü yalnızca borca ayırır. Kaley buna "cheese day" der.

Kaley ilerlemeyi paydaşlara kullanıcı değeri ve iş değeri üzerinden anlatmayı önerir. "Beş kalem kapattık" yerine "ödeme adımındaki hata mesajı artık alanın yanında" deyin.

Tasarım sistemiyle ödemek

Tutarsız bileşen borcunun en kalıcı ödemesi bir tasarım sistemidir. NN/g'den Therese Fessenden tasarım sistemini, tasarımı büyük ölçekte yönetmek için yeniden kullanılabilir bileşen ve kalıplardan oluşan standartlar bütünü diye tanımlar. Fessenden'e göre standart öğeleri yeniden kullanmak istenmeyen tutarsızlık riskini düşürür.

Pratikte şöyle işler. Üç farklı buton yerine bileşen kütüphanesinde tek bir buton tanımlarsınız. Renk ve boşluk kararları design token olarak tek yerde durur. Sonra ekranları, o ekrana zaten dokunduğunuz sprintte tek tek taşırsınız.

Kaley ve Budiu yapay zekâ ile üretim yapan ekipler için de aynı yönü gösterir. Tasarım sistemini ve onaylı etkileşim kalıplarını üretim aracına verin. Böylece yeni çıktı daha sağlam bir temelden başlar.

Benim notum

Tasarım borcunda en sık gördüğüm hata, borcu hiç yazmamaktır. Ekip sorunu bilir, Slack'te konuşur, ama kimse bir satıra dökmez. Yazılmayan borç planlanamaz.

Bu yüzden ilk adım olarak bir saatlik envanter toplantısı öneririm. Herkes bildiği kalemleri yazar, sonra yukarıdaki iki soruyla sıralarsınız. "Hemen yap" listesinde kalem varsa, onları bu sprinte koyun.

Küçük bir ekipseniz temizlik sprinti şart değil. Her sprintte bir iki kalem kapatmak bile borcun büyümesini yavaşlatır.

Sık sorulanlar

Tasarım borcu ile UX borcu aynı şey mi?

Pratikte evet. NN/g UX debt terimini kullanır, birçok ekip aynı şeye design debt ya da tasarım borcu der. Hepsi, hızlı ya da özensiz bir çözümün deneyimde bıraktığı süren sorunları anlatır.

Tasarım borcu her zaman kötü müdür?

Hayır. Anna Kaley'ye göre metafor, borçtan her koşulda kaçınmak gerektiği anlamına gelmez. Hız önemliyse borcu bilerek alabilirsiniz. Kaley bu kararın dikkatle ve ekipçe verilmesini önerir. Ben bir de borcun kayda geçirilmesini eklerim.

Her sprintte borca ne kadar zaman ayırmalıyım?

NN/g sabit bir oran vermez. Kaley her sprintte ya da iki sprintte bir hikâye puanı ayırmayı ve en az bir iki kalem kapatmayı önerir. Buna üç ayda bir temizlik sprinti eklenebilir.

A/B testindeki farklı tasarımlar borç sayılır mı?

Sayılmaz. NN/g'ye göre test varyantları geçici ve bilinçlidir, kazanan öğeler de tasarım sistemine işlenir. Bence kazanan işlenmezse, test bittikten sonra kalan fark borca dönüşür.

Kaynaklar (3)
  1. Anna Kaley, UX Debt: How to Identify, Prioritize, and Resolve, Nielsen Norman Group. erişim 2026-11-03; 11 Kasım 2018; tanım, nedenler, bulma, kayıt, önceliklendirme ve ödeme yolları
  2. Anna Kaley ve Raluca Budiu, The Custodial Era of UX: Cleaning Up After AI, Nielsen Norman Group. erişim 2026-11-03; 28 Ağustos 2026; yapay zekâ ile üretim ve UX borcu
  3. Therese Fessenden, Design Systems 101, Nielsen Norman Group. erişim 2026-11-03; 11 Nisan 2021, son gözden geçirme 27 Ağustos 2026; tasarım sistemi tanımı