Frontend Developer CV'sinde UI/UX Farkındalığının İspatı: "Kullanıcı Odaklıyım" Cümlesinin Ötesine Geçme Rehberi

"Kullanıcı odaklıyım" yazan herkes aynı şeyi söylüyor

Bir frontend geliştirici CV'sini eline alıp ilk on saniye içinde göz gezdirdiğinde şu satırla karşılaşmak sıradan bir hale geldi: "UI/UX prensiplerine hâkim. Kullanıcı odaklı çalışan bir geliştiriciyim." Cümle yerinde olabilir. Ama yüzlerce önüne gelen aynı cümle, artık ne ATS'nin ne de insan okuyucunun hafızasında yer etmiyor. CV hazırlama sürecinde bu tür "özellik listesi" satırları, bir noktada herkesin kullandığı ortak havuza düşüyor; sonra sıralama geldiğinde buzdolabının arkasında unutulan bir yapışkan not kadar etkisiz kalıyor.

Peki gerçekten kullanıcı deneyimini düşünen bir frontend geliştirici, bu düşünceyi nasıl ispatlar? İddiayı virgülden sonra sıralanan "tutkulu", "detaycı", "sonuç odaklı" sıfatlarıyla süslemek değil; tasarım kararlarının izini sürmek. Erişilebilirlik bilincini somutlaştırmak, performans metriklerini UX diliyle yeniden yazmak gerekiyor. Bu yazı, "cv bedava" şablonlarının ürettiği klişelerden çıkıp, UI/UX farkındalığını ölçülebilir bir satıra. Hatta satırlar bütününe dönüştürmenin yollarını ele alıyor.

Neden "UI/UX farkındalığı" cV'de çoğu zaman görünmez kalır?

Sebebi basit: UI/UX, çoğu CV'de bir "yetkinlik alanı" gibi yazılıyor, bir "yapılmış iş" gibi değil. Oysa ATS bu cümleyi okurken bir eylem, bir araç, bir ölçüm arıyor. Kısaca, insan okuyucu ise kanıt istiyor: Bu kişi hangi ekranda hangi kararı aldı, hangi prensiple değiştirdi, ne oldu?

Pratikte, cV analiz araçlarının da sıkça işaret ettiği üzere. Frontend pozisyonlarına binlerce başvuru geliyor ve bu başvuruların ciddi kısmı aynı kelime havuzunu paylaşıyor. "Kullanıcı odaklı", "responsive". Bir noktada, "modern UI", "tasarım sistemi" gibi ifadeler tek başlarına hiçbir şey anlatmıyor; ne var ki yanlarında bir karar. Bir araç ismi veya bir gözlem geldiğinde bir cümleye dönüşüyorlar.

İddia ile kanıt arasındaki mesafe

Bir satırda "UI/UX bilincine sahibim" yazmak, bir doktora "sağlığa önem veriyorum" demek gibi. Herkes için yerinde, kimse için anlamlı değil. Hâlbuki "Bir checkout akışında form alanlarını on ikiden beşe indirip terk oranının belirgin biçimde düşmesini sağladım" demek, hem ATS'nin eylem fiili taramasına takılır hem de insan okuyucunun zihninde bir film oynatır.

Tasarım kararını kanıta çevirmenin üç katmanı

Aslına bakılırsa, uI/UX farkındalığını CV'de ispatlamak, aslında her maddeyi üç katmandan geçirmekten ibaret. Bu katmanlar, yazılımcının iş günlüğünde zaten var olan düşünceyi, CV'nin sığ alanına taşımanın en sağlam yolu.

1. Katman: karar anı, hangi problemi gördün?

Frontend geliştirici, tasarımı uygularken onlarca mikro karar verir. Bunların çoğu commit mesajlarında, PR açıklamalarında, ekip sohbetlerinde kaybolur. Oysa CV'ye taşınacak ilk katman, problemin kendisi.

• "Mobil kullanıcıların kayda değer bir kısmı sepet sayfasında işlemi yarıda bırakıyordu."
• "Klavye ile gezinme yapan ekran okuyucu kullanıcıları form hatalarını algılayamıyordu."
• Çoğu durumda, "Dashboard'un ilk yükleme süresi kullanıcıların sayfayı terk etmesine neden oluyordu."

Sahada, bu cümlelerin ortak noktası, başında bir gözlem, sonunda bir bağlam olması. ATS'nin aradığı eylem fiilleri burada zaten doğal olarak var: "algılayamıyordu", "terk ediyordu", "neden oluyordu".

2. Katman: uygulama anı, neyi, neden, hangi prensiple değiştirdin?

İkinci katman, yapılan işin kendisi. Burada tasarım prensipleri (yakınlık, hizalama, hiyerarşi), erişilebilirlik kuralları (WCAG. ARIA), etkileşim prensipleri (Fitts Yasası. Hick Yasası, Nielsen heuristikleri) ve teknik kararlar (state yönetimi, lazy loading, skeleton loader) devreye girer.

Örneğin:

"Sepet sayfasındaki on iki form alanını beşe indirip, zorunlu olmayan bilgileri tek adımlı bir 'daha sonra ekle' akışına taşıdım. Alan sayısındaki bu azaltma, Nielsen'ın 'kullanıcı özgürlüğü ve kontrol' heuristiğiyle örtüşüyor; aynı zamanda dönüşüm hunisinin ilk direncini kaldırmayı hedefliyordu."

Burada cümlenin içine yerleşen "Nielsen'ın heuristiği" ifadesi, geliştiricinin tasarım okuryazarlığını sadece söylemekle kalmıyor, kaynağıyla birlikte gösteriyor. ATS için de altın değerinde bir anahtar kelime: "heuristic evaluation".

3. Katman: sonuç anı, ölçülebilir veya gözlemlenebilir etki

Son katman, yapılan değişikliğin ne ürettiği. Sahada, ölçülebilir etki her zaman mümkün olmayabilir; o zaman gözlemsel. Nitel bir kanıt da kabul edilebilir bir kapanış cümlesi olur.

• "A/B testi sonucunda dönüşüm hunisinin tamamlanma oranı önceki versiyona göre belirgin biçimde arttı."
• "Sayfa yükleme süresi yarıdan fazla kısaldı."
• "Erişilebilirlik denetiminden (Lighthouse) düşük puandan yüksek puana yükseldi."
• "Müşteri destek ekibine gelen 'sayfayı bulamıyorum' tipi şikâyetler iki ay içinde belirgin biçimde azaldı."

Sahada, eğer sayı yoksa, aşama anlatımı da ikna edici olur: "Kullanıcı testi oturumları düzenledim. Beş katılımcıdan dördü yeni akışı ilk denemede tamamladı." Rakam yokluğu, teknik varlığıyla telafi edilir.

Erişilebilirlik satırı: "a11y yapıyorum" demeyi bırakmak

Frontend dünyasında erişilebilirlik artık bir niş bilgi değil; çok sayıda ülkenin yasal düzenlemesinde yer alan. Göz ardı edilemeyecek bir zorunluluk. CV'de bu konuyu tek kelimeyle geçiştirmek, tam da farkındalığın olmadığının işareti olarak okunuyor.

Erişilebilirliği somutlaştıran örnek cümleler

• Bir noktada, "Form hata mesajlarını aria-describedby ile etiketleyip ekran okuyucu testlerinde (NVDA, VoiceOver) doğruladım."
• "WCAG 2.1 AA renk kontrast oranlarını sağlamak için tasarım token'larını güncelledim."
• "Klavye ile gezinilebilir modal yapısı kurup focus trap uyguladım."
• "Skip-to-content linki ekleyerek ekran okuyucu kullanıcılarının ana içeriğe tek Tab ile ulaşmasını sağladım."

Şöyle ki, bu cümlelerin üç kayda değer işlevi var: ATS'nin aradığı teknik terimleri barındırıyor (aria-describedby. WCAG, focus trap), insan okuyucuya kararın arkasındaki düşünceyi aktarıyor, ve "erişilebilirlik" kelimesini tek başına bırakmıyor.

Pratikte, tasarım sistemi ve design token deneyimini cV'ye taşımak

Pratikte, "Design system kurdum" ya da "design system'e katkıda bulundum" cümleleri, ekipten bağımsız okunduğunda belirsiz. Tasarım sistemi deneyimini CV'de kanıtlamak için katmanların açıkça yazılması gerekiyor.

Hangi kararı sen mi aldın?

Çoğu frontend geliştirici, büyük bir tasarım sisteminin tek bir parçasını geliştirir. CV'de bunu "şirketteki tasarım sistemini kurdum" diye yazmak, gerçeği saptırmak değil ama belirsizleştirmek. Daha dürüst ve daha güçlü bir ifade:

"Storybook üzerinde düzenli olarak yeni bileşen yayınladım; bu bileşenlerin bir kısmını sıfırdan tasarlayıp, geri kalanını Figma'dan React'e taşıdım ve accessibility testlerinden geçirdim."

Burada sorumluluk paylaşımı açık. Okuyucu, geliştiricinin neleri sıfırdan yaptığını, neleri uyarladığını görebiliyor. ATS açısından da "Storybook", "Figma", "React", "accessibility" terimleri geçiyor.

Design Token'larla Çalışmak

Renk, tipografi, boşluk ve motion değerlerini tasarım token'ları olarak yönetmek, hem tasarımcı hem geliştirici tarafında ortak bir dil kurar. CV'de bu çalışma şöyle somutlaştırılabilir:

• "Tasarım token'larını JSON formatında Storybook'a entegre edip tema değişikliklerinin günler süren süreden dakikalara inmesini sağladım."
• "Marka yenileme sürecinde renk token'larını yeniden adlandırıp semantic hale getirdim (örn. Color.action.primary)."
• "Motion token'ları ekleyerek prefers-reduced-motion kullanan kullanıcılar için otomatik olarak animasyonları devre dışı bırakan bir yapı kurdum."

Core web vitals'ı UX diliyle yeniden yazmak

Frontend geliştiricinin en somut UX kanıtı, performans metrikleridir. Kısaca, lCP, CLS, INP gibi Core Web Vitals değerleri, Google'ın ötesinde doğrudan kullanıcı deneyimini yansıtır. CV'de bu metrikler teknik bir "optimizasyon yaptım" cümlesinin ötesine taşınabilir.

Teknik veriyi kullanıcı hikâyesine çevirmek

"LCP değerini düşürdüm" satırı doğru, ama tek başına soğuk. Yanına bir kullanıcı gözlemi eklendiğinde ısınır:

Kısaca, "Ana sayfa LCP değerini kritik ölçüde iyileştirdim; bu sayede ana içerik mobil cihazlarda çok daha erken görünür hale geldi. Aynı dönemde hemen çıkma oranında belirgin bir düşüş gözlemlendi."

Şöyle ki, hâlbuki CV alanı kısıtlıysa, sade bir teknik satır da iş görür. Burada başlıca olan, UX'in sadece "buton rengini değiştirdim" değil, sayfa yaşam döngüsünün her katmanında var olduğunu göstermektir.

Hangi metrik hangi UX sorununa karşılık gelir?

• LCP: Kullanıcının "sayfa yavaş açılıyor" hissi. İçeriğin geç gelmesi.
• CLS: İçerik zıplaması, hatalı tıklama hissi, güven kaybı.
• İşin aslı, ıNP: Tıklamadan yanıt gelene kadar geçen süre, "uygulama donuk" hissi.

Kısaca, bu üçlü, frontend geliştiricinin UX okuryazarlığının en güçlü göstergesi. CV'de üçü birden geçiyorsa, geliştirici sadece "performans iyileştirmesi yaptım" değil. "kullanıcının sayfayla ilişkisini ölçülebilir biçimde iyileştirdim" demiş oluyor.

Kullanıcı testi ve geri bildirim döngüsünü göstermek

UI/UX farkındalığının en güçlü ispatı, geliştiricinin geliştirme döngüsüne kullanıcı sesini dahil etmesidir. Çoğu yazılımcı bu çalışmayı yapar ama CV'de yazmaz; yazılmayan şey, okuyucu için yoktur.

Hangi süreçleri cV'ye dökersin?

• "Beş katılımcıyla usability test oturumları düzenleyip, navigasyon menüsündeki etiketleri yeniden adlandırdım."
• "Hotjar kayıtlarını inceleyerek en çok terk edilen adımı belirleyip, o adımdaki mikro animasyonu sadeleştirdim."
• "Müşteri destek ekibinin haftalık olarak paylaştığı UX kaynaklı şikâyetleri backlog'a çevirip, sprint içinde kapatıldı."

Genelde, bu satırlar, geliştiricinin sadece piksel taşımadığını, kullanıcı davranışını gözlemleyip ürün kararına dönüştürdüğünü kanıtlar. CV analiz araçlarının da işaret ettiği gibi. Bu tür süreç odaklı cümleler, "UX bilgim var" gibi soyut ifadelerden çok daha fazla dikkat çeker.

Portfolio ve vaka çalışması bağlantısının stratejik yeri

Aslına bakılırsa, frontend geliştiricinin UI/UX farkındalığını ispatlamasının en güçlü tamamlayıcısı, portfolyo veya vaka çalışması bağlantısıdır. CV'de bu bağlantı "websiteme bakın" şeklinde bırakılmamalı; belirli bir projeye, hatta belirli bir karara yönlendirmelidir.

Doğrudan bir karara götüren bağlantı örnekleri

• "Sepet akışı yenileme kararı için: portfolyo.example.com/checkout-case"
• "Tasarım sistemine geçiş sürecinin teknik dökümü: portfolyo.example.com/design-system"
• "Erişilebilirlik denetim raporları: portfolyo.example.com/a11y"

Genel bir portfolyo linki yerine, CV'nin iddiasını doğrudan kanıtlayan sayfaya yönlendirmek, okuyucu için zaman kazandırır. Çoğu durumda, aTS açısından da bağlantının etiketi ("checkout-case" gibi) anahtar kelime işlevi görür.

Case study yazımının üç altın kuralı

1. Pratikte, problem cümlesiyle başla: "Bu ekran neden vardı, ne işe yarıyordu, nerede tökezliyordu?"
2. Karar sürecini anlat: "Şu seçenekleri düşündüm, şu heuristiği uyguladım, şu testleri yaptım."
3. Etkiyi somutlaştır: "Sonuç şu oldu, metrik şu yöne gitti, geri bildirim şöyle geldi."

Bu üçlü, CV'deki tek satırın portfolyoda genişlemesidir. Okuyucu, satıra takılır, bağlantıya tıklar, derinleşir. Bu akış, CV'nin işe alma sürecindeki en güçlü senaryolarından biridir.

UI/UX İfadelerini ATS'nin Göreceği Kelimelere Çevirme Sözlüğü

CV analiz araçları, başvurulan pozisyonun iş ilanında geçen anahtar kelimeleri tarar. Frontend ve UI/UX kesişiminde sıkça kullanılan ve ATS'nin yakaladığı terimler şunlar:

• Heuristic evaluation: → Nielsen'ın 10 heuristiğini uyguladığını gösteren cümle.
• Accessibility / WCAG / a11y: → Somut bir sürüm (WCAG 2.1 AA) ile birlikte yazılmalı.
• Kısaca, design system / Design tokens: → Hangi aracın (Storybook, Figma Tokens, Style Dictionary) kullanıldığı belirtilmeli.
• Core Web Vitals / LCP / CLS / INP: → Akış ve gözlem cümleleriyle birlikte.
• Usability testing / User research: → Kaç katılımcı, hangi yaklaşım (moderated, unmoderated).
• Information architecture / Sitemap / User flow: → Karar anını içeren cümleyle.
• Responsive design / Mobile-first: → Hangi breakpoint'lerde ne değişti.

Aslına bakılırsa, bu sözlük, cv hazırlama sürecinde frontend geliştiricinin en sık başvurduğu kaynaklardan biri olmalı. Her terim, CV'de tek başına değil, eylem ve sonuçla birlikte yer aldığında değer kazanır.

Sık yapılan üç hata ve nasıl düzeltilir

Hata 1: "Tasarımcılarla uyumlu çalışırım"

Bu cümle, neredeyse tüm frontend CV'lerinde var. Şöyle ki, sorunu şu: Herkes bunu yazıyor, kimse bunu kanıtlamıyor. Yerine ne yazılabilir?

"Tasarım ekibiyle düzenli hand-off toplantıları düzenleyip, geliştirme sırasında karşılaşılan tutarsızlıkları (örn. Spacing scale uyumsuzluğu) token güncellemeleriyle kapattım."

Bir noktada, hata 2: uX'i sadece görsel karar olarak anlatmak

"Renk paletini yeniledim", "tipografiyi değiştirdim" gibi satırlar, UX'in sadece estetik katmanını anlatır. Oysa UX, kullanıcının amacına ulaşma sürecinin tamamıdır. Daha güçlü bir ifade:

Bir noktada, "Kayıt akışındaki tek sayfalık uzun formu birden fazla adıma böldüm; her adımda yalnızca zorunlu bilgileri isteyip, geri kalanını son adıma aldım. Tamamlanma oranında belirgin bir artış gözlemlendi."

Hata 3: "User-Centric" sıfatını boş yere kullanmak

"User-centric", "customer-focused", "human-centered" gibi sıfatlar, kelime havuzunda çok yer kaplar ama içi boştur. Bunlar fakat ardından gelen somut cümleyle anlam kazanır. Tek başına kullanıldığında ATS'nin kelime sayacı için bir artı, okuyucunun zihninde bir eksi puan olur.

Hangi UI/UX yetkinliği hangi pozisyona uyuyor?

Genelde, frontend geliştiricinin CV'sinde UI/UX vurgusunun yoğunluğu, hedef pozisyona göre değişir. Yanlış pozisyona isabetsiz ağırlık vermek, CV'nin genelinde bütünlüğü bozar.

Sadece frontend pozisyonu

Bir noktada, ağırlık performans, erişilebilirlik, tasarım sistemi, kod kalitesinde olmalı. UI/UX, bu satırların içine serpiştirilmiş gözlemler olarak yer alır.

Frontend + tasarım işbirliği gerektiren pozisyon

Pratikte, tasarım aracı kullanımı (Figma), tasarım hand-off süreci, prototipleme deneyimi açıkça yazılmalı.

Product geliştirme odaklı startup pozisyonu

Sahada, kullanıcı testi, ürün keşfi, A/B test deneyimi öne çıkmalı. Teknik kararlar bu çerçevede anlatılmalı.

Pratikte, tasarım bilinci tek satırda değil, kararların izinde yaşar

Frontend Developer CV'sinde UI/UX farkındalığının gerçek ispatı. Özel bir bölüm açıp oraya "UI/UX" başlığı atmakla değil, her maddenin içine tasarım düşüncesinin izini serpmekle olur. Erişilebilirlik bilinci bir token güncellemesinde, performans bilinci bir LCP iyileştirmesinde, kullanıcı empatisi bir form sadeleştirmesinde yaşar.

Cv bedava şablonlarının ürettiği jenerik listelerin ötesine geçmek isteyen bir frontend geliştirici için yol haritası kısadır: Her yaptığın işin problemini yaz. Prensibini yaz, sonucunu yaz. UI/UX farkındalığı, yazıldığında kendiliğinden ortaya çıkar; çünkü o farkındalık, zaten yaptığın işin içinde vardı.

Pratikte, aTS'nin kelime havuzunu, insan okuyucunun zamanını ve kendi mesleki kimliğini ciddiye alan her CV. Bir noktada "kullanıcı odaklıyım" cümlesini silip, onun yerine o odaklılığın izini süren birkaç somut satır koyar. İşte o satırlar, gerçek farkındalığın ispatıdır.