Her şey harika gidiyor. Stand-up’lar tıkırında, Figma/Sketch dosyaları düzenli. Müşteriden, departmanlardan, paydaşlardan ses yok. Ama içinizden bir ses hala: “Ekip gerçekten iyi tasarım yapıyor mu? Tasarımcıların performansı iyi mi?” diye soruyorsa, bu paylaşımım ilginizi çekebilir. 👀

Artık sürekli ölçeklenebilir tasarım, tasarım sistemi, yapay zeka vs gibi kavramları konuşuyoruz ama bir şeyi atlıyoruz: Peki ya tasarımcı performansı? ⚠️

Son dönemde yaptığım tasarım toplantılarında, mentorluklarda ve iş görüşmelerinde sıkça karşılaştığım ortak bir soru var:

🎯 Tasarımcının kendisi ne kadar ölçeklenebilir? Hangi kriterlerle bunu anlayabiliriz? Tasarımcının performansı nasıl ölçülür?

En son bu soruyu sorduğumda, lider pozisyonda bir tasarımcı arkadaş şöyle dedi:

“Tasarımcı zaten işini yapıyorsa iyidir. Tasarım işi her yerde böyle zaten, iş çıkıyorsa sorun yoktur. Anlaşılıyor zaten işi yapıp yapamadığı, hissediyorsun zaten, senior kişi bilir işi.”

Meslektaşımın bu yaklaşımını duyunca nutkum tutuldu!! 😳 Ve bu konuda bir içerik üretmek istedim.

Performansı sadece “hissederek” değerlendirmek, hem işveren hem de çalışan açısından risklidir. Sonuçta iş hayatımızda bir aşk yaşamıyoruz; bu bir iş ilişkisi. Duygular değil, veriler konuşmalı. Bu paylaşımımda, bir UI/UX Designer ya da Product Designer’ın performansını nicel (sayısal) verilerle nasıl ölçebileceğimizi kendi deneyimlerimden yola çıkarak anlatacağım. Net, ölçülebilir ve objektif kriterlerle.

Hazırsanız başlayalım mı? 👨🏻‍🚀

•••

Nicel Verilerle Tasarımcı Performansını Nasıl Ölçeriz?

Metaforumuz: Futbol ⚽️

1. Görev Tamamlama Süresi ⏳

Tasarımcının aldığı işi ne kadar sürede tamamladığını takip etmek, sadece hızını değil aynı zamanda süreç yönetimine olan hâkimiyetini de gösterir. Bu metrik üç parçadan oluşacak:

1.1 — Ortalama ticket tamamlama süresi
Bir tasarımcı, aldığı bir işi ortalama kaç günde teslim ediyor? Sürecin sonunda ne kadar yoğunlaşıyor?

💭 Yorumum: Sürecin sonlarına doğru yaşanan ani yoğunluk, 2–0 geride olunan bir maçta 79. dakikada sahaya 3 santrafor sürmeye benzer. O noktada artık sistem değil, bireysel yetenek konuşur. Ya mucizevi bir şekilde üç gol atıp maçı çevirirsiniz, ya da “önümüzdeki maçlara bakarız” dersiniz.

1.2 — Sprint bazlı görev tamamlama oranı
Sprint süresince tasarımcının üzerine aldığı işlerin yüzde kaçını tamamladığına bakarız.

Örnek: 10 görev aldıysa ve 8’ini bitirdiyse oran %80’dir.

💭 Yorumum: Bu oran, takımın 90 dakikada kaç pozisyonu gole çevirebildiğiyle ilgilidir. Pozisyona girmek yetmez, sonuca gitmek gerekir. 10 kere ceza sahasına girip 2 gol atmak başka, 8 gol çıkarmak bambaşkadır. Sprint sonunda skorbordda ne yazdığı, aslında tüm oyunun özetidir.

1.3 — Deadline’a uyum yüzdesi
Tasarımcı aldığı işleri ne kadar zamanında teslim ediyor? Proje ritmini, takım uyumunu ve güvenilirliği bu metrik net şekilde gösterir.

💭 Yorumum: Tüm takım hücuma çıkmış, rakip dengesiz yakalanmış ama sen pası zamanında vermezsen, takım arkadaşın ofsayta takılır. Deadline’a uymamak tam olarak budur! Zamanlamayı kaçırmak. Proje ritmi de işte böyle bozulur.

•••

2. Üretilen Çıktı Oranı 📈

Bir tasarımcının üretim hacmi, performansın en görünür yüzüdür. Ama sadece sayı değil, çeşitlilik de önemlidir. Çok üretmesini beklemek kolay; asıl mesele, üretilenlerin farklı problemleri ne kadar çözdüğü. Sayı tek başına yeterli değil. Önemli olan, içerik ve etkisi.

2.1 — Kabul gören çıktı sayısı / Toplam üretilen çıktı
Çok sayıda ekran çizmek bir beceri değil, sadece tasarım egzersizidir. Yapılan çoğu tasarım “kullanılmıyorsa” boşa üretmektir. Üretilen tasarımların ne kadarı production’a giriyor, kaç tanesi rafa kaldırılıyor? Şimdi buna bir bakalım;

Örnek: 32 ekran tasarlanmış diyelim, bunların sadece 12’si development’a geçmiş, yani ürünle bütünleşmiş/kabul görmüş.

Kabul oranı 12 ÷ 32 = %37.5

Kabul barajı %51 olarak belirlendiyse, bu düşük oran ya tasarım yönlendirmesinin zayıf olduğunu ya da “ne kadar çok, o kadar iyi” yanılgısıyla hareket edildiğini gösterir.

💭 Yorumum: Bu durum, bir maçta 32 şut çekip sadece 12’sini kaleye isabet ettirmek gibidir. Belki oyuna hükmediyor gibi görünürsün ama skorbordda yazan başka bir şeydir. Çok tasarım üretmek değil, doğru yere oynayıp golü bulmak önemlidir. İsabetsiz şutlar da, production’a girmeyen tasarımlar gibi tribüne gider.

2.2 — Ekran başına revizyon sayısı (Revize oranı)
Bir tasarımcı ekranı çizip teslim ediyor ama sürekli geri dönüp tekrar tekrar revize etmek zorunda kalıyorsa burada ciddi bir verimlilik kaybı vardır.

Az revizyon = daha net çözüm, daha etkili iletişim
Çok revizyon = belirsizlik, yetersiz keşif, zayıf problem tanımı

Örnek: 10 ekran çizilmiş diyelim, toplam 35 revizyon geçmiş (v1, v2, v3, v4, Final, Final En Son…)

Revizyon oranı 35 ÷ 10 = 3.5

Bu, her ekranın ortalama 3–4 kez geri döndüğü anlamına gelir. Sprint yakan verimsizlik. Tüm tasarımcıların ağrı noktası olan revize işlemini biraz daha ölçeklenebilir hale getirelim ve revize barajı koyalım. Baraj koymazsak bu metrik sadece “bak bu kadar olmuş” diye kalır, ne zaman aksiyon alınacağını bilmek gerekir.

Peki, baraj ne olmalı?
Bu biraz takıma, projeye ve şirketin tasarıma karşı olgunluğuna göre değişir ama ortalama değerleri şöyle düşünebiliriz:

Politikalarınıza göre değişkenlik gösterebilir tabi ama genel olarak barajı 2.1 / 2.5 alabilirsiniz. Bu “her ekran için en fazla 2 revizyonla işi netleştirelim” gibi bir hedef anlamına gelir.

💭 Yorumum: Bu durum, her pozisyonda hakemin VAR’a gitmesi gibi. Top filelerde mi? Ofsayt mı? Faul var mı? Her şey tartışmalıysa, maç akar mı? Akmaz. Tasarımda da durum aynı: sürekli geri dönülen işler, karar verilemeyen pozisyonlar gibidir. Oyun durur, tempo düşer, motivasyon dağılır. Net brief = net pas = net gol. Revizyon oranı fazlaysa, saha çizgileri bulanık demektir.

2.3 — Arayüz ekran tasarımı
Bazen bir tasarımcı 10 senaryoyu çözmek için 15 ekran çizer. Ama bazen aynı 10 senaryo için 40 ekran çıkar. İşte orada şişkinlik başlar. Bu metrik, gereğinden fazla varyant çıkaran, tek ekranla çözülecek iş için dört çözüm öneren yaklaşımları ortaya çıkarır.

Örnek: 10 senaryo var (giriş, ödeme, şifre sıfırlama vs.), 45 ekran çizilmiş diyelim

Ekran sayısı 45 ÷ 10 = 4.5

Burada şu soruyu sormak gerekir; Gerçekten her senaryo için bu kadar farklı ekran gerekli miydi, yoksa varyant çıkarmak verim gibi mi gösteriliyor?

Peki, bu neden sorun?

1. Bu fazla varyasyonlar, karar verme sürecini zorlaştırır (PM, dev, stakeholder kafayı yer).

2. Prototip oluşturmak karmaşıklaşır.

3. Developer için hangi ekranın final olduğu belirsizleşir.

4. Tasarımın özü kaybolur; çünkü odak çözümde değil, seçenek üretmekte olur.

Bu durumda tasarımcı aslında zamanını “karar netleştirmek” yerine “opsiyon çoğaltmak”la harcar.

Peki, baraj ne olmalı?
Bu biraz takıma, projeye ve şirketin tasarıma karşı olgunluğuna göre değişir ama ortalama değerleri şöyle düşünebiliriz:

Performans göstergesi gibi varyant çıkarılmış olabilir. Kullanıcı senaryosu çözülmüyor, fikir gösteriliyordur. Tasarım süreci yeniden ele alınmalı.

Politikalarınıza göre değişkenlik gösterebilir tabi ama barajı genel olarak 3.6 alabilirsiniz. Bu ölçümle, çok ekran üretip az değer katan tasarımcıyla, az ekranla büyük problem çözen tasarımcıyı ayırt edebilirsin.

💭 Yorumum: Ceza sahasına kadar gelip sürekli pas yapmaya benzer. Herkes ayağındaki topu bir başkasına atar, kimse şut çekmez. 3 pasla gol atılacakken, 13 pasla pozisyonu harcamak gibi. Bol ekran üretmek = bol pas; ama çözüm üretmeyen varyantlar = kaleye gitmeyen atak. Seyirci de, teknik direktör de, developer da bir noktadan sonra “vursana artık!” diye bağırmaya başlar.

2.4 — Component / Design system katkısı
Tasarım sürecinde her şey görünür değildir. Bazı katkılar ekran ekran parlamaz ama takımın verimliliğini, ürünün tutarlılığını ve geliştiriciyle tasarımcı arasındaki iş birliğini doğrudan iyileştirir. İşte design system katkısı tam olarak budur.

Ne demek bu katkı?

• Yeni component’lar üretmek (örn. alert, tooltip, dropdown vs.)

• Mevcut component’ları refactor etmek (auto layout, variants, token kullanımı)

• Renk, tipografi, spacing gibi design token yapıları kurmak

• Kullanım dokümantasyonu oluşturmak (nasıl kullanılır rehberleri)

Bu işler genelde sprint kartlarında yer almaz, ekran sayısı gibi ölçülmez. Ama developer’ın işini kolaylaştırır, takım içinde tutarlılık sağlar, tasarımın sürdürülebilirliğini garanti altına alır.

Neden önemli?
Çünkü design system’ı olmayan ekip, aynı butonu 12 kez yeniden çizer. Çünkü component’i olmayan tasarımcı, her seferinde sıfırdan başlar.

Bu katkıyı nasıl ölçeriz?
“Component katkısı” görünmeyen bir iş olduğu için sayısallaştırılması zordur ama mümkündür:

Design system ilede uğraşan tasarımcı bazen arayüz ekranı üretmiyor olabilir ama 6 kişinin aylarca/binlerce kez kullandığı component yapısını kuruyorsa, o kişinin performansı “ekran sayısıyla” değil “verimliliğe yaptığı katkıyla” değerlendirilmelidir.

💭 Yorumum: Design system’e katkı yapan tasarımcı, sahada topu her defasında düzgün kontrol eden, oyunu bozmayan ve takımı taşıyan gizli kahraman gibidir. Gol atan forvet alkış alır ama o gole giden yolu açan, pası doğru zamanda veren oyuncu çoğu zaman fark edilmez. İşte o oyuncu = design system’la uğraşan tasarımcıdır. Design system’le uğraşan tasarımcı 0 ekran çizip, 20 kişilik ekibin 6 ay boyunca kullandığı bir component set’leri kuruyorsa, o katkıyı sadece “ekran sayısıyla” ölçmek, asist kralını sadece gol sayısıyla değerlendirmeye benzer.

•••

3. Feedback Skoru (CSAT / NPS) 📊

Tasarım bir ekip oyunudur. En iyi tasarımı bile çıkarsan; developer’lar, product manager’lar ve product owner’lar ekip arkadaşların seninle çalışmayı zor buluyorsa, performans eksiktir. İşte bu yüzden subjektif gibi görünen geri bildirimleri, nicel metriklerle ölçmek çok işe yarar. En yaygın ikisi: Memnuniyet skoru (Customer Satisfaction Score — CSAT) ve Net Tavsiye Skoru (Net Promoter Score — NPS)

3.1 — Memnuniyet skoru (CSAT — Customer Satisfaction Score)
Ekip arkadaşlarına/paydaşlara bir soru sorulur. Genelde 1–5 ya da 1–10 arası puanlama istenir.

Örnek: “Bu tasarım çalışmasından ne kadar memnunsunuz?” sorusunu cevaplayan 5 kişi; (4), (4), (5), (5), (4) puanı verdiğini varsayalım. Ortalama: 4.4 = %88 CSAT sonucunu elde ederiz.

%88 CSAT, “Bu tasarım çalışmasından %88 oranında memnun kalınmış.” demek oluyor. Yani ekibin sana güveniyor, işi beğenmiş, birlikte çalışmak verimli geçmiş.

Ne işe yarar bu skor?

1. Geri bildirimi daha objektif hale getirir.

2. Zamanla tasarım sürecindeki iyileşmeleri ölçmeni sağlar.

3. Ekiple olan ilişkini (iletişim, iş teslimi, revize süreci vs.) gözlemlemeni sağlar.

4. “Ben zaten iyi tasarım yapıyorum” kafasından çıkıp takım içi etkini değerlendirme imkânı verir.

💭 Yorumum: CSAT, skorbord değil; tribün sesidir. Maçı kazanmış olabilirsin ama seyirci ıslıklıyorsa bir şeyler eksiktir. Ya da skor berabere bitmiştir ama tribün seni ayakta alkışlıyorsa, doğru yoldasındır. İşte bu skor da onun gibi: ekip içi moral, güven ve uyumun net göstergesi. Sadece gol atmak değil, oyunu beğendirmek de önemlidir.

3.2 — Net Tavsiye Skoru (NPS — Net Promoter Score)
Ekip arkadaşlarına/paydaşlara bir soru sorulur. Puanlama 0–10 arası puanlama istenir.

• Promoters (9–10 puan verenler)
  → Çok memnun, bayılıyorlar. Seni başkasına önerir.

• Passives (7–8 puan verenler)
  → Orta karar. Memnun ama fan değil.

• Detractors (0–6 puan verenler)
  → Memnun değil. Tavsiye etmez, hatta zarar bile verebilir.

Örnek: “Bu kişiyle tekrar çalışmak ister misiniz?” sorusunu cevaplayan 10 kişiden 6’sı 9–10 puan, 3’ü 7–8 puan, 1’i 5 puan verdiğini varsayalım.

Not: 7–8 puan verenler skora dahil edilmez. Çünkü NPS, sadakati ve tavsiye etme isteğini ölçer.

%Promoter = 60%, %Detractor = 10% ise NPS = 60–10 = +50 → bu çok iyi bir skordur. Yüksek NPS = sadece çıktıya değil, iş birliğine ve güvene duyulan memnuniyet.

Nerede Kullanılır?

1. Tasarımcı, product manager, product owner ve developer iş birliği sonrası feedback

2. QA ve developer‘a Figma dosyası teslimi sonrası değerlendirme ve tasarımın netliği ve dev-handoff süreci sonrası

Zamanlama olarak sprint sonları, proje teslimleri ya da çeyrek değerlendirmeleri gibi doğal durak noktalarında, 3 soruluk kısa anketlerle geri bildirim toplanabilir. Çünkü biri iyi tasarım yapıyor olabilir ama ekip onunla tekrar çalışmak istemiyorsa, bu da performansın önemli bir göstergesidir.

💭 Yorumum: NPS, teknik direktörün seni bir sonraki maça ilk 11’e yazıp yazmayacağını gösterir. Sadece iyi oynadın mı değil; takım seninle oynamak istiyor mu? Topu paylaşabiliyor musun, iletişimin güçlü mü, oyunu birlikte kurabiliyor musunuz? Yüksek NPS = “Bu adam sahada güven veriyor” demektir. Düşük NPS ise “topu ayağına almak istiyor ama pas vermiyor” hissi yaratır. Yani skor değil, güven duygusu konuşur.

•••

Sonuç olarak; performansı sadece hissederek değerlendirmek, karşılıklı hayal kırıklıklarına davetiye çıkarmaktır. 🙃 Bu bir iş ilişkisi ve tasarımda da, kariyerlerde de sürdürülebilirlik ancak net beklentiler ve şeffaf metriklerle mümkün. Artık “bu adam fena değil” hissiyatıyla değil, gerçekten değer üreten tasarımcıları somut verilerle ayırt edebileceğimiz bir düzende çalışmalıyız. Çünkü ekip güveni, üretim verimliliği ve ürün kalitesi; rastgele sezgilerle değil, tekrar edilebilir performansla inşa edilir.

Bu yazıdaki metrikler tek başına yeterli olmayabilir. Ama en azından “neyi ölçmemiz gerektiğini” anlamak için bir başlangıç sunar. Bu metrikleri içeren bir hesaplama Google Sheet'ine buradan ulaşabilirsiniz. 🚀

Umarım bu deneyimlerim sizler için yardımcı olmuştur. 🙌