Kısa cevap: Bir UI/UX tasarımcıda aranan temel beceriler; araştırma ve problem tanımlama, bilgi mimarisi ve akış kurma, görsel tasarım, durum ve etkileşim düşüncesi, erişilebilirlik, prototipleme ve test, karar gerekçesini anlatabilme ve geliştiriciyle çalışmayı kolaylaştıran teknik okuryazarlıktır; bunların her biri unvanla değil, ortaya konan çıktıyla değerlendirilir.
Ben Selçuk Aker. 19 yılı aşkın süredir marka ve dijital ürün tasarımı yapıyorum; web, mobil uygulama ve yönetim paneli arayüzleri işimin önemli bir parçası. Bu rehberde becerileri bir sıfat listesi olarak değil, her birinin işte nasıl göründüğü ve portfolyoda nasıl kanıtlanacağı üzerinden anlatıyorum. Tasarımcı olmak isteyenler için de, ekibine tasarımcı arayanlar için de aynı soruya cevap vermeye çalışıyorum: “Bu beceri gerçekten var mı, nasıl anlaşılır?”
Beceriyi unvanla değil çıktıyla değerlendirin
Özgeçmişlerde “empatik”, “detaycı”, “kullanıcı odaklı” gibi ifadeler sık geçer. Bunlar doğru olabilir, ama doğrulanamaz. Bir beceriyi değerlendirmenin daha güvenilir yolu, o becerinin bıraktığı izi aramaktır:
| Beceri | İşte bıraktığı iz |
|---|---|
| Araştırma ve problem tanımlama | Cevaplanabilir araştırma soruları, gözlem ile yorumu ayıran notlar |
| Bilgi mimarisi ve akış | Hata ve vazgeçme yollarını da içeren akış şeması, mantıklı menü adları |
| Görsel tasarım | Tutarlı yazı ölçeği, okunabilir hiyerarşi, ızgaraya oturan yerleşim |
| Durum ve etkileşim | Boş, hata, yükleme ve başarı ekranları; bileşen varyantları |
| Erişilebilirlik | Ölçülmüş kontrast değerleri, görünür odak, yeterli dokunma alanı |
| Prototip ve test | Görev senaryosu, gözlem notları, bulguya göre yapılmış değişiklik |
| İletişim | Karar gerekçesi yazılmış ekranlar, anlaşılır sunum |
| Teknik okuryazarlık | Geliştiricinin soru sormadan uygulayabildiği devir notları |
Bu tablo, bir sonraki bölümlerin özetidir. Her beceriyi ayrı ayrı ele alalım.
Araştırma ve problem tanımlama
İyi bir UI/UX tasarımcının ilk becerisi doğru soruyu sormaktır. “Kullanıcılar uygulamayı sevmiyor” bir problem tanımı değildir. “Yeni kullanıcıların bir kısmı ilk siparişte adres adımında uygulamadan çıkıyor” ise üzerinde çalışılabilecek bir tanımdır. Tasarımcı mevcut verilere, destek kayıtlarına ve görüşmelere bakarak geniş bir şikâyeti somut bir soruya indirger.
Bu becerinin önemli bir parçası gözlemi yorumdan ayırmaktır. “Katılımcı filtre butonunu üç kez aradı” bir gözlemdir. “Filtre butonu yeterince görünür değil” ise bir yorumdur ve başka açıklamaları da olabilir. Araştırma notlarında bu ayrımı yapabilen tasarımcı, ekibi yanlış çözümlere daha az sürükler. Araştırmanın ekran kararlarına nasıl dönüştüğünü kullanıcı araştırmasını ekran kararlarına dönüştürmek yazısında örneklerle anlattım.
Bilgi mimarisi ve akış kurma
Bilgi mimarisi, içeriğin ve işlevlerin kullanıcının aradığı yerde bulunmasını sağlar. Bu beceri kendini en çok menü adlarında ve gruplamada gösterir. Şirket içinde “cari hesap modülü” denen bir bölüm, kullanıcı için “ödemelerim” olabilir. Akış kurma becerisi ise bir görevin bütün yollarını görebilmektir: yalnız “mutlu yol” değil, kullanıcının geri döndüğü, vazgeçtiği ya da hata yaptığı yollar da.
Bu beceriyi geliştirmek için sık kullandığınız bir uygulamanın bir görevini seçip akışını eksiksiz çizmeyi deneyin. Kaç karar noktası ve kaç hata durumu çıktığını görmek çoğu zaman şaşırtıcıdır. Menü ve kategori adlarında kararsız kaldığınızda, kart sıralama gibi basit yöntemlerle kullanıcıların içeriği nasıl gruplandırdığını görmek de bu becerinin parçasıdır. Burada amaç kullanıcıya menüyü tasarlatmak değil, onların zihnindeki kategorileri anlamaktır.
Görsel tasarım: hiyerarşi, tipografi, renk, ızgara
Arayüzde görsel tasarım, süslemekten çok yön göstermekle ilgilidir. Kullanıcı ekrana baktığında önce neyi görmeli, sonra neye geçmeli? Bu sıra boyut, ağırlık, renk, boşluk ve konumla kurulur.
- Tipografi: Sınırlı sayıda ve tutarlı yazı ölçeği, okunabilir satır uzunluğu, Türkçe karakterleri doğru gösteren yazı aileleri.
- Renk: Marka renklerinin yanında anlam taşıyan renklerin (hata, uyarı, başarı) tanımlanması ve anlamın yalnız renge bağlanmaması.
- Izgara ve boşluk: Ekranlar arasında tutarlı kenar boşlukları ve hizalama; farklı genişliklerde öngörülebilir davranış.
Grafik tasarım geçmişi olanlar bu alanda avantajlıdır. Bu temel becerilerin grafik tasarımdaki karşılığını iyi bir grafik tasarımcının özellikleri rehberinde ele aldım.
Etkileşim ve durum düşüncesi
Deneyimli bir arayüz tasarımcısını en hızlı ayırt eden beceri, bence durum düşüncesidir. Bir ekran tek bir resim değildir; veri yokken, veri yüklenirken, bir hata oluştuğunda, kullanıcının yetkisi olmadığında ve işlem başarıyla tamamlandığında farklı görünür. Bu durumların her biri tasarlanmazsa, geliştirme sırasında doğaçlama çözümler ortaya çıkar.
Bir veri isteğinin arayüzde doğurduğu yükleme ve hata durumlarını API entegrasyonu ve arayüz durumları yazısında ayrıntılı anlattım. Bu beceriyi portfolyoda göstermenin yolu basittir: Ana ekranın yanında en az bir boş durum ve bir hata durumu ekleyin.
Erişilebilirlik ve kapsayıcı tasarım
Erişilebilirlik, görme, işitme, hareket veya bilişsel farklılıkları olan kişilerin de ürünü kullanabilmesini hedefler. Ama sonuçları herkese yarar: güneş altında telefona bakan, tek eliyle çanta taşıyan ya da yavaş bağlantıyla çalışan herkes.
W3C’nin WCAG 2.2 yönergesi bu alanın temel başvuru kaynağıdır. AA düzeyinde normal metin için en az 4.5:1, büyük metin ve arayüz bileşenleri için en az 3:1 kontrast oranı istenir; 2.2 sürümüyle dokunma veya tıklama hedefleri için asgari bir boyut ölçütü de eklenmiştir. Bir tasarımcıdan bu oranları ezbere bilmesi değil, ekranlarını bunlara göre ölçmesi beklenir. Tasarım tarafındaki kontrolleri web standartları ve erişilebilirlik kontrolü yazısında listeledim.
Prototipleme ve test
Prototip, bir fikri kodlamadan denemenin yoludur. Beceri, prototipin doğru ayrıntı düzeyinde kurulmasındadır: Bir akışı denemek için her animasyonu çizmek gerekmez; bir mikro etkileşimi denemek için ise bütün uygulamayı bağlamak gerekmez.
Test becerisi de görev yazmakla başlar. “Uygulamayı inceleyin” yerine “Gelecek hafta salı günü için randevu alın” gibi gerçek bir görev verilmelidir. Katılımcıya yardım etmeden izlemek, gözlemi not etmek ve bulguları önem sırasına koymak bu becerinin parçalarıdır. Hangi kararların prototipte sınanması gerektiğini wireframe ve prototipte test edilecek kararlar yazısında anlattım.
İletişim: gerekçe yazma, geri bildirim alma, geliştiriciyle çalışma
Tasarım kararları ekip içinde tartışılır. Bir kararı “böyle daha güzel” diye savunmak yerine, hangi kullanıcı görevine hizmet ettiğini ve hangi alternatifin neden elendiğini anlatabilmek, tasarımcının etkisini belirler. Geri bildirim alırken de aynı beceri gerekir: Her yorumu uygulamak değil, yorumun işaret ettiği problemi bulmak.
Geliştiriciyle çalışma bu becerinin en somut hâlidir. Ekranları teslim edip çekilmek yerine, geliştirme sırasında gelen soruları cevaplamak ve uygulanan ekranı tasarımla karşılaştırmak, sonucun kalitesini doğrudan etkiler.
Kendi projelerimde önemli kararları kısa bir karar kaydı olarak tutuyorum: Ne değişti, neden değişti, hangi alternatif elendi. Bu kayıt birkaç ay sonra “Bu buton neden burada?” sorusu geldiğinde ekibin aynı tartışmayı baştan yapmasını önler. Bir tasarımcının bu tür yazılı iz bırakma alışkanlığı, dışarıdan bakıldığında görünmez ama ekip içinde çok değerlidir.
Teknik okuryazarlık
UI/UX tasarımcının kod yazması gerekmez; ama tasarladığı şeyin nasıl yapılacağını kabaca bilmesi gerekir. Bu okuryazarlık şunları kapsar:
- HTML ve CSS mantığı: kutu modeli, esnek yerleşim, ekran genişliğine göre değişen düzen.
- Veri ve durum: Bir listenin sunucudan geldiğini, bu sırada yükleme ve hata durumlarının oluştuğunu bilmek.
- Platform kuralları: iOS için Apple Human Interface Guidelines, Android için Material Design 3 kılavuzlarının temel yaklaşımı.
- Devir: Ölçülerin, renk ve yazı değişkenlerinin ve dışa aktarılacak varlıkların geliştiriciye nasıl aktarılacağı.
Tasarım ile ön yüz geliştirme arasındaki teslim ilişkisini HTML, CSS ve JavaScript teslimi yazısında ele aldım.
Becerileri geliştirmek için alıştırmalar
Becerilerin hiçbiri yalnız okuyarak gelişmez. Aşağıdaki alıştırmalar, her birini kısa ve tekrarlanabilir bir pratikle çalışmanıza yardımcı olur:
| Beceri | Alıştırma |
|---|---|
| Problem tanımlama | Bir uygulama mağazasındaki olumsuz yorumları okuyun; her şikâyeti tek cümlelik bir problem tanımına çevirin. |
| Akış | Bir bankacılık ya da kargo uygulamasında tek bir görevi seçin; bütün karar noktalarını ve hata yollarını çizin. |
| Görsel hiyerarşi | Kalabalık bir ekranın ekran görüntüsünü alın; yalnız boyut ve boşlukla yeniden düzenleyin, renk kullanmayın. |
| Durum düşüncesi | Bir listeyi boş, tek kayıtlı, çok kayıtlı ve hatalı hâlleriyle dört ayrı ekran olarak çizin. |
| Erişilebilirlik | Kendi tasarımınızdaki bütün metin ve buton renklerinin kontrast oranını ölçüp bir tabloya yazın. |
| Test | Bir arkadaşınıza tek bir görev verin; yardım etmeden izleyin ve yalnız gözlem cümleleriyle not tutun. |
| İletişim | Bir tasarım kararınızı, tasarım bilmeyen birine üç cümlede anlatacak şekilde yazın. |
Bu alıştırmaların çıktıları, portfolyoda vaka çalışmalarınızı destekleyen küçük kanıtlar olarak da kullanılabilir. Önemli olan, her alıştırmanın sonunda neyi öğrendiğinizi bir iki cümleyle not etmektir; bu notlar mülakatta düşünme biçiminizi anlatırken işinize yarar.
Bir ipucu daha: Becerileri tek tek çalışmak başlangıçta faydalıdır, ama gerçek projelerde hepsi aynı anda devreye girer. Bu yüzden belirli aralıklarla küçük bir uçtan uca proje yapın: bir görevi tanımlayın, akışını çizin, ekranlarını durumlarıyla tasarlayın, iki üç kişiyle deneyin ve sonucu yazın. Bu döngüyü tekrarlamak, ayrı ayrı öğrendiğiniz becerilerin birbirine nasıl bağlandığını görmenizi sağlar.
Kıdeme göre beceri beklentisi
Aynı beceriler her kıdemde istenir, ama beklenen derinlik ve bağımsızlık değişir:
| Beceri alanı | Junior | Mid | Senior |
|---|---|---|---|
| Problem tanımı | Verilen problemi anlar, soru sorar | Problemi verilerle netleştirir | Hangi problemin önce çözülmesi gerektiğini ekiple belirler |
| Akış ve yapı | Tek bir görevin akışını çizer | Birbirine bağlı akışları tutarlı kurar | Ürün genelinde bilgi mimarisini yönlendirir |
| Görsel tasarım | Mevcut kütüphaneyi doğru kullanır | Yeni bileşen önerir ve belgeler | Tasarım sisteminin yönünü belirler |
| Durumlar ve istisnalar | Hatırlatıldığında ekler | Kendiliğinden listeler | Teknik ekiple birlikte istisnaları önceden öngörür |
| Test | Testi izler, not alır | Test planlar ve yürütür | Neyin test edilmesi gerektiğine karar verir |
| İletişim | Kararını açıklar | Paydaşlara sunar, geri bildirimi yönetir | Ekipler arasında uzlaşma sağlar, genç tasarımcılara yol gösterir |
Senior bir tasarımcıyla çalışmanın işletme açısından ne anlama geldiğini İstanbul’da senior UI/UX tasarımcı ile çalışmak yazısında anlattım.
İşe alırken bu becerileri nasıl sınarsınız?
Bir UI/UX tasarımcı seçerken portfolyodaki ekranlara bakmak yeterli değildir. Şu yöntemler daha fazla bilgi verir:
- Vaka çalışması anlatımı isteyin: Adaydan bir projeyi problemden sonuca anlatmasını isteyin. Rolünü net söyleyip söylemediğine dikkat edin.
- Durum ekranlarını sorun: “Bu listenin boş hâli nasıl görünüyordu?” sorusu çok şey anlatır.
- Kısa bir eleştiri alıştırması yapın: Mevcut ürününüzden bir ekranı gösterip adayın neyi neden değiştireceğini dinleyin.
- Devir dosyası örneği isteyin: Geliştiriciye teslim edilen bir dosyanın nasıl düzenlendiğini görün.
Freelance çalışacak bir tasarımcı seçerken ek olarak kapsam, revize ve teslim maddelerini de değerlendirmek gerekir; bunun için freelance UI/UX tasarımcı seçimi rehberine bakabilirsiniz.
Özet: UI/UX tasarımcı becerileri kontrol listesi
- Problemi cevaplanabilir bir soruya indirgeyebiliyor ve gözlemi yorumdan ayırabiliyor mu?
- Akışı hata ve vazgeçme yollarıyla birlikte çizebiliyor mu?
- Tutarlı bir tipografi, renk ve ızgara sistemi kurabiliyor mu?
- Boş, hata, yükleme ve başarı durumlarını kendiliğinden tasarlıyor mu?
- Kontrast ve dokunma alanlarını ölçüyor mu?
- Kararlarını gerekçesiyle anlatabiliyor ve geliştiriciyle birlikte çalışabiliyor mu?
Bu becerileri hangi sırayla kazanabileceğinizi UI/UX tasarımcı nasıl olunur, günlük işte nasıl kullanıldıklarını UI/UX tasarımcı ne iş yapar rehberinde bulabilirsiniz. Becerilerin dayandığı temel kurallar için UI/UX tasarım ilkeleri, araç tarafı için UI/UX tasarım programları sayfalarına bakabilirsiniz. Kavramların genel çerçevesi UI/UX tasarım rehberinde yer alıyor.
UI/UX tasarımcı becerileri hakkında sık sorulan sorular
UI/UX tasarımcı için en önemli beceri hangisidir?
Tek bir beceri seçmek zor; ama problemi doğru tanımlamak diğer bütün becerilerin verimini belirler. Yanlış tanımlanmış bir problem için hazırlanan özenli ekranlar, ürünün asıl sorununu çözmeyebilir. Bu yüzden soru sorma ve gözlem becerisi listenin başında yer alır.
Çizim yeteneği gerekli mi?
İleri düzey çizim gerekmez. Fikri hızlıca kâğıda dökebilecek kadar kutu, ok ve basit şekil çizebilmek yeterlidir. İllüstrasyon gerektiren işler genellikle ayrı bir uzmanlıkla yürütülür.
Empati bir beceri olarak nasıl gelişir?
Empati, kullanıcıyı gözlemleyerek ve dinleyerek gelişir. Kullanıcı görüşmelerine katılmak, destek kayıtlarını okumak ve test oturumlarını izlemek, “ben olsam böyle yapardım” varsayımını düzeltir. Kendi alışkanlıklarınızın herkesi temsil etmediğini görmek bu becerinin başlangıcıdır.
Senior UI/UX tasarımcıyı junior’dan ne ayırır?
Senior tasarımcı istisnaları ve durumları kendiliğinden öngörür, hangi problemin önce çözülmesi gerektiğini ekiple belirleyebilir ve kararlarını farklı paydaşlara anlatabilir. Junior tasarımcı ise verilen bir problemi çözmeye odaklanır ve daha fazla yönlendirmeye ihtiyaç duyar. Fark çoğu zaman araç bilgisinde değil, muhakemede ve bağımsızlıktadır.
UX tasarımcı istatistik bilmeli mi?
İleri düzey istatistik genellikle gerekmez. Ancak analitik verileri okuyabilmek, küçük bir örneklemden genel sonuç çıkarmanın riskini bilmek ve yüzdeleri doğru yorumlamak önemlidir. Büyük ölçekli deneyler söz konusuysa veri analistleriyle birlikte çalışılır.
UI tasarımcı için tipografi neden önemli?
Arayüzdeki bilginin büyük kısmı metinle aktarılır: başlıklar, etiketler, butonlar, hata mesajları. Tutarlı bir yazı ölçeği ve okunabilir satır yapısı, kullanıcının ekranı taramasını ve doğru öğeyi bulmasını kolaylaştırır. Zayıf tipografi, iyi kurulmuş bir akışı bile zor kullanılır hâle getirebilir.
Bu beceriler portfolyoda nasıl gösterilir?
Her vaka çalışmasında problemi, sizin rolünüzü, akışı, denenen alternatifleri, durum ekranlarını ve varsa deneme bulgularını gösterin. Kontrast kontrolü, bileşen varyantları ve devir notlarından birer örnek eklemek, teknik ve görsel becerileri aynı anda kanıtlar.
Teknik bilgi ne kadar gerekli?
Kod yazacak düzeyde olması gerekmez. Ekranların farklı genişliklerde nasıl davrandığını, verinin sunucudan geldiğini ve bunun yükleme ile hata durumları doğurduğunu, platform kurallarının temel yaklaşımını bilmek yeterlidir. Bu bilgi, geliştiricinin uygulayabileceği ve sonradan değiştirmek zorunda kalmayacağı tasarımlar yapmayı sağlar.